16 May 2000  Research & Ideas

The Simple Economics of Open Source

What motivates thousands of computer programmers-and even the companies that employ them-to share their code with the world? The growing use of so-called "open source" software may not seem, at first glance, to make much economic sense. But according to research by HBS Professor Josh Lerner and his colleague Jean Tirole, economics may actually help explain why open source works as well as it does.


Why in the world would anyone take the time to write complicated software programs for free?

It's a good question, one that has piqued the curiosity of a number of economists, who wonder what benefits, if any, lie behind the burgeoning "open source" movement in technology.

After all, outwardly the situation smells of economic anarchy. Where are the market forces, when thousands of talented programmers—and even many commercial firms—spend inordinate amounts of time writing and sharing computer source code: an activity that apparently gives the individuals and companies involved no pay-off, no reward?

Could it be driven, as some media reports have admiringly suggested, purely by intellectual fervor on the part of programmers, perhaps coupled with a noble desire to share and dispense knowledge to benefit mankind?

Not so fast, say HBS Professor Josh Lerner and his colleague Jean Tirole, an economist at the University of Toulouse and the Massachusetts Institute of Technology. In their new working paper, "The Simple Economics of Open Source," Lerner and Tirole make the case that an idealistic notion of programmer altruism only goes so far. After all, the pair argues, generosity and knowledge-bearing have not really been guiding factors in other industries: so why would they dominate the computer field?

Instead, they suggest, laboring on open source brings developers and companies specific, tangible and very favorable economic benefits: benefits that are sensible, potentially quite lucrative and, in a word, simple. Altruism is just a nice by-product.

Looking for drivers

The phenomenon of open source has roots in a long tradition of sharing and cooperation in software development (see "A Long Tradition"), but Lerner and Tirole's research focused on three particular cases: those of Apache, Perl and Sendmail (see "The Fathers of Invention"). In addition to wading through printed interviews and materials, and conducting face-to-face discussions with key players in the development of open source, they also queried knowledgeable observers.

What Lerner and Tirole learned has led them to suggest ways that the commonly espoused motivations of programmers might be different when people work on open source projects as opposed to "closed" projects.

Economic theory, they write, tells us that programmers participate in a project when they derive a net benefit from the work, with net benefit based on both immediate and delayed rewards. Immediate rewards include monetary compensation, as well as the opportunity to fix a bug or customize a program for their own benefit.

Delayed rewards, what Lerner and Tirole call the "signaling incentive," include the "career concern incentive" which refers to future job offers, shares in commercial open source-based companies or future access to venture capital, and the "ego gratification incentive," focused on a desire for peer recognition. Though different in some regards, both have been shown to be stronger when the work is visible to people the programmer wants to impress (colleagues, venture capitalists, the overall job market).

With immediate rewards, commercial projects have an edge as far as money goes—the proprietary nature of the code generates income, making it possible for firms to reward programmers with salaries. But open source projects carry two advantages that commercial projects can't match. One is the "alumni effect": programmers are already used to working with the open code from their time in schools and universities, where it was freely available; they are able to build on knowledge they already possess. And, two, programmers welcome the opportunity, made possible by open source, to customize and de-bug projects, either for personal use or to make their job easier at their firm.

Strengthening the signaling incentive

But the real advantage of open source, Lerner and Tirole discovered, is in the delayed or signaling incentives, where the visibility of the programmer's contribution counts most.

Open source projects measure individual performance better. In a commercially created program, outsiders can't really tell who did what. Open source is different. As Lerner and Tirole write, "Outsiders are able to see not only what the contribution of each individual was and whether that component 'worked,' but also whether the task was hard, if the problem was addressed in a clever way, whether the code can be useful for other programming tasks in the future," and so on.

In open source, a programmer is his or her own boss and can take full responsibility for the success or failure of a task. Programmers in typical commercial projects, by contrast, need to work with (or around) their supervisor; the individual contribution is harder to measure.

