Skip to main content

Open source software: Motivation and restrictive licensing


Open source software (OSS) is an economic paradox. Development of open source software is often done by unpaid volunteers and the “source code” is typically freely available. Surveys suggest that status, signaling, and intrinsic motivations play an important role in inducing developers to invest effort. Contribution to an OSS project is rewarded by adding one’s name to the list of contributors which is publicly observable. Such incentives imply that programmers may have little incentive to contribute beyond the threshold level required for being listed as a contributor. Using a unique data set we empirically examine this hypothesis. We find that the output per contributor in open source projects is much higher when licenses are less restrictive and more commercially oriented. These results indeed suggest a status, signaling, or intrinsic motivation for participation in OSS projects with restrictive licenses.

This is a preview of subscription content, access via your institution.


  1. Open source is different than “freeware” or “shareware.” Such software products are often available free of charge, but the source code is not distributed with the program and the user has no right to modify the program. Like other products based on intellectual property, the intellectual property in software is typically “licensed” for use, not sold outright. Someone who purchases a music CD buys the physical CD and the right to play the music under specific circumstances (which do not include the right to play it on the radio, etc). Software, whether proprietary or open-source, is similarly “licensed for use.”

  2. See for example Raymond (2000) and Stallman (1999).

  3. The open source model has changed somewhat recently and now some of the work is performed by employees of companies who support open source software. While it is true that even in 2001–2002, a non-trivial number of open source project programmers were being paid for their contributions, Ghosh et al. (2002) conclude that open source development was more like a hobby than a (paying) job. Our analysis, which was conducted using data from 2001–2002, focuses on the less well-known projects that were more likely to rely on volunteers.

  4. Hann et al. (2002) examine the Apache HTTP Server Project and find that contributions are not correlated with higher wages, but a higher ranking within the Apache Project is indeed positively correlated with higher wages. But such a correlation will occur whenever a higher ranking reflects higher productive capabilities of programmers.

  5. Johnson (2005) present a model in which the OSS organization structure is superior to that of proprietary development as it minimizes transaction costs and avoids agency problems.

  6. See also Hars and Ou (2001), Hertel et al. (2003). Using survey methods, these papers, respectively find that peer recognition and identification with the goals of the project are the main motivations for developers who contribute to open source software projects.

  7. The mean number of contributors is 83 in our sample.

  8. In the XFree86 project, for example, in order to become a developer, one must submit an accepted patch [see Halloran and Scherlis (2002)].

  9. Most of the empirical work in the literature has focused on case studies of individual well-known open source projects such as Linux and Apache. Hann et al. (2002) study the Apache web server, while Kuan (2002) examines the Apache web server, the Linux operating system, and the Gnome user interface. However, as Shah (2002) noted there may be potential differences between a relatively small group of well-known open source projects and the general population of open source projects. The projects in our sample do not include the well-known successful open source projects, such as Apache, Bind, Linux, Perl and Sendmail which are not hosted at SourceForge.

  10. Nevertheless, BSD-type licenses are not like commercial licenses, since commercial firms do not typically provide the source code to users, nor do they let users redistribute the code.

  11. The definition of the GPL as a relatively restrictive license follows Lerner and Tirole (2005).

  12. It would, of course, be interesting to know whether a small number of individuals made most of the contributions, but such information is not available for our data set. While the distribution about this average would add some additional information, the results using averages are quite striking, and they enable us to answer our primary research question.

  13. SourceForge lists activity levels for projects on its website. Activity level is an internal measure based on page views, downloads, Bugs, and Support Patches, etc. Hence, it is a measure that includes both inputs and outputs.

  14. We are grateful to NERA for providing us with the data. Although the projects were selected a couple of years before the data collection began, this does not cause a selection bias.

  15. According to “Cost Estimation and Project Management,” which is available at available at http:///, the most common measure of productivity is lines of code. Leppämäki and Mustonen (2003) use this measure as a proxy for output in their theoretical paper.

  16. All open source projects in our sample list their contributors’ email addresses, and the algorithm employed for counting contributors was designed to control for contributors who list multiple email addresses.

  17. The empirical results suggest that there is little difference between very restrictive and moderately restrictive licenses. Hence we generally use the variable RESTRICTIVE. Nevertheless, we also discuss how the results change when we delineate restrictive licenses into very restrictive and moderately restrictive licenses.

  18. Each project was rated by stage of production, ranging from 1 to 6. Nearly all of the projects in our sample were in stages 3–6. We employ the variable in this manner, because some projects listed multiple stages at a single point in time, while other projects listed a single stage. Only a few projects that listed a single stage at each point in time changed stages during our time period.

  19. Some of the programs in our sample are available in more than one (high level) programming language.

  20. The two projects were available under both licenses throughout the period for which we have data.

  21. It is our understanding that POSIX isn’t technically an operating system, but rather a set of standards. Nevertheless, we’ll refer to POSIX as an operating system. No projects were written for both LINUX and POSIX operating systems.

  22. Lerner and Tirole (2005) find that the activity level is higher for projects “that are not highly restrictive and (on a less consistently statistically significant basis) not restrictive.” Since “activity” is a mixture of both input and output, it is hard to compare this with our main result. Lerner and Tirole (2005) do not have data on lines of code.

  23. There are a few well-known cases in which the license type was changed, but no changes in license type were made in the projects in our sample.

  24. The Breusch and Pagan (BP) Lagrange multiplier test and the Hausman (HM) specification test indicate that the random effects model is appropriate. The results are robust to using maximum likelihood estimation or generalized least squares (GLS) estimation. In order to be concise, we report only the GLS results.

  25. Of course in this case, SINGLE OS has to be excluded due to multicollinearity.

  26. Another possibility is that projects that have chosen a restrictive license are perhaps more “community-oriented” and thus more generous in giving recognition than commercial projects.

  27. The regressions in Tables 4 and 5 show that the POSIX effect is similar in magnitude to the LINUX effect.

  28. It is our understanding that Perl uses both a BSD-type license and a GPL license.


  • Bonaccorsi A, Rossi C (2002) Licensing schemes in the production and distribution of open source software: an empirical investigation available at

  • Ghosh R, Glott R, Krieger B, Robles G (2002) Free/libre and open source software: survey and study. Part IV. Survey of developers. FLOSS Report, International Institute of Infonomics, University of Maastricht, The Netherlands (available at

  • Halloran T, Scherlis W (2002) High quality and open source software practices. Proceedings from the 2nd Workshop on Open Source Software Engineering, Orlando, FL (mimeo, available at

  • Hann I, Roberts J, Slaughter S (2002) Delayed returns to open source participation: an empirical analysis of the apache HTTP Server Project. Carnegie Mellon University mimeo

  • Harhoff D, Henkel J, von Hippel E (2003) Profiting from voluntary spillovers: how users benefit by freely revealing their innovations. Res Policy 32:1753–1769

    Google Scholar 

  • Hars A, Ou S (2001) Working for free?—motivations for participating in open source projects. Int J Electron Commer 6:25–39

    Google Scholar 

  • Hertel G, Niedner S, Herrmann S (2003) Motivation of software developers in open source projects: an internet-based survey of contributors to the Linux kernel. Res Policy 32:1159–1177

    Article  Google Scholar 

  • Johnson J (2002) Open source software: private provision of a public good. J Econ Manage Strategy 11:637–662

    Article  Google Scholar 

  • Johnson J (2005) Collaboration, peer review and open source software. Cornell University mimeo

  • Kuan J (2002) Open source software as lead user’s make or buy decision: a study of open and closed source quality. Stanford Institute for Economic Policy Research mimeo

  • Lakhani K, Wolf R (2005) Why hackers do what they do: understanding motivation and efforst in free open source projects, In: Feller/Open, Fitzgerland J, Hissam S, Lakhani K (eds) Perspectives on free and open source software. Cambridge, MIT

  • Leppämäki M, Mustonen M (2003) Spence revisited—signaling with externality: the case of open source programming. Discussion Paper 558, University of Helsinki

  • Lerner J, Tirole J (2002) Some simple economics of open source. J Ind Econ 52:197–234

    Google Scholar 

  • Lerner J, Tirole J (2005) The scope of open source licensing. forthcoming, Journal of Law, Economics and Organization 21:20–56

    Google Scholar 

  • Raymond E (2000) The cathedral and the bazaar.∼esr/writings/cathedral-bazaar/cathedral-bazaar/

  • Shah S (2002) A summary of ‘open source software as lead user’s make or buy decision: a study of open and closed source quality. TIIP Newsletter.

  • Stallman R (1999) The GNU operating system and the free software movement. In: Dibona C, Ockman S, M Stone (ed) Open sources: voices from the open source movement. O’Reilly, Sepastopol, CA.

Download references


We are grateful to an anonymous referee, the editors, Guenter Knieps and Ingo Vogelsang, and to Judith Chevalier, David Evans, Bernard Reddy, David Steinberg, Manuel Trajtenberg, and seminars participants at the 2004 AEA meetings and Tel Aviv University for helpful comments. Financial support from NERA is gratefully acknowledged.

Author information

Authors and Affiliations


Corresponding author

Correspondence to Chaim Fershtman.

Rights and permissions

Reprints and Permissions

About this article

Cite this article

Fershtman, C., Gandal, N. Open source software: Motivation and restrictive licensing. IEEP 4, 209–225 (2007).

Download citation

  • Published:

  • Issue Date:

  • DOI:


  • Open source software
  • Intrinsic motivation
  • Professional status
  • Signaling
  • Restrictive licenses

JEL Classification

  • D20
  • L86