Back to Eric's Home Page Up to Site Map $Date: 1998/02/23 23:32:39 $

The Economics of Open-Source Software

In the last section of The Cathedral and the Bazaar, I suggest that the bazaar development mode may be so much more effective than the cathedral mode that open-source software may eventually drive closed, proprietary software almost completely out of the market.

Richard Stallman I am not. I believe in strong intellectual-property rights. I believe any programmer has the same fundamental right as any other producer to `hoard' and sell the fruits of his/her labor on whatever terms the market will bear. While I choose to publish nearly all of my software as open-source, I will never, ever condemn others for choosing differently.

Nevertheless, I suspect that in the future selective pressures for higher-quality software will favor the open-source model so heavily that closed or `shrouded' software becomes the exceptional case. Indeed, there are some kinds of software (including many mission-critical Internet tools such as DNS) for which this is already true.

Can Programming Survive?

When I say this in public, I'm often asked three big questions and a fourth tactical one:

  1. How can I make a living programming open-source software?

  2. If the open-source model wins out, will programmers starve?

  3. Can corporations and investors earn good returns on open-source?

  4. Who should we be trying to convert first? and how?
I don't have final answers. But I have been thinking about the question enough to make some suggestions.

How can I make a living programming open-source software?

There are companies making money programming open-source software right now. Red Hat, Cygnus, and Caldera are three of the best known. There are others.

If the open-source model wins out, will programmers starve?

I don't think the triumph of open-source would doom anyone to starvation. But to understand why not, we need to take a fresh look at the economics of software and the work that programmers actually do.

Computer programs have three kinds of economic value. They have use value, market value, and monopoly value.

The use value of a program is its economic value as a tool. The market value of a program is its value as a saleable commodity. The monopoly value is the value you gain not just from having the use of a program but from having it be unavailable to your competitors.

The standard nightmare programmers have about open source is what I call the "Open-Source Doomsday" scenario. This starts with the market value and monopoly value of software going to zero because of all the free sources out there. Use value alone doesn't attract enough consumers to support software development. The commercial software industry collapses. Programmers starve or leave the field. Doomsday arrives when the open-source culture itself (dependent on the spare time of all these pros) collapses, leaving nobody around who can program competently. All die. Oh, the embarrassment!

People who worry about `Open Source Doomsday' have lost sight of one fundamental fact: If having a program written is a net economic gain for a customer over not having it written, a programmer will get paid whether or not the program is going to be free after it's done.

The doomsday scenario also rests on several shaky assumptions:

Programming will collapse if software has no market value

Very unlikely. Code written for resale is only the tip of the programming iceberg. It used to be said that 85% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case (and a good thing; who in their right mind wants to wear a tie and grind out huge volumes of COBOL?) but most estimates put the proportion of all code written in-house at companies other than software vendors at over 75%.

This "vertical" code includes most of the stuff of MIS, the financial- and database-software customizations every every medium and large company needs. It includes technical-specialist stuff like device drivers (nobody tries to make money selling device drivers!). It includes all kinds of embedded code for our increasingly microchip-driven machines -- from machine tools an jet airliners to cars to microwave ovens and toasters.

Most vertical code is integrated with its environment in ways that make reusing or copying it very difficult. (This is true whether the `environment' is an 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 "maintainance", and any software engineer or systems analyst will tell you that it makes up the vast majority of what programmers get paid to do. And it will still need to be done even when most software is open-source.

Between originating, customizing and maintaining vertical code (and related tasks like system administration and troubleshooting), the use value of software would still support the millions of good jobs in that 75% even if all "horizontal" or standalone software were free.

So even if we make absolute worst-case assumptions about the other factors in the "Open Software Doomsday" scenario, only at most 25% of the programming profession is exposed. As we'll see, the actual exposure is probably much lower.

Open-source software has no market value

We know this isn't true. Probably the purest demonstration today is Red Hat, which has built a flourishing business selling software you can download for free from Red Hat's own web site! Red Hat's sales are doubling every year.

What you're really buying from them is handholding and support for the ``free'' stuff they sell -- a single place to go when you have problems. In 1998 there are probably close to a dozen companies working this model successfully.

Open-source software has no monopoly value

Even this may not be true. Adopting or even just studying someone else's software is not a costless, frictionless process; you need to dedicate skilled time to it. As product cycle times drop, coattail-riding gets less attractive, because the payoff period shrinks relative to the time you had to dedicate. And time your skilled people spend studying someone else's "monopoly" code is time you're spending getting to whether the competition used to be (rather than where they are now).

Probably there still will be some trade-secret monopoly software in the future, in the few cases where it confers a stable long-term advantage. Petroleum companies, for example, might have good reasons not to share the data-analysis routines they use to map oilfields.

But it's really fairly hard to think of a lot of other applications in which software trade secrets have more value than the rather high purchase, integration, and maintainance costs of closed software. For the office-business market that supports most commercial software, it's hard to even imagine what such "monopoly" secret techniques might be like. Doing spreadsheet recalculations, addressing bulk mailings and computing payrolls are not deep problems; we probably have public algorithms for these now that are as good as we're going to get.

