|
Abstract:
|
"Some open source communities consist of hundreds or thousands of individuals who have different interests, backgrounds and motives. In the communities, the source code of software is not treated as a secret. Programmers agree that the software and corresponding source code should be open, visible, downloadable and modifiable for anyone interested. The software and the corresponding source code are said to be in a commons (Benkler 2002a, Bollier 2001b, Boyle 2003, Bruns 2000, McGowan 2001). The question in this paper is: 'How are the open source commons organized and how are they sustained?' An answer to this question is believed to be relevant to all those who study and are involved in digital information commons.
"The goal of this paper is to provide an analysis of the institutional design of open source commons. The eight design principles, as put forward by Elinor Ostrom, are adopted to answer the research question. They are: 1) clearly defined boundaries, 2) congruence between appropriation and provision rules and local conditions, 3) collective choice arrangements, 4) monitoring, 5) graduated sanctioning, 6) conflict resolution mechanisms, 7) minimal recognition of rights to organize, 8) nested enterprise. Among the reasons for choosing this framework are: i) it bridges a gap that exists in state-of-the-art research on open source communities and ii) it is based on rigorous empirical analysis of the institutions in self-governing communities.
"The material presented in this paper is based on observations of mailing lists, secondary literature and 60 in-depth interviews. The interviews were held with a mixture of people ranging from hobbyist software programmers to commercial end users. Five communities were studied in more detail, they are: Apache, Linux, Debian, Python and PostgreSQL.
"A first outcome is that open source communities have a multitude of quite formal institutions like foundations, open source licenses and elected leadership. Their role is to protect the commons from external pressures threatening the future availability of the software (see also O'Mahony, 2003). They serve as boundaries. These and other institutions, however, have little explanatory value in the organization of the communities. For instance, the communities have devised voting mechanisms, but they have hardly any affect in solving conflicts or leading to a collective choice. Many respondents explained to ignore the outcome of a vote and instead decided to do what they think is best.
"Another important outcome is that the open source commons are based on a highly intelligent infrastructure, which consists of many mechanisms and tools. Examples of tools are databases to structure the development process and guidelines to describe how the software should be written. The infrastructure eases the process for developers and users to contribute to the commons; they lower the costs involved in e.g. searching for the contributions of others and understanding what others have contributed."
|