May not be redistributed commercially without the author's permission.




Arnold Kling, "Arguing in My Spare Time", No. 9

March 14, 1998

The most popular Web server software, according to the survey taken by Netcraft (, is Apache. Apache is freeware. So is Linux, a version of the Unix operating system. The most popular Web browsers can be obtained at no charge.

If making the source code available to the public is the ultimate proof of commitment not to charge for software, then Netscape has taken that step with its browser. Hal Varian and Carl Shapiro commented on this in an op-ed piece in the Wall Street Journal, calling it a "judo" strategy--an attempt to counter a larger opponent.

Does software want to be free? Is there something about the economics of software that, Microsoft notwithstanding, makes it an inappropriate good for which to charge?

Among others, Brad Cox has pointed out the sense in which software pricing is artificial, particularly in the age of the Internet. You take a computer program that is purely intellectual, represented by bits, convert it to atoms via a disk or CD-ROM, then add more atoms in the form of cardboard and shrinkwrap, and then sell the atoms in stores. (Brad does not argue that software should be free, however. He suggests that pay-per-use in some cases might be a better model than pay-per-license.)

In terms of economic theory, software violates one of the fundamental postulates. This postulate states that if I consume more of something, then that leaves less of it for you to consume. If I consume more food, there is less for you. If I spend time consulting with a doctor, there is less of the doctor's time available for you.

With software, this postulate does not hold. I can use as many computer programs as often as I would like, and in no way does that constrain your ability to use those programs. In fact, it might be argued the opposite: the more that I use, say, PKZIP, the more valuable PKZIP becomes to another consumer.

Without this postulate, standard economic theory does not apply to software. In that sense, the usual theory of pricing does not hold. However, that does not mean that we can apply neither economics nor pricing to software. Economists have examined other goods that violate the "more for me means less for you" postulate, and this analysis has provided useful insights.

A general term for these sorts of goods is "public goods." The classic example of a public good is national defense. If we live in the same country, then you and I both can "consume" national defense at the same time. More for one of us does not mean less for the other.

Another example of a "public good" is broadcast television. Anyone with a television set can receive broadcast television, without paying the television stations. My reception does not adversely affect your reception. However, even though broadcast television is a "public good," we have developed a way for it to be provided profitably by private firms. The advertising model works in this case.

Television programs are costly to produce. Consumers "pay" for television programs by watching advertising.

Software programs are costly to write, test, and document. Should consumers "pay" for something other than the software itself?

One suggestion is that the programs will be free, but people will pay for support and service. However, this creates an adverse incentive: the better the program works and the easier it is to use, the less revenue is available from support and service.


In the Dilbert sector (government agencies, financial service companies, and other bureaucratic entities), most of the software that is developed is free. These organizations develop proprietary software to run their operations. Typically, there is no charge to use or license the software. This is true whether the software is used by internal or external customers. External customers that use software often receive it bundled in with whatever services the organization provides.

The Dilbert sector views the economic problem of software development as one of allocating staff to projects. The scarce resources are coders, testers, documenters, project managers, and so forth. There are an infinite number of systems projects that might be undertaken. The task is to allocate the staff resources to the most beneficial projects.

When the cost-benefit calculations are undertaken, either explicitly or implicitly, to determine which projects to attempt, the Dilbert sector does not think in terms of per-use pricing or per-license pricing for software. It thinks in terms of the overall benefit of the software, in terms of cost savings or revenue generated.

In theory, what the Dilbert sector is doing is making the benefit-cost calculations from a social point of view. Calculate total benefit to the organization (including its customers), and allocate staff if the total benefit exceeds the cost. This is exactly what the economics textbooks say is appropriate in order to allocate a "public good."

Internal allocation of staff in the Dilbert sector also solves some other economic problems in software. As alluded to earlier, the developer of a software product for sale faces some adverse incentives. The less you test and document the product, the less it costs you to develop. The incentive is to sell shoddy products, and that incentive that is reinforced if you also sell service and support for profit.

When a company develops proprietary software for its own use, the incentive to develop shoddy products is attenuated considerably. The costs of shoddy products are borne internally, and the internal MIS department does not usually earn "profit" from supplying support and maintenance services.


As readers of this essay series know, I do not believe that the Dilbert sector develops software efficiently. Moreover, as the common elements of software problems become more and more apparent, the inefficiency of "reinventing the wheel" in firm-specific software becomes increasingly costly.

I believe that the trend is for software to be developed by specialized firms and adapted for use by individual firms. However, pricing software by the license or on a per-use basis does not solve the resource allocation problem correctly.

The dilemma is that there are two types of inefficiency in software development:

(1) The pure software industry creates a pricing inefficiency: what is priced is the activity of obtaining a license to use the software; however, this activity should be free, because obtaining a license does not use up any scarce resources.

(2) The Dilbert sector creates operational inefficiency. It simply does a poor job of executing software development, and it spends too much time developing solutions for problems that can be solved by generic components.

In the next essay, I will elaborate on a solution to the problem of software efficiency: the "software club." The goal of a software club is to achieve a software development process that is as efficient as what can be found in specialized software firms, combined with a resource allocation mechanism that is similar to the "public good" cost-benefit analysis that takes place in the Dilbert sector.

The consumers (members) in a software club would be individuals. Businesses might acquire group memberships for their employees. A member might pay a fee to join the club, along with an annual or monthly fee.

A typical consumer might join 1 or 2 clubs. A large business might join 5 or 6. Each club might provide hundreds or even thousands of software products.

As a member of a software club, you could use all of the software offered by the club, as much as you like. Using software imposes no marginal cost on the club. On the other hand, using support and training does impose cost. Those latter activities would be priced (although a club might bundle a minimum level of free support along with membership).

I do not want to speak much about technical implementation, because that is not my area of expertise. I think of having a "smart card" that you can plug into any computer, which tells the computer who you are and to which clubs you belong. This smart card would enable you to use whatever software to which you are entitled.

As a consumer or a business, you would face a fixed monthly or annual charge for software. Your incentive would be to join the club or clubs that offer the best value.

The administrators of a software club would use their dues to pay in-house staff or supplier firms to develop, test, document, and support software. Software clubs that allocate their dues effectively will be popular. Those that do not produce the right software with the right amount of quality will fail.

Software clubs might resemble software download centers, such as were developed by CompuServe and America Online. On the Internet, CNET has developed such a center. However, unlike the shareware model now used by these download centers, revenue would come from a membership model.

Members will expect software clubs to filter their software, something that is not done very well by the online download services . I need one ftp program, not 50. If my software club is going to offer 50 ftp programs, they had better be able to guide me quickly and effectively to the one that most suits my needs.

A software club can be thought of as a mechanism for bundling many software products. It appears to me that Microsoft's strategic use of bundling is indicative of the validity of the economic model of the software club. A software club would make this bundling broader and more formal. In fact, given the "public good" character of software, bundling is almost certainly not a bad thing. The Justice Department notwithstanding, my guess as an economist is that we should want to encourage software bundling rather than discourage bundling.

The next essay will sketch out the software club idea in more detail.