Finally, in open source people have greater flexibility when moving from project to project, building up knowledge and "tools" as they go. By contrast, in commercial firms people are restricted by proprietary code specific to that firm. So in a sense they have to start all over again when they switch jobs.

In their working paper, Lerner and Tirole also point out that people in open source can use their projects as a "port of entry." For example, a systems administrator at a small college (who might be a user of open source as well as a contributor to it) can "signal" her talent to many people in a position to influence her future career: colleagues, prospective employers and, especially, venture capitalists.

The venture capital attraction is also a strong one, Lerner and Tirole found. Open source work may be a great stepping stone to future venture capital. The open source environment made it possible, for instance, for the founders of Sun, Netscape and Red Hat, to show other people what they were made of.

Companies jump aboard

Commercial firms have not failed to notice the success of open source projects. Their strategies for capturing some of this energy usually fall into one of two strategies, say Lerner and Tirole.

In what they call the "reactive" strategy, commercial firms try to bundle paid services and products onto open source programs, to fill a niche. These services and products are either not provided at all by open source or are not handled very efficiently. "The company expects to … boost its profit on a complementary segment," write Lerner and Tirole.

In the second strategy, companies embrace the open source movement by releasing some of their own proprietary code, in the hopes that this will lead to greater value down the road thanks to new kinds of cooperation. As Lerner and Tirole explain, "This is similar to giving away the razor (the released code) to sell more razor blades."

This mixing of open and closed source code is not without risks, they point out. In the lingo of the field, an open source project can easily be "hijacked" when an unscrupulous programmer modifies a module and then effectively imposes a proprietary new platform, whisking away some prime benefits of the original program.

Lerner and Tirole also draw an analogy to academe, writing that commercial interests can easily preclude creativity and intellectual exploration if programmers become too fixated on exciting, short-term commercial goals.

Puzzles for the future

The open source movement leaves several questions for economists to contemplate in the future, say Lerner and Tirole. How, for instance, will the breaking of projects into modules help or hurt open source? The success of an open source project seems dependent on the ability to break down the project into distinct components; yet as projects move beyond their Unix origins, will emerging languages continue to accommodate this modularization?

Lerner and Tirole also wonder whether open source projects can handle so many contributors jumping on the bandwagon. How will project leaders sift through all the submissions, many of which are only of fair-to-negligible value?

And finally, can open source projects expect to live longer than commercial ones? The jury remains out on that question too, write Lerner and Tirole. Since open source code is freely available, programs can probably live so long as people are attracted to their inherent challenges. But fads erupt in open source as in any other field, and developers who flock to high-profile projects—for the aforementioned visibility, future access to venture capital, etc.—could well abandon worthy but less glamorous projects before their time.

"Our ability to answer confidently these and related questions," predict Lerner and Tirole, "is likely to increase as the open source movement itself grows and evolves." In the meantime, the two professors venture their hope that such puzzles will inspire and stimulate other researchers to look into the issues themselves, and share their suggestions — in true open source style.

Download the complete working paper, "The Simple Economics of Open Source" in PDF format.

Open Source: The basics

Open source brings many cooks into the kitchen of a particular project. In open source software development, programmers may not even know each other—they may in fact be working in different companies and/or on opposite sides of the globe—yet they can join forces to refine any program that interests and excites them as individuals.

That's because the basic operating code of the computer programs is "open": the source code is openly shared, making it readily understandable and easy to modify.

The success of an open source project depends on the ability to divide it into segments or modules so that programmers can tinker with different parts of the chain without affecting the program as a whole. Usually, a leader or leadership group is in charge of a project, and while all or most suggestions that arrive may be considered, the code can be physically altered only by a few individuals or by the project leader.

"Closed" code, on the other hand, the kind under strict licensing control by the majority of commercial firms, is more of a secret language, since it is shared, if at all, in binary code designed for interpretation by the computer, but not easily interpreted—let alone modified—by other programmers.

