This article discusses points relating to the comparative merits of open-source and proprietary software. You can find part one, How the software economy is driven by proprietary work, here.
In defence of the upgrade treadmill
Raymond proposed that a weakness in proprietary business models is its reliance on future sales. As Raymond states:
"If the vendor's money comes from selling bits, most effort will go to making bits and shoving them out the door; the help desk, not a profit centre, will become a dumping ground for the least effective and get only enough resources to avoid actively alienating a critical number of customers."
This is a different spin on the same phenomenon noted in the Theory instalment of this series. To my mind, the "upgrade treadmill" is what drives proprietary software companies to generate so much innovation, as innovation is what convinces consumers to buy upgrades. This is the root cause of the disproportionate share of "use value" created by proprietary software.
Second, I question whether proprietary companies really do such a poor job of supporting customers, or even developers. A common complaint regarding open source is the lack of a reliable source of assistance when you encounter problems in an open-source product (though companies like Red Hat, IBM and Novell are doing everything they can to bridge the divide).
Similarly, those companies dedicated to "shoving bits out the door" manage to do a better job of providing documentation. As noted in past articles, it is my experience that proprietary software products are MUCH better documented than open source (with a good example found in Microsoft's MSDN Web site). I propose that this is due to the volunteer nature of most open-source software development. Volunteers tend to contribute the kind of work they find interesting, and take it from me, developers HATE documentation. I hate documentation, and I write articles on a regular basis.
Raymond does note that the upgrade treadmill is only viable in a market "that is expanding fast enough to cover the support and lifecycle costs entailed in yesterday's sales with tomorrow's revenues." I agree completely. Mature markets that grow slowly will find it hard to convince customers to upgrade. However, that difficulty is also the thing that drives innovation. Products that lack such a drive, such as open source, won't have the incentives to make those discoveries.
Don't knock the upgrade treadmill. A financial stake in the success of a product is one of the things that makes capitalism so successful. The upgrade treadmill can be long, or it can be limited by the functional equivalent of a gymnasium wall. The risk of a broken nose is what drives innovation, and it is a useful addition to the software development process.
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.
> Every developer in modern software projects has trolled the Sourceforge seas for open-source titbits that might shave weeks or months off development time.
Whoa, that's rich. So, stealing (in terms of having no shame to spew nonsense about it and yet using it all over the place) is OK as long us free software is being stolen. Nice touch.
> 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.
What a load of it. This is so untrue it isn't funny. When did you last check a serious free software project? Just go and look at the number of dependencies each of those will have. That is code reuse in action, FYI. What is a real problem is licensing incompatibilities. And that is being worked on (to some success).
> Second, I question whether proprietary companies really do such a poor job of supporting customers, or even developers.
Obviously you haven't been in the position to speak to 5 different people that have no clue before hitting someone that actually knows what they are talking about. Ask a question on Apache Development list and see how fast and how good your answer is going to be.
Proprietary software can run but it cannot hide. It's days are numbered. The industry that has been built around it is too big and too expensive to be maintained long term. After all, computers and software as we know them today are still in their infancy.