This paper was one of the first examinations of the important open source phenomenon (please see below for a discussion) from an economics perspective. The decision to freely contribute software may seem initially quite mysterious to an economist. In our work, though, Jean Tirole and I argued that standard frameworks of labor economics could be adapted to capture activity in the open source environment.

A programmer working on an open source software development project incurs a variety of benefits and costs, which she weighs against each other. The programmer incurs an opportunity cost of her time. This has two dimensions. First, a programmer who would work as an independent on open source projects would forgo the monetary compensation she would receive if she were working for a commercial firm or a university. Second, for a programmer with an affiliation with a commercial company, a university or research lab, the opportunity cost is the cost of not focusing on her primary mission. For example, the academic’s research output may sag and the student’s progress towards a degree slows down.

“This paper was one of the first examinations of the important open source phenomenon...from an economics perspective.”

Two immediate benefits may counter this cost. First, the programmer, when fixing a bug or customizing an open source program, may actually improve rather than reduce her performance in the mission endowed upon her by her employer. This is particularly relevant for system administrators looking for specific solutions for their company. Second, the programmer compares how enjoyable the mission set by the employer and the open source alternative are. A "cool" open source project may be more fun than a routine task.

There are also two distinct, although hard-to-distinguish, delayed rewards from participating in open source projects. The career concern incentive refers to future job offers, shares in commercial open source-based companies, or future access to the venture capital market. The ego gratification incentive stems from a desire for peer recognition.

Probably most programmers respond to both incentives. There are some differences between the two. The programmer mainly preoccupied by peer recognition may shun future monetary rewards, and may also want to signal her talent to a slightly different audience than those motivated by career concerns. From an economic perspective, however, the incentives are similar in most respects.

To compare programmers’ incentives in the open source and proprietary settings, we examine how the fundamental features of the two environments shape the incentives just reviewed. We will first consider the relative short-term rewards, and then turn to the deferred rewards.

Obviously, commercial projects have an edge on the current-compensation dimension because the proprietary nature of the code generates income. This makes it privately worthwhile for private companies to offer salaries. This contention is the old argument in economics that the prospect of profit encourages investment, which is used, for instance, to justify the awarding of intellectual property rights to encourage invention.

By way of contrast, an open source project may well lower the cost for the programmer, for two reasons. The first is an alumni effect. Because the code is freely available to all, it can be used in schools and universities for learning purposes; so it is already familiar to programmers. This reduces their cost of programming. Second, and as we have already noted, the cost of contributing to an open source project can be offset if the activity brings about a private benefit (the ability to fix bugs and customize the product to ones own ends) for the programmer and her firm. Note again that this factor of cost reduction is directly linked to the openness of the source code.

When we consider the delayed reward (signaling incentive) component, the open source process also has some benefits over the closed source approach. As we noted, signaling incentives are stronger, the more visible the performance and the more attributable the performance to a given individual. Signaling incentives therefore may be stronger in the open source mode for three reasons.

“A 'cool' open source project may be more fun than a routine task.”

First, in an open source project, the 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 forth. Second, the open source programmer is her own boss and takes full responsibility for the success of a subproject she works on, with little interference from a superior. Finally, since many elements of the source code are shared across open source projects, more of the knowledge they have accumulated can be transferred to new environments).

Open source software, which involves developers at many different locations and organizations sharing code to develop and refine computer programs, has increased dramatically over the past decade. This growth can be illustrated by considering a few representative categories:

Web servers: The open source Apache project has dominated the web server market since the inception of systematic tracking by Netcraft.

Operating systems: Statistics compiled by Google suggest that Linux has only a modest (though increasing) share of the desktop operating system market. But a recent survey of chief information officers suggests that Linux will play an increasingly important role in this market going forward.

Embedded systems: A survey of developers by Evans Data Corporation suggests that Linux has rapidly outstripped Windows as the operating system most frequently embedded into products ranging from mobile phones to video recording devices.

Databases: The dissemination of open source databases remains in its infancy, but these are projected to become significant challengers to commercial systems sold by firms such as IBM and Oracle

Other categories: SourceForge lists well over 100 thousand open source projects. Many of these projects are nascent, but a considerable number dominate their respective categories: e.g., PERL and PHP are the dominant scripting languages.

Besides this rapid growth, the increased academic interest in open source software has also been stimulated by the fact that the open source production process is seemingly very different from other forms of innovation. Many of the contributors to open source projects are unpaid. Contributions are made under licenses that often restrict the ability of contributors to commercialize their own contributions. Open source projects themselves are often loosely structured, with contributors free to pursue whatever area they feel most interesting.

In recent works, we are focusing on one (though surely not the only) broader implication of open source software: the economics of technology sharing. Corporations benefit in several ways from participating in open source projects:

Solving the pricing commitment problem. In many settings with powerful network effects, users may be unwilling to commit to a particular innovator’s technology, lest they find themselves vulnerable to being "held up" later on. By making the code available under an open source license, the innovator commits to make the program available at no or low cost and overcomes this problem.

Allowing low-price combinations of intellectual property. "Patent thickets" are frequent concern in many high-technology industries. When multiple firms have overlapping intellectual property rights, obtaining the freedom to pursue innovation in a given technology may be daunting.

If most patent-holders are willing to license their patents covering a given technology on reasonable terms, there is a strong temptation for the last licensor to extract much of the surplus by demanding a high fee. By contributing code to an open source project to which others will also make additions, the firm insures that combinations of intellectual property will be possible.

Certifying new technologies. In many cases, open source projects’ leadership teams play a critical role in choosing between technological alternatives. If the project leadership has sufficient credibility in the software community, firms may contribute software to open source in order to benefit from their endorsement, as the HP case discussed above illustrates.

While contributions to open source projects are one way in which firms can solve these problems, other alternatives exist: Firms can blend their patents with others in a patent pool. These pools allow users to access a number of firms’ patents simultaneously, thereby avoiding the "patent thicket" problems. In many cases, the pooling agreements also specify the pricing schedule in the agreement that establishes the pool, addressing the pricing commitment problem. To be certain, patent pools raise a number of competition policy issues, but these can in part be addressed through a careful design of the pool (Lerner, and Tirole [2005]; Lerner, Strojwas, and Tirole [2007]).

Standard setting organizations play a number of roles, one of the most important being the certification of new technologies. Firms can seek an endorsement for an emerging technology by a variety of standards bodies. They may turn to an independent and prestigious one, especially if there are a variety of promising alternatives, or use a more complacent one (Lerner and Tirole [2006]). These bodies also help address the other concerns, frequently asking contributors of the key technologies to commit to license the technology on "reasonable and non-discriminatory" terms or to make various other concessions.

Self-imposed commitments can serve much the same role. For instance, firms can commit to license technologies at a given price schedule. Alternatively, they can commit to provide sufficient information so that users can tailor the technology. One open question about many of these self-initiated programs is the extent to which the commitments can be enforced if the firm subsequently changes its strategy.

A natural follow-up question is whether governments should encourage open source software. Government commissions and agencies have proposed—and in some cases implemented—a variety of measures to encourage open source developers. These have ranged from subsidies for open source developers developing programs to meet government needs or more generally, mandating the adoption of open source in public projects, and even mandated the development of localized open source projects. While a number of economic analyses have examined these issues, much more remains to be done.