Open source supply and demand
Auto mechanics and software
"Lowering the cost of a good tends to increase, rather than decrease, total investment in the infrastructure that sustains it. When the price of cars goes down, the demand for auto mechanics goes up -- which is why even those 5 percent of programmers now compensated by sale-value would be unlikely to suffer in an open-source world."
First, it's worth reiterating that Raymond's 5 percent estimate is just that, an estimate. I mentioned in my theory section that I find that estimate to be low, and that it could range as high as 20 percent. Raymond admits as much in "The Magic Cauldron," though, and I have no more proof for my figure than he has for his.
His analysis, in the broad outlines, is correct. In markets where the price of a good is low, demand goes up (classic demand curve theory). For products with associated service costs (such as the market for automobiles), this can result in a boost in the demand for people who provide those services.
Raymond's error lies in assuming that this rule applies down to zero. I've discussed at length software valuation in this article, but to rehash, consider the market for coats. If I paid $2,000 to buy a coat, I'm more likely to pay $150 to have the coat repaired. In contrast, if I only paid $50 for a coat, I probably would buy a new coat unless I could find someone to repair it for less than $50 (something that would put downward pressure on seamstress salaries). The same applies to TV sets and VCRs. The market for TV repair has collapsed because televisions are so inexpensive that it is often cheaper just to buy a new television.
A similar dynamic exists in software. I've always been amazed at the rates charged by SAP contractors or Oracle DBAs. These rates only make sense in markets where the up front cost of software is very high. Both SAP financial software and Oracle databases are very expensive, and that provides cover for high rates. Similarly, Adobe Photoshop, at $500.00, provides cover for Paint Shop Pro, which is a bargain, comparatively speaking, at $100.00, even though that price is higher than the shrink-wrapped software average.
Valuation has a high perception component. There is a perception that bartenders should be paid more than waiters/waitresses, and that turns out to be the case.
There is a perception that Levis blue jeans should cost $70-$80 in Europe, whereas in America, that is far too high. There is a perception that Sargento-brand cheese is worth three times the price of Food Club-brand cheese (Food Club is a generic label in America), even though the cheese packaged by each comes from the SAME block (it's amazing what you can learn from a tour of a cheese factory in Wisconsin).
The perception of what developers should be paid is linked to the value of the product they service. This is why it is false to assume that lowering the price of software almost to zero will result in higher salaries for developers. Free (as in cost) software, which as I explained in a past article is a necessary by-product of GPL-style licences, leads to lower perceived value for the technicians responsible for the construction of software.
Raymond seems to partly agree with this, as he claims the following:
"Any foregone profits, however, will be more than matched by benefits on the cost side, as software consumers reap tremendous savings and efficiencies from open-source products."
Perhaps this is true, though I don't see why this should cheer software developers. Even so, it may well harm consumers if lower salaries reduce the supply of programmers.
Of course, the wonder of free markets is their flexibility. If the supply of developers falls too low, salaries would rise, attracting more developers into the market. Of greater concern is the structural changes wrought by the eradication of customer-facing, self-funded software companies which experiment in parallel at the satisfaction of consumer wants. A reduced flow of innovations would result in a smaller market (fewer new software ideas, fewer new products).
In short, a market without a sufficient number of customer-facing entities would be a market with lower demand for software developers.
Technology "rock stars" and aristocratic patronage
One way Raymond suggests open source would take up the "slack" caused by a reduction in the number of proprietary software companies is the hire of people to work full time on open-source development projects:
"The community's stars are increasingly finding they can get paid for what they want to do, instead of pursuing open source as a hobby funded by another day job. Corporations like Red Hat, O'Reilly Associates, and VA Linux Systems are building what amounts of semi-independent research arms with charters to hire and maintain stables of open-source talent."
First, of people paid to spend all their time on a single piece of software, proprietary developers constitute the majority. I question the degree to which "working to earn goodwill" (Raymond's explanation of the motivation companies would have for hiring "open-source superstars") will pick up the slack created by the reduction in proprietary software jobs.
Second, most programming rock stars operate in the world of proprietary software. James Gosling, Bjarne Strousrup (creator of C++), Anders Hejlsberg (creator of Delphi and C#), Bill Joy, Don Box and Charles Petzold all leap to mind. The difference between them and their open-source parallels lies in their paycheque, which might go a long way towards explaining why more are found in proprietary software. Furthermore, they tend to be strong defenders of a developer's right to make a good (even direct) profit from his or her labours. As Gosling noted in a recent blog post:
"developers put a huge amount of energy into creating software and if they can't get that energy back in a way that balances, then the system falls apart."
Third, as noted, proprietary software companies have a greater incentive to push the programming state of the art forward due to the rigors of the "upgrade treadmill." Furthermore, proprietary software companies clearly have more money. Given these two facts, I have even more trouble believing that "building goodwill" will serve as much of a replacement for the incentives and money that drives superstar employment at proprietary software companies.
Fourth and final, Raymond compares the practice of hiring "superstars" to "the system of aristocratic patronage that funded most fine art until after the Industrial Revolution". This is an interesting analogy, though one questions why this should be considered a good thing. Rembrandt spent an inordinate amount of time painting portraits of fat, rich people. Why? Because those were the people who wrote the cheques which kept the candles burning in the art studio, if you catch my drift.
When you're self-funded, you are free to achieve higher levels of self-expression in your art. Most fine art these days is funded by direct sales to collectors, and I expect that few artists would prefer a return to aristocratic patronage.
Of course, proprietary software developers are bound by the demands of consumers. Artists who can't convince anyone to buy their stuff would still have to squat in abandoned factories in shady parts of town. That doesn't mean, however, that self-funded software companies aren't free to achieve higher levels of creativity than the "hired stable" of open-source superstars living in a modern version of aristocratic patronage.
The services business model
The most common business model proposed by open-source advocates is the provision of services around an open-source core. Services include technical support, installation assistance, and the creation of custom software atop an open-source base. A number of companies use this model, among them JBoss (maker of an open-source Java/J2EE implementation), IBM, and more recently, Novell. All these companies sell consulting services, and make a tidy sum in the process.
That's all well and good, but it must be recognised that consulting services are NOT exclusive to open-source markets. Consulting exists for proprietary software as much as open-source software, making the "services model" less of a business model innovation so much as the continuation of something that already exists. In other words, services aren't going to bridge the loss of 5 to 20 percent of software jobs reliant on "sale value", nor are they an answer to the problem of markets detached from the sources of information relating to consumer wants.
Conclusion
As I noted in the first instalment, this series was not a condemnation of open-source. Rather, it is a call to moderation, as well as an attempt to draw the outlines of a new equilibrium between the worlds of open-source and proprietary software.
Thirty years ago, most software was open-source. IBM released the source code for the software which ran on its mainframes, something made possible by a business model oriented around the sale of hardware. Somewhere along the way, people figured out a way to monetise a market for software. This created an explosion of software innovation and built the software economy from which America generates so much of its GDP.
Proprietary software's success caused the pendulum to swing too far from software's roots, causing open-source practically to disappear from standard practice. The pendulum is swinging back again, and that is a good thing. As it swings, we should remember the benefits of business models built upon sale of access to a secret (proprietary software).
I've long advocated a hybrid model for open-source software companies, one where key parts of a product are kept private while a slow-changing core is opened up to the wider development community. This links the benefits of open-source software development to the benefits of a model that encourages consumer-oriented innovation.
As they say, you can have your cake and eat it, too.
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.