The Simple Economics of Open Source

HBS Working Knowledge: Technology by Martha Lagace, Senior Editor: "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?

Lerner and Tirole's research focused on three particular cases: those of Apache, Perl and Sendmail

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).

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.

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.

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.

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.

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."

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?

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."