Re: [ox-en] Steven Weber * The Success of Open Source
- From: Michael Bouwens <michelsub2003 yahoo.com>
- Date: Sat, 28 Oct 2006 22:11:59 -0700 (PDT)
[Converted from multipart/alternative]
[1 text/plain]
Stefan,
This has been a wonderful resource for me, and I have integrated some of your summary and citations in the P2P entries on Peer Production and Open Source Production Methodology.
However, I was hoping that you would perhaps revisit the following points about chapter 3:
You say:
The chapter then describes a couple of variants of leadership
but you do not specify what is said, but this is really crucially interesting as well
You then continue and say:
The chapter continues with descriptions of a couple of decision-making
schemes found in Free Software projects
I am equally interested in this summary.
Of course, I should read the book myself <g>.
Michel
Stefan Merten <smerten oekonux.de> wrote: -----BEGIN PGP SIGNED MESSAGE-----
Hi Oekonuxis!
I finally made it to complete reading of that great book "The Success
of Open Source" by Steven Weber. Moreover I wrote a recension of the
book you can find below and on
http://en.wiki.oekonux.org/Oekonux/Research/SuccessOfOpenSource
Mit Freien Grüßen
Stefan
- --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
General impressions
===================
A really great book! The book looks at the practice of Free Software
projects and from this collects a lot of insights in how Free Software
projects function. Then it presents these insights in a consistent
framework. An essential thesis is that Free Software constituted a new
notion of property and that this new notion of property results in new
governance structures.
When I started reading the book I planned to quote some highlights and
so marked interesting paragraphs on the margin. The problem is: Nearly
every page has at least one such mark! This recension mainly consists
of quotes from the book which I find most insightful or otherwise
interesting. All the page numbers given are for the hardback version
of the book.
I think for everyone who seriously wants to participate in Oekonux_
this book is a must-read. For Oekonux Chapter 5 about microfoundations
of Free Software relates much to the term Selbstentfaltung which is
something we already thought a lot about. Chapter 6 about
macrofoundations of Free Software relates to what has been called the
OHA problem in Oekonux. An area where we did not make substantial
advances in the past. May be for seasoned Oekonux participants this is
therefore one of the most interesting parts of the book.
Chapter 1: Property and the Problem of Software
===============================================
The first chapter presents some initial questions and thesises.
I explain the creation of a particular kind of software - open
source software - as an experiment in social organization around a
distinctive notion of property. The conventional notion of property
is, of course, the right to exclude your from using something that
belongs to me. Property in open source is configured fundamentally
around the right to distribute, not the right to exclude. If that
sentence feels awkward on first reading, that is a testimony to just
how deeply embedded in our intuitions and institutions the exclusion
view of property really is.
Open source is an experiment in building a political economy - that
is, a system of sustainable value creation and a set of governance
mechanisms. In this case it is a governance system that holds
together a community of producers around this counterintuitive
notion of property rights as distribution. It is also a political
economy that taps into a broad range of human motivations and relies
on a creative and evolving set of organized structures to coordinate
behavior. [p.1f.]
Ultimately the success of open source is a political story. The open
source software process is not a chaotic free-for-all in which
everyone has equal power and influence. And is is certainly not an
idyllic community of like-minded friends i which consensus reigns
and agreement is easy. In fact, conflict is not unusual in this
community; it's endemic and inherent to the open source process. The
management of conflict is politics and indeed there is a political
organization at work here, with the standard accouterments of power,
interests, rules, behavioral norms, decision-making procedures, and
sanctioning mechanisms. But it is not a political organization that
looks familiar to the logic of an industrial-era political economy.
[p.3]
About the importance of Free Software for a new society:
The open source phenomenon is in some ways the first and certainly
one of the most prominent indigenous political statements of the
digital world. [p.7]
About three interesting questions for political economy:
* *Motivations of individuals:* The microfoundation of the open
source process depend on individual behavior that is at first
glance surprising, even startling. Public goods theory predicts
that nonrival and nonexcludable goods ought to encourage free
riding. Particularly if the good is subject to collective
provision, and many people must contribute together to get
something of value, the system should unravel backward toward
underprovision. When, then, do highly talented programmers choose
voluntarily to allocate some or a substantial portion of their
time and mind space to a joint project for which they will not be
compensated?
* *Coordination:* How and why do these individuals coordinate their
contributions on a single focal point? The political economy of
any production process depends on pulling together individual
efforts in a way that they add up to a functioning product.
Authority within a firm and the price mechanism across firms are
standard means of coordinating specialized knowledge in a highly
differentiated division of labor, but neither is operative in open
source. Instead, individuals choose for themselves what they want
to work on. Money is not a central part of the equation. And any
individual can freely modify source code and then redistribute
modified versions to others. A simple analogy to ecology suggests
what might happen over time as modifications accumulate along
different branching chains. Speciation - what computer scientists
call code-forking - seems likely. In effect the system evolves
into incompatible versions. Synergies in development are lost. And
any particular developer has to choose one or another version as
the basis of his future work. This is essentially what happened to
another major operating system, Unix, in the 1980s. How does the
open source process sustain coordinated cooperation among a large
number of contributors, outside the bounds of hierarchical or
market mechanisms?
* *Complexity:* Software is an extraordinarily complex technical
artifact. In *The Mythical Man-Month*, a classic study of the
social organization of computer programming, Frederick Brooks
noted that when large organizations add manpower to a software
project that is behind schedule, the project typically falls even
further behind schedule. He explained this with an argument that
is now known as Brooks's Law. As you raise the number of
programmers on a project, the work that gets done scales linearly,
while complexity and vulnerability to mistakes scales
geometrically. This is supposed to be inherent in the logic of
division of labor - the geometric progression represents the
scaling of the number of possible communication paths and
interfaces between pieces of code written by individual
developers. Chapter 3 considers in detail the deeper line of
reasoning behind this argument, which is an incredibly interesting
statement about the relationship between complex systems of
meaning and the imperfections of human communication. Recognize
for the moment the challenge it poses to organization. What is the
nature of governance within the open source process that enables
this community to manage the implications of Brooks's Law and
perform successfully with such complex systems?
[p.11f.]
About the importance of Linux as a certain artifact:
Remember what is potentially durable and possibly deserving of the
term "revolutionary" - not a particular manifestation of a process
but the process itself. After all, the logistics revolution was not
any single container ship or a company building tractor-trailer
trucks; it was a new way of moving goods around the world. [p.14]
About perspectives on changes:
My point is that during the early stages of economic and social
change, analysts often pay more attention to what is going away than
what is struggling to be born. To use Schumpeter's phrasing, it is
easier to see precisely the destructive side of creative
destruction, than it is to see the creative side. [p.15]
About the notion of property in Free Software:
Open source radically inverts the idea of exclusion as a basis of
thinking about property. *Property in open source is configured
fundamentally around the right to distribute, not the right to
exclude.* [p.16]
Chapter 2: The Early History of Open Source
===========================================
The first chapter about this chapter:
Chapter 2 traces the early history of the open source process. It
focuses on the interaction between technology, culture, and
politics. It explains how open source grew out of early programming
needs, how it established a technical aesthetic and a nascent
political culture, and how both were affected by Justice Department
antitrust actions, corporate strategies, and changes in the way
mainstream technology users behaved. [p.18]
This chapter draws a very well-informed picture about the early days
of computing and what this meant for Free Software. It tells about
technological innovations and their impact on the way people think
about computing. It emphasizes how much the way of thinking Unix -
like strict modularization - is based on preformed the way of thinking
about Free Software. From personal experience I agree with this
analysis wholeheartedly.
The chapter also gives a good outline of the organizational background
of Unix - i.e. the back and forth between AT&T, University of
Berkeley, the upcoming Internet, Sun and so on. It also mentions the
grassroots like the Homebrew Computer Club and also the Free Software
Foundation. The chapter ends at the time when Linux started.
Chapter 3: What Is Open Source and How Does It Work?
====================================================
The first chapter about this chapter:
Chapter 3 gives a more precise description of the phenomenon. How
does the open source process function? I present data that capture
an important part of what we know about the open source process and
the people who contribute to it. I use this to build an ideal-type
description of open source as a production process for complex
knowledge goods. [p.18]
About the importance of creativity for developing software:
That is why great poetry is almost always the product of a single
creative mind. It can be helped along, of course. Design practices
and general rules can be and are taught to aspiring poets, and to
aspiring software designers. Technology provides both with tools to
assist their work, from word processors to elegant test programs for
software modules. But technology cannot now, and will not in the
foreseeable future, solve the problem of creativity and innovation
in nondecomposable complex systems. The essence of software design,
like the writing of poetry, is a creative process. The role of
technology and organization is to liberate that creativity to the
greatest extent possible and to facilitate its translation into
working code. Neither new technology not a "better" division of
labor can replace the creative essence that drives the project.
[p.58f.]
About the central characteristics of Free Software:
*The key element of the open source process, as an ideal type, is
voluntary participation and voluntary selection of tasks.* [p.62]
About the distinction of division and distribution of labor:
In fact the underlying notion of a division of labor doesn't fit the
open source process at all. Labor is *distributed*, certainly - it
could hardly be otherwise in projects that involve large numbers of
contributors. But it is not really divided in the industrial sense
of that term. [p.62]
About the importance of organization for the understanding of the
success of Free Software:
*If Brooks is even partially right about the nature of complexity,
then the success of open source cannot simply depend on getting more
people or even the "right" people to contribute to the project. It
depends also, and crucially, on how those people are organized.*
[p.65]
The chapter then goes on to look at studies which try to find out
which people contribute. One important result is that there are
relatively few people who contribute a lot and relatively many people
who contribute only one or two items. It then comes to the question of
what these people actually do.
About the roots of the procedures:
The logic of what open source user-programmers do did not emerge
from abstract theory. No one deduced a set of necessary tasks or
procedures from a formal argument about how to sustain large-scale,
decentralized collaboration. It was a game of trial and error - but
a game that was played out by people who had a deep and
fine-grained, if implicit understanding of the texture of the
community they were going to mobilize. Over time, observers studied
the behavior as it played out in practice and tried to characterize
its key features. Drawing heavily on Eric Raymond's keen analysis
supplemented by a set of interviews and my own observations, I offer
eight general principles that capture the essence of what people do
in the open source process. [p.73]
These principles are:
1. Make it interesting and make sure it happens
Because all all contributions are voluntary people work in areas
they find interesting. Those parts of software development which
for most are less interesting must be made interesting by other
means like public credit.
Also because people do not want to waste their contribution they
need to believe that their contributions are really used.
2. Scratch an itch
Put simply: Solve real problems people have.
3. Minimize how many times you have to reinvent the wheel
4. Solve problems through parallel work processes whenever possible
What is meant here is that problems are solved in a evolutionary
way where parallel developments are tried more or less
independently and at some point one of them is selected to be
followed further while others are dropped.
5. Leverage the law of large numbers
This means that to test your software in an optimal way you give it
to as much users as possible to generate the maximum test patterns.
6. Document what you do
Documentation is necessary to transport the ideas contained in a
piece of software from one mind to another - across space as well
as across time.
7. Release early and release often
8. Talk a lot
For me pages 73-82 where these principles are laid down and explained
are among the most interesting parts of the whole book.
On the question how Free Software developers collaborate the chapter
mentions three empirical facts:
* Technology is an enabler
A quote illustrates nicely what is meant here:
Put 25 people in a room and communication slows down, whereas an
email list can communicate with 25 people just as quickly and
cheaply as it communicates with 10 or 250. As the numbers scale
and the network grows, the likelihood of proliferating weak ties -
that is, pulling into the process people with very different sets
of expertise and knowledge - goes up as well. [p.83]
* Licensing schemes as social structure
Again a quote comes in handy to explain the meaning of this point:
The basic assumptions behind open source is that people want to be
creative and original and they don't need much additional
incentive to engage in this manner. The only times when innovation
will be "undersupplied" is when creative people are prevented from
accessing the raw materials and tools that they need for work.
Distributions of raw materials and tools, then, is the fundamental
problem that an intellectual property rights regime needs to
solve. Solving that problem allows the system to release fully the
creative energies of individuals. Even better, it promises to
ratchet up the process over time as a "commons" of raw materials
grows. Open source intellectual property aims at creating a social
structure that expands, not restricts, the commons.
The regime takes shape in a set of "licenses" written for the most
part in the language of standard legal documents. For now think of
these licenses as making up a social structure for the open source
process. In the absence of a corporate organization to act as an
ordering device, licensing schemes are, in fact, the major formal
social structure surrounding open source. [p.84f.]
* Architecture tracks organization
This is a point which I know so well from my paid work - but I guess
it is a bit hard to understand the meaning of this point unless you
know it from your own experience. In short: The way a development
organization is shaped is reflected in the artifacts it creates.
Another quote may shed more light on this:
Implicitly then, and often explicitly, technical decisions are
influenced by beliefs about effective ways to organize
development. Technical discussions on how things should work and
should be done are intimately related to beliefs about and
reflections of the complex collaboration problem invoked by
voluntary large-scale parallel processing in open source
development. Technical rationality may be a necessary part of the
foundation of the open source process, but it is not sufficient.
[p.88]
The chapter ends with the question on how open source developers
resolve disagreements.
On the sources of conflict:
Major conflicts within the open source process seem to center on
three kinds of issues. The first is who makes the final decisions if
there are deep and seemingly irreconcilable disagreements over the
goodness of a specific solution, or a general direction for dealing
with a problem. The second is who receives credit for specific
contributions to a project. (Ironically, this second source of
conflict can become worse in more successful collaborations, because
much of what is good in these collaborations is created in the
context of relationships as much as by any particular individual.)
The third major source of conflict is the possibility of forking.
The right to fork *per se* is not an issue. What causes contention
is the issue of legitimacy. It is a question of who can credibly and
defensibly choose to fork the code, and under what conditions.
[p.89]
What constitutes the fundament for conflict resolution:
In open source much of the important conflict management takes place
through behavioral patterns and norms. There are two descriptive
elements of these norms that I consider here: the visible nature of
leadership and the structures of decision-making. [p.89]
The chapter then describes a couple of variants of leadership. But it
concludes:
This kind of variance does not demonstrate that leadership is
irrelevant; instead it suggests that there are different ways to
lead and that a satisfying explanation of the open source process
needs to go beyond the question of leadership. [p.90f.]
The chapter continues with descriptions of a couple of decision-making
schemes found in Free Software projects. Similar to leadership it
concludes:
Each of these decision-making systems has strengths and weaknesses
as coordination mechanisms. [...] What they share is the fundamental
characteristic of the open source process - there is no authority to
enforce the roles and there is nothing to stop an individual
programmer or group of programmers from stepping outside the system.
On a whim, because of a fundamental technical disagreement, or
because of a personality conflict, anyone could take the Linux code
base or the Apache code base and create their own project around it,
with different decision rules and structures. Open source code and
the license schemes positively empower this option. To explain the
open source process is, in large part, to explain why that does not
happen very often and why it does when it does, as well as what that
=== message truncated ===
The P2P Foundation researches, documents and promotes peer to peer alternatives.
Wiki and Encyclopedia, at http://p2pfoundation.net; Blog, at http://blog.p2pfoundation.net; Newsletter, at http://integralvisioning.org/index.php?topic=p2p
Basic essay at http://www.ctheory.net/articles.aspx?id=499; interview at http://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html; video interview, at http://www.masternewmedia.org/news/2006/09/29/network_collaboration_peer_to_peer.htm
---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.
[2 text/html]
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de