<nettime> Six Limitations to the Current Open Source Development Methodology

[Felix Stalder <felix@openflows.org>]

Six Limitations to the Current Open Source Development Methodology

The "Open Source Approach" to develop informational goods has been 
spectacularly successful, particularly in the area for which it was 
developed, software. Also beyond software, there are important, successfull 
Open Source 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, particularly outside the software domain, the Open Source projects 
remain relatively marginal. Why? Some of it can be explained by the relative 
newness of the approach. It takes time for new ideas to take hold and to be 
transferred successfully from one context to another. But this is only part 
of the story. The other part is that the current development model is based 
on a number of specific, yet unacknowledged conditions that limit its 
applicability to more diverse contexts, say the music distribution or drug 
research.

The boundaries to the open production model as it has been established in the 
last decade are set by six conditions characterizing virtually all of the 
success stories of what Benkler called "commons-based peer production." The 
following list is a conceptual abstraction, a kind of ideal-type. The actual 
configuration and relative importance of each condition varies from project 
to project, but taken together they indicate the boundaries of the current 
model. In this elaboration, I draw from examples of free and open source 
software, but it would be simple to illustrate these limitation based on open 
content projects.


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 Production

A large software program consists of many smaller code segments (libraries, 
plug-ins etc.)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 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, or other markers allowing to determine 
liability, to it. 

The space delimited by these condition is large and still not fully explored. 
We can expect that the current open production model will find additional 
niches in which it can thrive. Few could have predicted the success of 
Wikipedia only three years ago, even though Open Source Software had already 
been very successful at the time. However, it is also clear that many 
information goods fall outside of this space. Not always are the means of 
production inexpensive and readily available or the production process 
modular. Sometimes,  the number of potential producers is small, more often 
than not are the producers not the users of their own products, and, in many 
cases, product liability is desirable.

This does not mean that the "open source model" cannot apply to, say, the 
production of literary works, music, or medical drugs. What it means, 
however, is that to make it viable, another round of social innovation is 
required. This is slowly happening. The growth of "Open Access Journals" or 
discussions around "compulsory licensing" are good, though very early 
examples.





----+-------+---------+---
http://felix.openflows.org

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net