Open source vs proprietary: Both have advantages

Why markets are often dominated by one company
Raymond believes that the end product of the upgrade treadmill is shrinking sales in a market where new innovations are hard to come by. The only escape is a market without competitors. According to Raymond, this "support-starvation failure mode" is the cause of the consolidation and monopolisation that he considers to be endemic to the proprietary software market.

Of course, one must ask how even monopoly providers of software are supposed to convince existing customers of software to upgrade in the absence of clear reasons to do so, given that most will likely possess an older version of the dominant product. Consider Microsoft Office. Office has so many features unused by the vast majority of word-processing consumers that few see much of a need to buy the latest and greatest version. I have Office 2003 sitting on a DVD (in other words, it would cost me nothing to install it), but I haven't for no other reason than I lack sufficient reason to do so.

In other words, driving off competitors won't make people buy NEW copies of software that changes little. If "monopolisation" is supposed to be the way big companies secure future revenue from stalled product lines, then it would seem a misdirected effort.

In truth, the "support-starvation failure mode" theory distracts people from the real reason that one company becomes dominant, which is the need for standards. Talking to a diversity of APIs, or even multiple implementations of the same API, is costly, and thus markets have shown a natural tendency to favour one variant of a product over all others. That's fairly apparent in proprietary software, as one product tends to dominate in most categories. What is less discussed is the tendency for dominance in open-source software.

Red Hat is the dominant Linux distribution, at least in the United States. Companies that standardise on Red Hat would have a hard time shifting to Debian, Slackware or Mandrake distributions, simply because there are sufficient differences between each variant that transition would not be problem-free. The end result is one distribution gets favoured disproportionately by customers and third-party software vendors attracted by the economics of scale to be derived from such a concentration.

The same thing happens in other categories of open-source software. Although competitors to Mozilla exist, the browser clearly is the leader in the market for "open-source browsers". Apache is the clear leader in web servers, and MySQL is breaking ahead of the pack (though databases in general tend to support a lot more competitors).

In short, dominance is not a by-product of corporate attempts to find a solution to the limits of the "upgrade treadmill". Rather, it is a symptom of markets that lack natural levels of compatibility.

Time wasted on marketing requirements
Marketing or management dictates can often seem nonsensical to developers in the trenches. Speaking to this perception, Raymond states:

"[Open-source] developers don't experience the pressures that routinely compromise conventional closed projects and turn them into tar-pits -- no lists of pointless and distracting check-list features from Marketing, no management mandates to use inappropriate and outdated languages or development environments, no requirement to re-invent wheels in a new and incompatible way in the name of product differentiation or intellectual property protection, and [most importantly] no deadlines."

I don't think it's fair, however, to say that ALL marketing dictates are useless. As noted in the first instalment of this series, one of the advantages of proprietary software is close contact with real-world customers. Such customers are NOT like developers. They have different sets of needs, and thus, developer instincts will not be as useful in the creation of consumer-oriented software. Those marketing dictates, in other words, might not be so pointless after all.

As for the appropriateness (or lack thereof) of languages or development environments, consider that geeks LOVE technology, and the newer the technology, the better. If free to do so, they will use the latest languages and development tools whether or not real-world customers are ready to use them. These are all things that matter to managers, and are thus IMPORTANT issues that are not considered in projects where developer "Ids" are free to let their preferences run wild.

"Re-inventing wheels" is an expensive proposition. In my experience, proprietary companies are obsessive about costs given that THEY are the ones paying developers. They don't tend to favour the reinvention of wheels, and tend to reward developers for finding ways to use previously-developed technology. Every developer in modern software projects has trolled the Sourceforge seas for open-source titbits that might shave weeks or months off development time.

In contrast, my experience of volunteer projects is that multiple "reinvented wheels" lie all over the workshop. The reason probably comes down to developer psychology. It's in the nature of developers to be control freaks, and that leads to grand projects that duplicate work simply because they want their software to work EXACTLY the way they want it to. Likewise, developers, as technophiles, often find it fun to untangle a difficult development knot.

Lastly, time constraints matter. I will grant that companies can shove software out the door too quickly. That doesn't mean that all time constraints are a bad thing. A middle ground seems more logical than the languid pace that becomes the norm in situations where the project has no constraints (think: Mozilla). Customers have needs now, and the first one to satisfy them has a better chance of doing so longer term.

Spreading the development load / cost-sharing
Releasing the source code for a product can serve to spread the costs of development. This is useful in a number of ways.

A company is no longer solely responsible for maintenance. They avail themselves of more developer input than they could ever manage on their own. A product released under a GPL-style licence ensures that a product's future is not reliant on the financial health of a single company. GPL-style licences help to ensure that anything added to the code will always exist in the public domain.

Spreading development responsibility IS useful, though there are limitations to the theory. The benefits derived from pooled efforts don't imply that all product development should be pooled. Does it make sense to get rid of all that "wasteful" parallel development and pool resources in the construction of a national, or even global, automobile manufacturer? No, and the reason is that parallel experimentation would be lost, thus depriving humanity of the resource optimisations and innovation that come from it.

Consideration must be given to where pooled effort makes the most sense. Technology that isn't well understood is not a prime candidate for pooled efforts.

John Carroll is a software engineer now living in Ireland. He specialises in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.