Small Business Services

I ended my previous entry giving you assurances that there is no conflict of interest in the Open Source economy, and noted that there are many reasons that people contribute to free software. In this article, I will show you how these many reasons actually help to eliminate the possibility of conflicts of interest causing substandard software in the Open Source world -- at least for the purpose of monetary gain.

First, it's necessary to understand the idea of "enlightened self interest" that pervades the Open Source world. That is, "by helping others, I ultimately help myself." This mantra is the central idea behind what is essentially a positive feedback loop.

The first thing that tends to attract people to free software is the price. Once they realize that the software is fit for their needs, business or personal, they begin to gain utility from it. As they gain utility, they start realizing that some feature is missing that they'd like to have, or there's a bug that annoys them, and so they do one of three things:

1. Ignore it and hope it's fixed in the next release.
2. Fix it if they are so endowed with programming expertise. After all, the program code is freely available.
3. File a bug report with the developers, specifying the bug and how to reproduce it.

Notice that the second and third option are constructive, while the first has no effect whatsoever. While most people will pick the first option, a significant number of people are motivated by their generosity or annoyance level that they fix the problem. The next thought is that they do not want to fix this over and over again in every new release, so they send their fixes back to the original author. The author includes the fix or new feature into the "upstream" -- the master code -- and everyone who uses that software package from that point on benefit. It's wonderful how one person can help millions of people by helping themselves!

Now realize that there are many more reasons that a person would create a fix and send it to the original author. There's the example of a company that uses Open Source products as part of their product. A bug in an open source program is a bug in their own product, so, in the interest of their product, they fix it and send the fix upstream. Google is an example of one such company, who contributes millions of dollars each year in funds to Open Source programmers or code contributions to F/OSS projects.

Still others contribute because they'd like to make a name for themselves to improve their future employment prospects. When the Dot Com Bubble burst in the late 90's, Open Source software improved dramatically, benefiting from the sudden surge of programmers who suddenly had much more free time on their hands, many of whom were trying to pad out their resume in the down time.

So we've established that there are many reasons for contributing, likely many more than mentioned above, but how does this prevent conflicts of interest?

Remember that, in popular FOSS projects, there will be dozens if not hundreds of programmers contributing. The leaders of that project need to appear to be "benevolent", because if they are not, the disenfranchised contributors are free to take the code and go start their own project with it in a process called "forking the project". If they want to retain their de facto leadership status and see their project continue to succeed, these leaders cannot give the impression of impropriety. Remember that they're dealing with highly intelligent, and many times temperamental people who are quick to notice that sort of thing.

Once the project leader is assumed neutral, the only ones left to determine what goes into the project are the contributing programmers themselves. These people, as a group, are contributing for every reason mentioned above and more. If we assume that one programmer has a conflict of interest with respect to adding a feature, you can just as easily assume that another one does not. One programmer's conflict of interest does not preclude another programmer from creating the new feature or fixing a given bug. Once submitted, the supposedly neutral leader will vet the new program and then include it into the master source code, making the project better in spite of a single member's conflict of interest.

That's how many disparate interests prevent a conflict of interest. It's not that they don't exist, it's that, when they do, they are not typically shared across the group, so the feature or bug fix is created anyway. Most Open Source programmers understand this, so the situation doesn't really even come up. For the most part, energy is focused on making the project as good as it can be because that benefits everyone.