We need to begin by noticing that computer programs like all other kinds of tools or capital goods, have two distinct kinds of economic value. They have use value and sale value.
The use value of a program is its economic value as a tool. The sale value of a program is its value as a salable commodity. (In professional economist-speak, sale value is value as a final good, and use value is value as an intermediate good.)
When most people try to reason about software-production economics, they tend to assume a `factory model' that is founded on the following fundamental premises.
1. Most developer time is paid for by sale value.
2. The sale value of software is proportional to its development cost (i.e. the cost of the resources required to functionally replicate it) and to its use value.
In other words, people have a strong tendency to assume that software has the value characteristics of a typical manufactured good. But both of these assumptions are demonstrably false.
First, code written for sale is only the tip of the programming iceberg. In the pre-microcomputer era it used to be a commonplace that 90% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case -- other industries are much more software-intensive now, and the finance industry's share of the total has accordingly dropped -- but we'll see shortly that there is empirical evidence that around 95% of code is still written in-house.
This code includes most of the stuff of MIS, the financial- and database-software customizations every medium and large company needs. It includes technical-specialist code like device drivers (almost nobody makes money selling device drivers, a point we'll return to later on). It includes all kinds of embedded code for our increasingly microchip-driven machines - from machine tools and jet airliners to cars to microwave ovens and toasters.
Most such in-house code is integrated with its environment in ways that make reusing or copying it very difficult. (This is true whether the `environment' is a business office's set of procedures or the fuel-injection system of a combine harvester.) Thus, as the environment changes, there is a lot of work continually needed to keep the software in step.
This is called `maintenance', and any software engineer or systems analyst will tell you that it makes up the vast majority (more than 75%) of what programmers get paid to do. Accordingly, most programmer-hours are spent (and most programmer salaries are paid for) writing or maintaining in-house code that has no sale value at all -- a fact the reader may readily check by examining the listings of programming jobs in any newspaper with a `Help Wanted' section.
Scanning the employment section of your local newspaper is an enlightening experiment which I urge the reader to perform for him- or herself. Examine the jobs listings under programming, data processing, and software engineering for positions that involve the development of software. Categorize each such job according to whether the software is being developed for use or for sale.
It will quickly become clear that, even given the most inclusive definition of `for sale', at least nineteen in twenty of the salaries offered are being funded strictly by use value (that is, value as an intermediate good). This is our reason for believing that only 5% of the industry is sale-value-driven. Note, however, that the rest of the analysis in this paper is relatively insensitive to this number; if it were 15% or even 20%, the economic consequences would remain essentially the same.
(When I speak at technical conferences, I usually begin my talk by asking two questions: how many in the audience are paid to write software, and for how many do their salaries depend on the sale value of software. I generally get a forest of hands for the first question, few or none for the second, and considerable audience surprise at the proportion.)
Second, the theory that the sale value of software is coupled to its development or replacement costs is even more easily demolished by examining the actual behavior of consumers. There are many goods for which a proportion of this kind actually holds (before depreciation) -- food, cars, machine tools. There are even many intangible goods for which sale value couples strongly to development and replacement cost -- rights to reproduce music or maps or databases, for example. Such goods may retain or even increase their sale value after their original vendor is gone.
By contrast, when a software product's vendor goes out of business (or if the product is merely discontinued), the maximum price consumers will pay for it rapidly goes to near zero regardless of its theoretical use value or the development cost of a functional equivalent. (To check this assertion, examine the remainder bins at any software store near you.)
The behavior of retailers when a vendor folds is very revealing. It tells us that they know something the vendors don't. What they know is this: the price a consumer will pay is effectively capped by the expected future value of vendor service (where `service' is here construed broadly to include enhancements, upgrades, and follow-on projects).
In other words, software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.
It is worth examining why we normally tend to believe otherwise. It may simply be because the small portion of the software industry that manufactures for sale is also the only part that advertises its product. Also, some of the most visible and heavily advertised products are ephemera like games that have little in the way of continuing service requirements (the exception, rather than the rule) [SH] .
It is also worth noting that the manufacturing delusion encourages price structures that are pathologically out of line with the actual breakdown of development costs. If (as is generally accepted) over 75% of a typical software project's life-cycle costs will be in maintenance and debugging and extensions, then the common price policy of charging a high fixed purchase price and relatively low or zero support fees is bound to lead to results that serve all parties poorly.
Consumers lose because, even though software is a service industry, the incentives in the factory model all cut against a vendor's offering competent service. 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 center, will become a dumping ground for the least effective and get only enough resources to avoid actively alienating a critical number of customers.
The other side of this coin is that most vendors buying this factory model will also fail in the longer run. Funding indefinitely-continuing support expenses from a fixed price is only viable in a market that is expanding fast enough to cover the support and life-cycle costs entailed in yesterday's sales with tomorrow's revenues. Once a market matures and sales slow down, most vendors will have no choice but to cut expenses by orphaning the product.
Whether this is done explicitly (by discontinuing the product) or implicitly (by making support hard to get), it has the effect of driving customers to competitors (because it destroys the product's expected future value, which is contingent on that service). In the short run, one can escape this trap by making bug-fix releases pose as new products with a new price attached, but consumers quickly tire of this. In the long run, therefore, the only way to escape is to have no competitors -- that is, to have an effective monopoly on one's market. In the end, there can be only one.
And, indeed, we have repeatedly seen this support-starvation failure mode kill off even strong second-place competitors in a market niche. (The pattern should be particularly clear to anyone who has ever surveyed the history of proprietary PC operating systems, word processors, accounting programs or business software in general.) The perverse incentives set up by the factory model lead to a winner-take-all market dynamic in which even the winner's customers end up losing.
If not the factory model, then what? To handle the real cost structure of the software life-cycle efficiently (in both the informal and economics-jargon senses of `efficiency'), we require a price structure founded on service contracts, subscriptions, and a continuing exchange of value between vendor and customer. Under the efficiency-seeking conditions of the free market, therefore, we can predict that this is the sort of price structure most of a mature software industry will ultimately follow.
The foregoing begins to give us some insight into why open-source software increasingly poses not merely a technological but an economic challenge to the prevailing order. The effect of making software `free', it seems, is to force us into that service-fee-dominated world -- and to expose what a relatively weak prop the sale value of closed-source bits was all along.
The term `free' is misleading in another way as well. 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% of programmers now compensated by sale-value would be unlikely to suffer in an open-source world. The people who lose in the transition won't be programmers, they will be investors who have bet on closed-source strategies where they're not appropriate.