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