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.