Open source vs proprietary: Both have advantages

This is part two 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 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.