A Long Tradition

The open source revolution has received a lot of attention in recent years. This is thanks in part to the explosion in Internet activity and the popular success of programs such as Apache, Perl, Linux, Sendmail and others. But code-sharing has enjoyed a long tradition among programmers, beginning in computer science labs at MIT and Berkeley as far back as the early 1960s, when programmers worked in relative autonomy.

Two of the most important elements of the open source movement, the Unix operating system and the C language, emerged from a commercial enterprise, AT&T's Bell Laboratories. A further spur to open source was the Free Software Foundation that maverick Richard Stallman began at MIT in 1983. Stallman's Foundation promoted and freely distributed cooperatively developed software, and introduced a formal licensing system, the General Public License (GPL, or "copylefting"). The GPL dictated, in part, that users of the software had to agree to make source code available and could not burden other programmers with licensing restrictions.

These GPL rules had generally given way to a more flexible stance by 1995. One group, working under the umbrella of the Open Source Initiative, developed an "Open Source Definition," which still holds sway:

License Must Not Contaminate Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. Rationale: Distributors of open-source software have the right to make their own choices about their own software.

The Fathers of Invention

Open source software usually begins with one frustrated programmer and a Eureka-like epiphany. Here are three "mini-cases" of important inventions cited by Lerner and Tirole in their working paper.


Called "the duct-tape of the Internet," the versatile Perl is a popular Web programming language whose name stands for Practical Extraction and Reporting Language.

Perl began in 1987 when Larry Wall, then working for a mainframe manufacturer – Burroughs, now part of Unisys – became frustrated by tedious, repetitive tasks in systems administration. It occurred to him that a program language which could bridge the gap between the C and Unix "shell" languages would speed things up tremendously as well as dispense with a greater variety of systems administration duties.

Since the launch of Perl in 1987 via the Internet, it has become a widely accepted language in competition with Java, the open source program Python, and two Microsoft programs: Visual Basic and ActiveX. Perl is administered by 10 to 20 programmers known as the "perl-5-porters," and is estimated to have one million users.


A Web server software competing with those of Microsoft and Netscape, Apache was started in 1994 by programmer Brian Behlendorf.

Behlendorf, then 21, had been charged with running one of the first commercial Internet servers in the U.S., the one behind Wired magazine's Web site. His server used Unix-based software – with free source code—from the National Center for Supercomputer Applications (NCSA) at the University of Illinois.

Whenever Behlendorf and developers wrote amendments or "patches" to the NCSA server, though, they found NCSA staff to be rather lax in responding. (A certain amount of distraction was understandable: some NCSA people were departing to start Netscape.)

Via a mailing list, Behlendorf and crew invited other Internet technology enthusiasts to suggest patches to the NCSA server software. These patches could be physically inputted only by a chosen few, and Apache 0.8 was born in August 1995. According to surveys of publicly available Web servers, Apache is run on 55 percent of them.


Like Larry Wall with Perl, Eric Allman also needed to cross a divide between two incompatible computer networks—but he got an even earlier start.

In 1979, as a graduate student of computer science at the University of California at Berkeley, Allman developed a program called Delivermail to bridge incompatible e-mail systems on the Berkeley campus. Delivermail evolved by 1981 into Sendmail, and became the standard method for routing e-mail on the Arpanet (the predecessor to the Internet). However, by the 1980s and early 1990s it was clear that variations of Sendmail did not work well together and, write Lerner and Tirole, "in the argot of the open source community, the development of the program 'forked'" into different versions that no longer worked with one another.

Allman rewrote Sendmail in 1993, and by 1998 it was estimated that Sendmail was handling 80 percent of Internet e-mail traffic. Sendmail, Inc., the company he founded with financial support from Benchmark Capital, a major venture capital firm, actively encourages continuing development of the software on an open source basis, working with the nonprofit Sendmail Consortium.