COMMENTARY--This is Part 3 in a four-part series of articles that is roughly a response to "The Magic Cauldron," the seminal work on open source economics written by Eric Raymond. This installment discusses Raymond's "five reasons" for choosing to create or use open source products.
 | ||||
|
| | ||
|
Propriety vs. open source 1: Driving the economy  2: The advantages 3: Why open source? 4: Suppliers & demand Commentary |
| ||
|
|
||||
|
|
||||
a) Reliability / Stability / Scalability are critical
b) Correctness of design and implementation cannot readily be verified by means other than independent peer review.
Item a) assumes that reliability, stability and scalability are better delivered by open source. This is often based on the notion that the public nature of an open source product enables thousands of eyes to pore over the code. This makes it more likely that problems will be found, leading to more bulletproof code.
Scalability depends on proper design and the application of good ideas which relate to the construction of scalable systems. Though some might disagree, open source doesn't have a monopoly on good programmers capable of making good designs. Will they be more likely to produce such good designs when they don't have a financial interest in the outcome? Empirically speaking, proprietary software has taken the lead in scalability, as proprietary UNIX was considered more scalable until only recently (and the big UNIX implementations still tout themselves as being more scalable in enterprise computing environments than Linux).
Regarding reliability and stability, finding flaws assumes "the community" truly scans the code for errors. Big projects might manage that, but smaller projects would have a harder time given their inability to attract developer attention. Witness the proliferation of "open source orphans" in the Sourceforge database. The open source nature of such projects is not in itself a guarantor of reliability or stability.
Furthermore, consider that proprietary software historically has done a much better job of providing the features that matter to ordinary consumers than open source software. As noted in the Theory section, this is necessarily true, as proprietary companies are the only entities with the close interactions with customers required to discover these features, not to mention the financial resources to orient developers towards those needs.
What will be the track record of companies that view security as a feature? I'm not suggesting that there isn't advantage to publicly-vetted code. There is. On the other hand, there are also advantages to be derived from companies with financial incentives to solve problems as quickly as possible. Microsoft appears to have succeeded in this regard, managing the shortest time between the announcement of a vulnerability and a fix. Furthermore, Microsoft's Trustworthy Computing initiative is an unprecedented effort to apply the revenue of a profitable software business towards the construction of a more secure operating system.
In other word, I think the jury is still out whether open source is inherently more secure than proprietary software. Publicly vetted code has certain advantages, and large companies such as Microsoft could benefit from that by endeavoring to release more source code. On the other hand, proprietary software's track record in the realm of features could translate into more secure proprietary operating systems when consumers (due to the internet) actually demand security.
c) the software is critical to the user's control of his/her business
Raymond expands on this elsewhere by noting that:
A consumer's rational desire to avoid being locked into a monopoly supplier will increase its interest in open source
In other words, fear of monopoly lock-in of the sort Raymond considered endemic to proprietary software will motivate people towards open source.
As noted, however, shifting to open source does not imply more choice. In practically every open source product segment, there is one dominant product. This is natural and is a function of the need for standards in markets which lack inherent levels of compatibility.
Furthermore, open source does not imply any more freedom to shift between implementations. Obviously, standardizing on Linux won't make it any easier to shift to a Mac. Once you commit to a particular operating system, you commit yourself through the applications you choose and the development staff you hire.
Even within Linux, however, you can't easily shift from Red Hat to Debian, and your ability to do so goes down with every passing year (and every new feature added to each distribution). The fact that Debian can get access to, and thus copy, extended features in Red Hat (which are open source, though note that there is no REQUIREMENT that that be the case so long as those extensions use, but don't alter, GPLed code) does not mean that Debian does, in fact, avail itself of those features. Though Raymond claims otherwise (he claims that Red Hat business model is based on assembling and testing a running operating system that is warranted (if only implicitly) to be merchantable and to be plug-compatible with other operating systems carry the same brand), Linux distributions are not compatible with one another, and short of selling the EXACT same bits a la Microsoft or Apple, never will be so long as human beings are capable of satisfying the same basic requirements in different ways.
Quality and suitability for required tasks would also be important in software that is "critical to the user's control of his/her business." I've already discussed the Reliability / Stability / Scalability issue, noting that proprietary software isn't necessarily worse in this regard.
In addition, Raymond claims that one of the advantages of open source is freedom from the deadlines that force code to be rolled out too soon. Oddly enough, one of the disadvantages of open source is freedom from the deadlines that ensure changes happen when companies need it. This has ramifications for companies reliant on open source products.
Open source provides a company the opportunity to maintain the code themselves, should the need arise, or to contract with someone else to move the code forward in directions they require. In such cases, deadlines can be imposed. However, not every company has the resources to finance custom development tasks. One of the advantages of proprietary companies is that buyers essentially outsource development tasks to them.
Granted, proprietary companies might lack certain critical features, but they at least have an incentive to figure out what they lack. I rarely hear of people talking about the need to alter core Windows code. A more common complaint, at least from the open source community, is that Windows has TOO MANY integrated features.
Access to source code provides flexibility, to be sure, for companies capable of financing their own extensions. That flexibility, however, comes with a price: the ability to fork the code in incompatible directions.
Don't believe for a moment that this never happens. I've run across numerous situations where clients have customized a piece of open source software in such a way that they can no longer drop in updates from the main code stream. This was partly due to a lack of extensibility in the base open source product, making alteration the only way to get the desired functionality.
In this regard, proprietary software might have an unexpected incentive to build in proper extensibility hooks. Since they don't provide customers the ability to change the original source code, they are OBLIGATED to design with extensibility in mind. I've noted numerous times that Microsoft writes their software like operating system components (meaning, with high levels of extensibility and reusability). Open source can "cheat," as it were, as release of the source code implies the ability to alter code to do whatever you want, even if it destroys compatibility.
d) the software establishes a common computing and communications infrastructure
This, in other words, is the "open source drives ubiquity" thesis that I've mentioned in past articles on the subject.
I agree that open source does this. Open source is a great way to spread a technology far and wide. The code is free, companies can alter it as needed, and if the code comes under a BSD-style license (that is, not GPL), can be freely used in proprietary software.
It should be noted, however, that releasing source code is not the only way to build ubiquity. Few would consider Windows as anything but ubiquitous. They did this by offering Windows at relatively low cost to any hardware vendor who wished to run it. Windows was one of the first mass-market, commodity operating systems, and this positioning was key to Microsoft's success at beating a certain company in Cupertino which had a head-start in graphical operating systems.
Likewise, the release of free client software is a common way to build popularity for new technology. Apple's Quicktime, Real Network's RealPlayer and Adobe's Acrobat Reader are all examples of such software, and none of them are open source. This points to the real driver of ubiquity: free (as in cost).
e) key methods (or functional equivalents of them) are part of common engineering knowledge
In other words, technology that is well understood is a prime candidate for open source products.
I agree with this completely. In fact, as noted in my theory section, the best place for open source is in well-understood technology domains. The best way to become well understood, however, is for self-funded companies to conduct parallel experimentation in the satisfaction of consumer needs. The winner will be the "right" technology. With time, knowledge encapsulated by that solution will disseminate into the wider marketplace, leading to eventual incorporation into an open source product.
This will undermine the ability of the original innovator to earn "rents" for the use of their groundbreaking technology, but this is a Good Thing ™. Software relies on good ideas working their way into the public domain, which serves as the foundation of my opposition to software patents.
biography<
John Carroll is a software engineer now living in Ireland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.
| 05/17/04
