Complement goods, developers who lack business sense, and open source as international aid
A long time ago, in a distant economic landscape, Joel Spolsky wrote an article applying the economic rule of complement goods to open source software. In short, Joel raises questions on the motives behind profit-maximising organizations funding open source development, arguing that those organizations are usually trying to commoditize software to sell something else, such as consulting services or hardware. In the long run, he argues, this puts developers out of work.
On a recent podcast with Dan Bricklin of Software Garden, Joel talks about developers "sitting around doing things that take two months when they could have bought something off-the-shelf for $199." This, he contends, is because many developers are out of touch with what makes sense for the businesses they work inside. Joel then further argues that open source gets into businesses because those developers who recognize they should not be reinventing the wheel run up against bureaucracies within their own organizations that make the procurement process unbearable when it comes time to purchase the right tools. This leaves developers to their own resources (i.e. SourceForge, Google) to save some time. In short, without a helping hand through the procurement process, they turn to open source.
I definitely have seen organizations that make the procurement process burdensome to the point of turning people elsewhere, but Joel overlooks one point: the value proposition of open source. I'll be the first to admit that free-as-in-beer is the first thing that entices many neophytes to consider open source. However, after getting in there, I think many organizations find that open source shows its real worth in terms of stability and flexibility that is the natural outcrop of a large-scale peer review process. Here, it is necessary to separate the small, few person open source projects from the large projects like Apache, JBoss, and MySQL. The smaller projects do not have the scale of the peer review process in which I see value, but the bigger projects do. Those bigger projects provide the infrastructure on which many organizations provide significant customer value and generate profits -- something they otherwise could not do. No doubt, they are generating profits off the volunteerism of others.
But one has to be careful in arguing that this transfer of knowledge in the form of working software should not take place because it puts developers out of work. Taken to its logical extreme, this argument could justify rewriting the same software over and over again. Economies seek to maximize efficiencies, and this would violate that principle. Maybe the answer is for societies to treat open source software as a public service, like water, energy and public transportation. Software is unique from these other public services in that it can easily cross geo-political borders and, thus, allow others to derive benefit from it without having contributed to the pool of funds that paid for the software. But in that case, maybe the economically advantaged Western nations should consider a portion of the contribution to funding open source development as aid to the rest of the world, allowing those less advantaged countries to grow their own economies and increase their own wealth (which can later be used to purchase Western goods and services).