The Business Case for Open Source

All right, so ``Open Source Doomsday'' doesn't seem very likely. Programmers can work on open source without fearing it will doom them to poverty. What, then, is the positive economic case for open-source software? Can corporations and investors earn good returns on it?

Reliability

The general business case for open-source is reliability. Open-source software is peer-reviewed software; it is more reliable than closed, proprietary software. Mature open-source code is as reliable as software ever gets.

Businesspeople sometimes boggle when one points this out. Many have a prejudice that open-source software is not `professional', that it is less reliable than closed software.

Again, the Internet's infrastructure makes the best possible case for this. Consider DNS, sendmail, the various open-source TCP/IP stacks and utility suites, and the open-source scripting languages such as Perl that are behind most "live" content on the Web. These are the running gears of the Internet. They have demonstrated a level of reliability and robustness under rapidly changing conditions (including a huge and rapid increase in the Internet's size) that, considered against the performance record of even the best closed commercial software, is nothing short of astonishing.

I developed the argument for the superior reliability of open-source in general in The Cathedral and the Bazaar, and won't rehash it here.

But the implication of this case is clear. Eventually, bazaar-mode peer review will come to be considered a necessary condition for highest quality. In many market niches, software that has not been peer-reviewed simply won't be perceived as good enough to compete.

Competitive Advantage

The bazaar mode seems to reverse our normal expectations about software development; more programmers are better (at least, as long as the capacity of the project leader or project core group to handle integration isn't exceeded). Even a small bazaar project can muster more brains to improve a piece of software than most development shops can possibly afford.

It follows that commercial developers leveraging the bazaar mode should be able to grab, and keep, a substantial advantage over those that don't. But there's more; the first commercial developer in a given market niche to switch to this mode may gain substantial advantages over later ones.

Why? Because the pool of talent available for bazaar recruitment is limited. The first bazaar project in a given niche is more likely to attract the best co-developers to invest time in it. Because they've invested the time, they're more likely to stick with it.

Lower Overhead

Switching to the open-source model should also be good for a significant reduction in software production costs.

The open-source model will allow software shops to (in effect) outsource some of their work, paying for it in values less tangible than money. (But perhaps not less economically significant; one such value will be the increased speed with which an outside co-developer can have a needed bug fix, which will often translate into a substantial opportunity gain.) This means smaller shops will be able to handle bigger projects. It does not necessarily mean the software sevelopment industry as a whole will shed paying jobs; with programming talent as scarce relative to demand as it has been, it probably just means more commercial projects will be able to find bodies.

Where To Try First

So to our tactical question: who to try first. That is, what companies (or classes of companies) should be able to see a clear near-term benefit in the open-source model

Thinking about this, I believe I've identified three niches:

  1. Support Sellers

    In this model, you (effectively) give away the software product, but sell distribution, branding, and after-sale service. This is what (for example) Red Hat and Cygnus Support are doing.

  2. Loss Leader

    In this model, you give away open-source as a loss-leader and market positioner for closed software. This is what Netscape is doing.

  3. Widget Frosting

    In this model, a hardware company (for which software is a necessary adjunct but strictly a cost rather than profit center) goes open-source in order to get better drivers and interface tools cheaper.

The open-source culture's shining exemplars of commercial success have, so far, been service sellers or loss leaders. Nevertheless, it is my opinion that our best near-term prospects for recruiting corporations into the open-source camp is among the hitherto neglected category of widget-makers.

If you are Logitech or 3COM or Intel, you don't really want to be in the software business. Your expertise, your culture, your corporate identity are all organized around manufacturing hardware. Unfortunately, almost nobody likes a naked widget. You have to build some software to wrap around your hardware, even though you never make money on the software itself.

This is ideal conditions for the open-source pitch. For a trifling money investment, any random widget maker could build up a community of interest more than willing to assist in its software development. Start with a web site full of specifications and driver sources; add a few technical contact people with a good attitude and decent communications skills; stir briskly with a mailing list and news server. Voila! Instant bazaar.

In discussing the open-source model with people who know that part of the industry, one objection keeps coming up over and over again. Many widget-makers fear that unshrouding their specs and drivers would enable competitors to reverse-engineer their hardware.

The effective 1998 response to this is "So what?" My previous reasoning about software monopoly value applies. With product cycles as short as they are now, cloning is probably a losing strategy.

Where We Go From Here?

In the above, I think I've shown that the open-source model will not be a death-knell for paying programming jobs. I hope I've shown that open-source will eventually out-compete closed, proprietary software. And I've suggested tactics to speed that day.

But I'm not stupid enough to believe I have all the answers. And I certainly don't have all the contacts I need to get to the CEOs and CTOs of the world and persuade them to join the open-source camp.

I welcome your comments on my analysis, and doubly welcome any avenues to corporate decision-makers you may be able to offer.


Back to Eric's Home Page Up to Site Map $Date: 1998/02/23 23:32:39 $

Eric S. Raymond <esr@snark.thyrsus.com>