One-size-doesn't-fit-all.
Particulars of the Volunteer Open Source Development Methodology

Felix Stalder <http://felix.openflows.org>
Published in: Make World Newspaper #3, Sept.11, 2003
license: Attribution-ShareAlike 1.0, http://creativecommons.org/licenses/by-sa/1.0/

The Free and Open Source Software Movement has been spectacularly successful. In barely 20 years, it has grown from a dream of a small band of programmers to a world-wide reality, producing some of the most advanced informational goods available anywhere. As such it has been the first collective effort to successfully harness the potential of the Internet, where information can be abundant and communication without cost.

This success has been inspirational, and many are looking for ways to apply its development model beyond software. The model is based on communal management and open access to the informational resources for production, openness to contributions from a diverse range of users/producers, flat hierarchies, and a fluid organizational structure.

To some degree this model has been applied successfully beyond software, in projects such as the free Encyclopedia, Wikipedia; collaborative sites writing/publishing projects such as koro5hin.org; and the Distributed Proofreading Project, attached to the Gutenberg Project.

However, the free and open source model is not a one-size-fits-all solution to open production of informational goods via the Internet and is not suited to be applied to many areas of informational production. Why? Because its social organization, the particulars of its development methodology, reflect the particulars of the problems -- software development -- for which it has been created. Other problems has different particulars and will need a different form of social organization to be produced 'openly'.

There are at least six particulars of software production, which is reflected in the social organization of the Free and Open Source Movement, that we cannot take for granted in other contexts.

1) Producers are not sellers

The majority professional, i.e. highly-skilled, programmers do not draw their economic livelihood from directly selling the code they write. Many work for organizations that use software but do not sell it, for example as system administrators. For them the efficient solution of particular problems is of interest, and if that solution can be found and maintained by collaborating with others, the sharing of code is not an issue. For others employed in private sector companies, for example at IBM, the development of free software is the basis for selling services based on that code. The fact that some people can use that code without purchasing the services is more than off-set by being able to base the service on the collective creativity of the developer community at large. From IBM's point of view, the costs of participating in open software development can be regarded as 'capital investment' necessary for the selling of the resulting product: services.

For members of academia (faculty and students) writing code, but not selling (often explicitly prohibited), contributes to their professional goals, be it as part of their education, be it as part of their professional reputation-building. For them, sharing of code is not only part of their professional advancement, but an integral part of the professional culture that sustains them also economically,. in form of salaries for the faculty and stipends for the (graduate) students.

Last but not least are all those who use their professional skills outside the professional setting, for example at home on evenings and weekends. Having already secured their financial stability, they can now pursue other interests using the same skill set.

2) Limited capital investment

Particularly the last, and very important group of people, whose who work outside the institutional framework on projects based on their own idiosyncratic interests, can only exist due to the fact that the means of production are extraordinarily inexpensive and accessible. Materially, all that is needed is a standard computer (often even a substandard one would already suffice) and a fast, reliable connection to the communication forums of the community. Of course, the computer and the network rely on a level of infrastructure that cannot be taken for granted in large parts of the world, but for most people in the centers of development, they are within relatively easy reach.

Once this access to be means of communication is secured, the skills necessary to participate in the development of code can also be acquired collaboratively, free of charge. The number of self-taught programmers is significant. Since no expensive diplomas are necessary to become active, the financial hurdle is, indeed, extraordinarily low.

3) High number of potential contributors

Programming knowledge is becoming relatively common knowledge, no longer restricted to an engineering elite, but widely distributed throughout society. Of course, truly great programmers are rare as truly great artists are, but average professional knowledge is widely available. This has a quantitative and a qualitative dimensions. Quantitatively, the number of able programmers is in the millions, and rising. Qualitatively, the range of people capable programmers is also unusually wide, not the least because the material hurdles are so low and the learning can take place outside of institutions with entry exams and tuition fees. This large and diversified pool of talents makes it possible to create the critical mass of contributors out of only a fraction of population.

4) Modularized and Incremental Production

A large software program consists of many smaller code segments (libraries, plug-ins etc), some of which can be appropriated from other programs. This makes it possible to break down the production process into many small steps which can be carried out by distributed contributors. If the act of integration is relatively straight forward, it allows to keep the amount of work that each has to contribute highly flexible and also make use of smaller contributions (bug reports, patches). Furthermore, the modularity of the production process allows a high number of people to work in parallel without creating significant interferences.

5) Producers Are Users

According to Eric S. Raymond, a good open source projects starts with a programmer scratching his own itch and finding out in the process that there are many others with the same problem. Wanting to use a program is a great motivation of contributing to developing it. Often, it's much more efficient that waiting, hoping that someone will write and sell a program that will address one's particular need.

6) No Liability

Last, but not least, software, proprietary as well as free and open source, has no product liability. Paragraph 11 of the GPL states, similar to most other licenses, that "the copyright holders and/or other parties provide the program 'as is' without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose" (GPL, v2). The absence of liability makes it possible to produce a program without having to assign clear ownership of the entire program (as supposed to attribution of parts of the code to individual contributors), or other markers allowing to determine liability.

This is not a critique of the Free and Open Source Software Movement, it works well and represents exceptional social innovation. But, to extend this innovation, we need, well, to innovate more. We must to think creatively what it would mean create open access to other informational goods, say music or medical drugs. For these areas, Free and Open Source Software can be an inspiration, but not a model. There's reason to be optimistic. Now models are being tested, or at least seriously discussed. The growth of "Open Access Journals" or discussions around "compulsory licensing" are good, though very early examples. Much remains to be done.


Note: an earlier version of this text has been published on nettime-l and oekonux-en and the discussions on this list have helped to clarify the argument presented.