Design Rules Volume 2 : Chapter 24—The Origins and Rationale for Open Source Projects and Communities

The purpose of this chapter is to analyze open source software development projects as a form of organization responsive to the requirements and rewards of software as a technology. Open source development is a collaborative method of designing software (and other complex artifacts) characterized by (1) distributed governance; (2) geographic dispersion of contributors; (3) voluntary participation and selection of tasks; and (4) “radical transparency” with respect to the design. Radical transparency is a shorthand term indicating that no one can be prevented from viewing, copying, modifying, or redistributing the software. An open source development project creates a complex product incorporating many options. It thus qualifies as a product platform. However, in contrast to standards-based and logistical platform systems, open source projects are transaction free zones dedicated to producing software. Property rights to the products of the zone are vested in a community (the members collectively). Tasks are not assigned, but are selected by the individuals, and disputes are usually resolved via discussion and persuasion, not authority. Most importantly, by agreement among the members, there is no information hiding: community source code is viewable and modifiable by any member of the project and the public at large.The first open source projects were staffed entirely by volunteers who received no direct compensation for working on the codebase. They also placed no restrictions on free-riding. These organizations raised an immediate question: why would individuals create valuable software and give it away for free? I explain the conditions under which individual contributions to a collaborative effort are consistent with rational self-interest and show how open source projects avoid the dilemmas caused by free-riding.I go on to consider how open source projects get started. Like all open platform systems, open source projects are subject to the “chicken-and-egg” problem: the benefits of the platform to each member depend on the presence of other members. Because open source projects do not allow side payments among members, I argue that an expectation among members that strangers will repay a gift with another gift is a pre-condition that assists early-stage projects to get off the ground. I summarize the empirical evidence for the existence of reciprocity in the human population and describe the results of a laboratory experiment that tests this hypothesis in a setting modeled after open source software