Benjamin Geer on Thu, 14 Aug 2003 21:49:08 +0200 (CEST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

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


On Thursday 14 August 2003 14:07, Felix Stalder wrote:

> The "Open Source Approach" to develop informational goods has been 
> spectacularly successful [...]
> 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."

While I think your analysis is useful, in that it partly explains why it has 
been so easy for commons-based peer production to flourish in software 
development, I would be hesitant to define the "open source approach" solely 
or even primarily in terms of the characteristics you mention.  In terms of 
power structures, surely there are many different open source approaches, 
including the 'benevolent dictator' approach used by the Linux kernel 
developers, and the various kinds of consensus, voting and delegation used by 
Apache, KDE and Debian.

While these projects have different political models, they have some poltiical 
features in common:

Open participation: Anyone can participate if they agree to the groups's 
principles, and have the necessary skills.

Self-management: The people who do the work decide amongst themselves what 
work is to be done, and how to do it.

Transparency: detailed about what the group is doing, including its 
discussions and decisions, as well as the knowledge gained through its work, 
are publicly available on web sites (e.g. in the form of source code and 
documentation) and on mailing lists.

Public ownership of knowledge: because knowledge about the group's work is 
publicly available, and freedom to use this knowledge is protected by open 
source licences, it becomes part of the commons.  (Note that even if a group 
produced something material, which could not be shared as easily as software, 
the group could still share its knowledge in the same way.)  Open 
participation also promotes public ownership of knowledge, because less 
experienced people can learn from more experienced people through 
participation.

Respect for skill: If your expertise is recognized by others, and you 
contribute something useful, your opinions are granted more weight.  There is 
no way to gain influence without skill.

Diversity: Different approaches to carrying out tasks and solving problems can 
coexist (without hindering one another), and learn from each other (e.g. KDE 
and GNOME).

It seems to me that these principles could indeed be applied to projects that 
don't fall within the boundaries you specified.

The Open Organizations project (http://www.open-organizations.org) is an 
attempt to synthesize these principles, and some others, into a workable, 
general-purpose model.

Ben

#  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