This is part four 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 instalment discusses some of Raymond's proposals relating to the manner in which developers will earn money in an open-source economy.
Previous articles:
1: Driving the economy
2: The advantages
3: Why open-source?
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."
Talkback
More thoughts after examining the realities.
JC:"When the price of cars goes down, the demand for auto mechanics goes up"
This is not the case at all John. When the price of cars goes up the demand for msechanics goes up. As cars become more expensive people tend to hang on to their older vehicles and are more willing to fix those cars to keep them running because it saves them money over all.
JC:"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)."
Agreed and in practice this tends to be the case.
JC:"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."
The first flaw is in the assumption that companies and/or government pay '0' for OSS. This is not so in most cases. While individuals are more likely to use the free download versions, companies are likely paying to implement OSS solutions on many machines.
It is inaccurate to compare 'stand alone' goods to OSS. A coat is a coat. When you are talking about software you must remeber that that it is interconnected with the systems in use and in many case valuable data. It is integrated with other IT factors which are dependent on it. It is a part of a bigger system.
The issue is the total cost. If software engineers are needed they will be needed no matter the initial cost of the software. It's the lower cost of OSS combined with the cost of services needed is lower as a combined total which companies look at. Logic would suggest that if the initial cost of the software is less then there is more money available to software engineers. High lisencing costs of some proprietary solutions would tend to decrease the percentage available for software engineers.
To give an example John I will share a situation which my friend, a network admin told me.
He is a netwrk admin for a company in my area which uses MS, Novell, and Linux servers. With the high price of MS lisencing the Win admins are paid poorly. They are being 'commoditized'. The IT people at his shop are all MCSE types and handle all work on the MS and Novell servers. When updates and configuration of the Linux server (initial price nearly 0) his company calls in a "Linux specialist" who bills them at 5 times the salary of the MS admins. This, in real world practice contradicts your theory that companies will pay more to maintain higher priced proprietary software. The company pays this bill because the TCO of the Linux server is still lower. It seems the only IT pro's or sofware engineers who would suffer through OSS are those who don't learn GNU/Linux/OSS.
Your theory doesn't bear out in real world. My company is technology consultancy solely focused on Free / Open Source software. We sell no products or hardware, only services ranging from software development to network integration to training, and broke a million in sales last year. We are on track to doubling that this year.
We do about 50/50 government and commercial work. Our rates are currently as high or higher than other competing commercial software focused consultants. We find that our specialization has actually created a high value niche. I don't expect the pricing structure to stay this way forever as more companies pursue our model. We do not need your theory's high software "cover" pricing to charge 200 an hour. We are very good at what we do, our customers come back again and again.
Any enterprise must pay for support and integration. It doesn't matter if the product is free or not. The value is shifting from the product to the reputation of the solution integrator. Nice try, but theory's only work until something clearly happening in the real world proves them wrong...