[ox-en] Steven Weber * The Success of Open Source
- From: Stefan Merten <smerten oekonux.de>
- Date: Fri, 20 Oct 2006 08:20:15 +0200
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
means for cooperation. [p.92f.]
Chapter 4: A Maturing Model of Production
=========================================
The first chapter about this chapter:
Chapter 4 continues the history of open source to the present. It
was in the 1990s that open source acquired a self-conscious identity
as a community. By the end of the 1990s, open source had become a
phenomenon, in product markets, capital markets, mainstream
corporate settings, and in the imagination of many people inside and
outside the software engineering world. This history demonstrates
the viability of (at least) two discrete ways of organizing the
production of software, each of which is embedded in distinctive
notions of property, policy, business models, and ideas in popular
imagination. [p.18]
Indeed this chapter continues the history of Free Software from the
early days of Linux close to the present (but probably before the huge
success of Firefox). Again it is a well-informed text which picks up
on many important events in the Free Software history.
Here are some quotes which express the principles which have been
established during this time:
This [founding of an autonomous X windows project] set an important
principle for mass open source development projects: If there is
something you want and others also want it enough to help you build
it, go ahead and do it.
Torvalds's response to the X windows project established a second
important principle. Torvalds did more than accept the new project
and cooperate with the X windows developers. He made use of the X
windows project as a way of stressing and testing the foundations of
the Linux kernel in new circumstances. [p.103]
This series of events [around the development of a network stack for
Linux] established a third principle of open source organization,
more specifically the organization of decision-making in Linux.
Torvalds's actions created a leadership role for Alan Cox. Cox was
then the semiofficial "networking guy" and the community of
developers began to send most communications or code patches having
to do with network functions directly to him, rather than to
Torvalds. The lieutenant model was born, along with the informal
pyramidal hierarchy that characterizes decision making for Linux. It
was never decided *per se*; it simply evolved in practice. Torvalds
endorsed and legitimized the practice when he started sending
networking code that was submitted to him down the line to Cox
before Torvalds himself acted on it. [p.105]
About how conflicts are carried out:
This long exchange [between Torvalds and Tanenbaum very early in
Linux history] illustrates some of the distinctive characteristics
of conflict in the open source process. It is carried out entirely
in the open, with messages on email lists accessible to everyone in
the community. Ultimately the discussions get down to technical
issues, clarifying the trade-offs among design strategies and
decisions that matter for the function and performance of software.
Torvalds was forced to think hard about the limitations and problems
with his design and justify a plan of attack to the community, which
actively responded and prodded and pushed. And because all the
communications were archived on the lists (they still can be read
today, and they often are), people were for the most part offering
closely reasoned opinions that educated the community about the
issues in play. [p.102]
About reasons for shift of leadership:
Lack of responsiveness of this kind [as the NSCA developers showed
before Apache was forked off] is a clear cue that leadership of an
open-source style development process is failing and represents a de
facto invitation to fork the code. [p.110]
About moral in Free Software:
Stallman understood that most of his audience were pragmatists. He
was trying to change that fact by illustrating the values he felt
were at stake in their practice, and moving the entire frame of the
discussion about software into the realm of ethics. For better or
worse, he failed at that task. Pragmatism is still the prevalent
"moral" stance among developers and users of computer software.
[p.112]
Chapter 5: Explaining Open Source: Microfoundations
===================================================
The first chapter about this chapter:
Chapters 5 and 6 are the core explanation of the open source
process. I break the explanation into two separate buckets [...].
The first is about microfoundations. Why do individuals choose
voluntarily to allocate a portion of their time, effort, and mind
space to the open source process? What is the economic logic of the
collective food that is being built that frames these decisions?
This is the focus of chapter 5. [...] [p.18]
About the fields which need research and the way of thinking which is
best suited for this research:
I am attempting to build an understanding that covers at least four
different bases. A good explanatory story must be *social* because
open source software is a collective phenomenon, the product of
voluntary collaboration among groups of people. It must also be a
*political* story because formal and informal structures and
organizations function to allocate scarce resources and manage
conflicts as well as promote certain practices and values. It must
be a *technical* story because the core product of the open source
process is software code. And it must also be an *economic* story,
in a fundamental way. I do not mean that familiar notions of
economic behavior like rent-seeking, opportunism, and even standard
cost-benefit analyses need to be front and center. What I do mean is
a more primitive version of economic reasoning. At the center of the
open source process are autonomous individuals who make choices
about what to do with their limited time and energy. To understand
the reasoning behind their choices is to understand the microlevel
economics of open source.
Political economy as a way of thinking covers most of these bases.
[p.129f.]
About altruism as an explanation:
If altruism were the primary driving force behind open source
software, no one would care very much about who was credited for
particular contributions. And it wouldn't matter who was able to
license what code under what conditions. Certainly people help each
other in open source for the sake of helping - as elsewhere, one of
the ways people express their values is in the act of providing
help. Richard Stallman's original manifesto likened the act of
sharing code to neighbors helping each other to put out a fire. But
neighbors know each other; they live next to each other over time; a
fire next door to my house threatens my house directly; and I have
reason to expect reciprocity from my neighbor at some time in the
future. The geographical distribution and relative anonymity of the
Internet makes altruism a dicier proposition. There is in fact
important evidence against the prevalence of altruistic behavior on
the Internet, even in settings (such as peer-to-peer networking) in
which there are no or very small possible costs associated with
making contributions. [p.131]
About self-organization as an explanatory term:
First, self-organization is used too often as a placeholder for an
unspecified mechanism. The term becomes a euphemism for "I don't
really understand the mechanisms that holds the system together."
That is the political equivalent of cosmological dark matter.
Better-specified notions of self-organization build on the notion
that order arises organically or endogenously out of the local
interactions among individuals. Here self-organization is being used
in contrast to overarching authority or governance - a useful
comparison. But that does not relieve the obligation to explain
*how* those local interactions add up to "global" order. [p.132]
Second, I shy away from the heading "self-organization" due to the
normative peculiarities of the discourse that it prompts.
Self-organization often evokes an optimistically tinged "state of
nature" narrative, a story about the food way things would
"naturally" evolve if the "meddling" hands of corporations and
lawyers and governments and bureaucracies would just stay away. Of
course those non-self-organized organizations have their own
narratives, which portray the state of nature as a chaotic mess.
To pose two state-of-nature narratives against each other creates a
battle of assumptions, a tournament of null hypotheses, which is not
productive. The underlying presumption - that there *is* in a fact a
state of nature without human agency - is even more damning to the
discourse when we are talking about something like software code or
knowledge production more generally. *There is no state of nature on
the Internet.* Knowledge does not want to be "free" (or for that
matter, owned) more than it wants to be anything else. We are going
to be creating lots of new things in this technological space, and
we can organize the creation of those things however we want. This
is social constructivism at its core, pitting different social
constructivist narratives against each other instead of against an
imaginary state of nature. [p.132f.]
Then the chapter goes on to explain two questions on the micro-level:
* Individual motivations
* Economic logic of the collective good
About the individual motivations the chapter then identifies six
categories of motivation:
* Art and beauty
* Job as vocation
* The joint enemy
* Ego boosting
* Reputation
* Identity and belief systems
About art and beauty:
The fun enjoyment, and *artistry* of solving interesting programming
problems clearly motivate open source developers. Developers speak
of writing code not only as an engineering problem but also as an
aesthetic pursuit, a matter of style and elegance that makes coding
an act of self-expression. [p.136]
About job as vocation:
Creating elegant or clean code is part of the programmer's
experience of *the job as vocation*. The idea of writing code to
"scratch your own itch" is critical because it is a standard part of
most software engineers' jobs. [p.137]
While Schumpeter is often read as a story about economic rents, he
also believed deeply in the emotional experience of creativity, the
erotic satisfaction of making something new and making it work.
Leaving behind the monopoly rents and emphasizing the erotic
satisfaction in Schumpeterian innovation creates a setting in which
innovators are deeply incentivized to share their work as broadly as
possible with others. There is simply no cost, and considerable
benefits to be had, by acting in this way. "Scratching your itch"
then becomes a story about satisfaction that comes with solving your
own problem *and* solving someone else's problems as well. [p.139]
About the joint enemy:
For many open source developers, this experience [of job as a
vocation] is embedded in an ongoing battle with a *joint enemy*.
Microsoft is the obvious villain, but in fact this single company
acts as a proxy for a wide array of proprietary software developers.
[...]
Code should be a open not for moral reasons *per se*, but because
development processes built around open source code yield better
software. The "enemy" is not an ideological villain; it is a
technical and business practice villain and that is what the
conflict is about. Microsoft is the exemplar because this company is
seen as sacrificing a technical aesthetic to ruthless business
practice aimed at gaining market share and profits. [p.139]
About ego boosting:
Individual *ego-boosting* is a powerful motivating force for open
source developers, but it is not a simple one. For the developer's
self-recognition, there is a consistent finding across surveys that
the challenge of programming in the open source environment is a
source of satisfaction ([...]). Within the community, ego as a
driving force is openly acknowledged and accepted. In trying to
create a legacy as a great programmer, many developers believe
deeply that "scientific" success will outstrip and outlive financial
success. [...] Yet there is a strong countercurrent against overt
*egotism*. Self-recognition and self-satisfaction are important, but
the hacker is not supported to self-promote at the expense of
others; in fact, the norm is to be externally humble and
(humorously, if possible) deprecate yourself. Bragging is
off-limits: The norm is that your work brags for you. [p.140]
About reputation:
Related to but separable from ego-boosting is the issue of
*reputation*. A reliance on what others think of the quality of your
work is not always a sign of unhealthy emotional dependence on
external evaluation. In the case of complex knowledge products with
aesthetic as well as functional value, it can also be a cognitive
component of concrete feedback. [p.141]
About reputation as an alienated motivation:
Lerner and Tirole portray an individual programmer as engaged in a
straightforward, instrumental cost-benefit analysis that goes like
this: Ego gratification is important because it stems from peer
recognition. Peer recognition is important because it creates a
reputation. A reputation as a great programmer is valuable because it
can be turned into money in commercial settings - in the form of job
offers, privileged access to venture capital, the ability to attract
cooperation from other great programmers.
The key point in this story is the signaling argument. [p.141f.]
The Lerner and Tirole argument is easy to nail down in traditional
economic terms, but that doesn't necessarily mean it is the most
important driver of individual behavior. Both the survey data and
interview and anecdotal data suggests that it is not the most
important conscious consideration for developers. [...] And the
simple behavioral fact is that most code - as long as it works -
does not get widely read, which undermines the claim that people
write it to boost their monetizable reputations. [p.143]
In any case, the reputonics argument [like described above] leaves
several things unexplained and creates problems of its own, such as
the following very important puzzle. If reputation were the primary
motivation, we should be able to tell some version of this kind of
story: Assume that project leaders like Torvalds receive greater
reputational returns than general programmers do. Then programmers
should compete to become project leaders, particularly on
high-profile projects, of which there are a limited number. This
competition could take at least two forms. We would expect to see a
significant number of direct challenges to Torvalds's leadership,
but in fact there have been few such challenges. Alternatively, we
could see "strategic forking." A strategic forker would fork a
project not for technical reasons, but rather to create a project
that he or she could lead. [...]
The problem with this kind of story is that it simply hasn't
happened. [p.143]
About identity and belief systems:
Part of the counterpoint to a competition in reputation comes from
strong elements of shared *identity and belief systems* within the
community of developers. Steven Levy in his 1984 book *Hackers*
chronicled the development of hacker culture around MIT in the early
1960s. Levy described the following key tenets of that culture,
which continue to characterize the open source community to a
surprising degree:
* *Access to computers should be unlimited - the so called hands-on
imperative.* [...]
* *Information should be "free".* [...]
* *Mistrust authority and promote decentralization.* [...]
* *Judge people only on the value of what they create, not who they
are or what credentials they present.* [...]
* *People can create art and beauty on computers.* [...]
* *Computers can change human live for the better.* [...]
[p.144f.]
A simple but foundational one [i.e. such an element] is the notion
that personal efficacy not only benefits from, but positively
requires, a set of cooperative relationships with others. [...] The
belief is that the community empowers the individual to help
himself. [p.145]
A related shared belief is that experimentation is the highest form
of human behavior. To try new things that challenge one's skills and
the skills of others is not just a tool for individual learning and
development; it is a contribution to the community. [p.145f.]
Finally there is an explicit recognition that these elements of
share identity and beliefs do not maintain themselves. Rather,
"community standards, ... are maintained by people actively applying
them, visibly, *in public*." [p.146]
After explaining these individual motivations the chapter then
explains that these are important but alone can not explain the
success of Free Software. Before the macrofoundations are researched
in the next chapter some light is shed on the economic logic of the
collective good.
The chapter tells that the notion of gift economy which some use to
explain Free Software is built on *abundance*. However:
Yet there is a flaw in the gift economy argument. What, exactly, is
the nature of abundance in this setting? [p.150]
It's clear that it is not the abundance in computing power and
bandwidth. Instead:
*Meaning and value depend on human mind space and the commitment of
time and energy by very smart people to a creative enterprise.* And
the time, energy, and brain power of smart, creative people are not
abundant. [p.151]
The chapter then goes on to look at the economic logic from the
perspective of *scarcity*:
Open source software is the epitome of a nonexcludable good, because
no one is prevented from consuming it. It is also entirely nonrival
in the sense that any number of users can download and run a piece
of software without decreasing the supply that remains for others.
This presents a straightforward economic puzzle of an essentially
pure public good. Put simply, the problem facing each rational
self-interested actor is the opportunity to free ride. [p.151]
About Rishab Ayer Ghosh's cooking pot model explaining the economics
of Free Software as a sort of non-direct exchange:
This is an attractive argument, but it too has a hole. Nonrivalness
foes not by itself make the challenge of joint provision go away.
The missing piece in Ghosh's argument is that it does not explain the
"trade." What is the underlying story that accounts for an exchange
relations hop here? In fact no trade is necessary. It is still a
narrowly rational act for any single individual to take copies of
multiple products from the pot without contributing anything at all,
and thus free ride on the contributions of others. The collective
action problem is still fundamentally in place. [p.153]
The chapter than develops the notion of an anti-rival good:
I believe the solution to this problem lies in pushing the concept
of non-rivalness one step further. Software in many circumstances is
more than simply non-rival. Operating systems like Linux in
particular, and almost software in general, actually are subject to
positive network externalities. Call it a network good, or an
anti-rival good (an awkward, but nicely descriptive term). In
simpler language, it means that the value of a piece of software to
any user increases as more people use the software on their machines
and in their particular settings. Compatibility in the standard
sense of a network good is one reason why this is so. Just as it is
more valuable for me to have a fax machine if lots of other people
also have fax machines, as more computers in the world run a
particular operating system or application it becomes easier to
communicate and share files across those computers. Each becomes
slightly more valuable to existing users as each new users enters
the picture.
Open source software makes an additional and very important use of
anti-rivalness, in maintenance and debugging. Remember the argument
that there exists an infinite number of paths through the lines of
code in even a moderately complex piece of software. The more users
(and the more different kind of users) actively engage in using a
piece of software, the more likely that any particular bug will
surface in someone's experience. And once a bug is identified, it
becomes possible to fix it, improving the software at a faster rate.
Thus is hugely important to the economics of software users, because
customization, debugging and maintenance usually accounts for at
least half (and sometimes considerably more) of the total cost of
ownership of enterprise software.
The point is that open source software is not simply a non-rival
good in the sense that it can tolerate free riding without reducing
the stock of the good for the contributors. It is actually
anti-rival in the sense that *the system as a whole positively
benefits from free riders*. Some (small) percentage of free riders
will provide something of value to the joint product - even if it is
just reporting a bug out of frustration, requiring a new feature, or
complaining about a function that could be better implemented. In
fact one wonders if it makes sense to use the term "free rider"
here. Regardless - the more "free riders" in this setting, the
better. [p.153f.]
Chapter 6: Explaining Open Source: Macrofoundations
===================================================
The first chapter about this chapter:
Chapters 5 and 6 are the core explanation of the open source
process. I break the explanation into two separate buckets [...].
The second bucket is macro-organizational. How do individuals work
with each other and govern that process, in a way that makes their
contributions add up to a joint product? This is the focus of
chapter 6. [p.18]
So this chapter is first about how the coordination in Free Software
functions and second what the governance schemes are and how they
function.
The abstract answer to the coordination problem:
Albert Hirschmann's classic argument from *Exit, Voice and Loyalty*
is a useful metaphor here. While the open source *process*
certainly encourages the use of voice, open source *licenses* are
designed explicitly to empower exit rather than loyalty as the
alternative when voice fails. The core freedom in free software is
precisely and explicitly the right to fork. All other driving forces
are present in the open source process, and they are embedded in a
culture that encourages intense and vehement disagreement. What
holds the process together? In an abstract sense, the answer must be
some combination of loyalty and raising the perceived behavioral
costs of exit high enough that people put real effort into voice and
stay with it long enough to solve coordination problems. More
precisely, a combination of individual incentives, cultural norms,
and leadership practices make up the solution. [p.159]
The chapter goes on to look at each of these elements.
About the (non-)incentives to fork:
Young's argument can be broadened by focusing on the power
asymmetries at play. The potential leader of a forked code base is
not in a powerful position, at least to start. Because the leader
depends on followers more than the other way around, asymmetric
interdependence favors the potential followers, who will make a free
and voluntary choice about where to invest their work. The dynamic
plays out in an interesting way: The more open a project is and the
larger the existing community of developers working on it, the
harder it is to attract potential followers to a fork. This is true
for several reasons. It becomes very difficult for a renegade to
claim credibly that she, as a fork leader, could assemble and hold
together a bigger and better community of developers than is already
working on the main code base. It would not be able to use, test,
debug, and develop software as quickly. Ant it could not provide as
attractive a payoff in reputation, even if reputation were shared
out more evenly within the forked community. If innovation slows,
the pie shrinks. And reputation depends at least in part on the
number of people who know of your repute - which means the larger
the audience, the more reputation you receive in return for any
particular innovation. Forking would split the audience [p.160]
About norms and their general definition:
In an important book *Order without Law*, Robert Ellickson lays out
three criteria that make up a plausible negative baseline, arguing
that a norm should be said *not* to exist if:
* Close-knit participants do not punish persons whom they know have
violated the norm.
* Ordinary behavior is mostly not in accordance with the norm.
* Group members' aspirational statements are inconsistent with the
norm.
[p.161]
A first core set of norms is about "ownership customs":
There are three typical ways in which someone (or some group) in
practice acquires this kind of "ownership". The first is simply to
initiate the project. [...] The second is to have ownership passed
on to you, explicitly and publicly, by the existing owner. [...] The
third way to acquire ownership is to pick up a project that appears
to be abandoned - that is, when the presumptive owner has
disappeared from the scene without passing on the mantle. [p.161f.]
A second core set of norms is about decision-making roles:
For the vast majority of open source projects, this is
straightforward. When there are just a few developers working on a
project, the right to make decisions about the code is coterminous
with ownership. For medium-sized projects, the norm is somewhat
subtler: Authority follows and derives from responsibility. The more
work an individual contributes and the more she takes responsibility
for a piece of the project, the more decision-making authority she
gains. This norm is backed up by an auxiliary norm that seniority
rules in disagreements over who has responsibility for a piece of
code. [p.163]
[...]
Decision-making norms become more complex and interesting in the
(relatively small number of) large-scale open source projects.
Linux, for example, took on a formal differentiated role structure
for decision-making as the project grew in size. [I.e. the
lieutenant model] [...] If this sounds very much like a hierarchical
decision structure, that is because it is one - albeit one in which
participation is strictly voluntary. [p.163f.]
A third core set of norms is about technical rationality:
Technical rationality starts out with the foundational assumption
that there exist technical solutions to technical problems. This may
sound banal or naïve, depending on your viewpoint; but it sets an
important tone for the way people fight out their disagreements.
Naïve, uneducated or even highly imaginative but undisciplined
opinions are extruded from the discussion. Logical arguments made on
technical grounds are the primary currency of the debate. How to do
something is a more important contribution than the idea that it
should be done. [p.164]
About the importance of technical rationality compared to moral
arguments:
The core statement of the Open Source Initiative reflects the
explicit victory of technical rationality: "We think the economic
self-interest arguments for open source are strong enough that
nobody needs to go on any moral crusades about it." [p.165]
About leadership practices in big projects (here citing the example of
Linux / Linus Torvalds):
It is clear that leadership played a critical role in getting the
project started, setting an initial focal point, and maintaining
coordination on it. [p.166]
Torvalds's leadership helped to maintain the calculations behind
this bet [that contributions of developers would be efficacious]. An
important part of this lies in his role first as the articulator and
second as a continuing reinforcer of the community's cultural norms.
[p.167]
While he [Torvalds] is not shy and does not deny his status as
leader, he does make a compelling case that he was not and is not
motivated by fame and reputation. The documented history,
particularly the archived email lists, support him on this point. He
continues to emphasize the fun of programming and opportunities for
self-expression and claims "the feeling of belonging to a group that
does something interesting" as his principal motivation. [p.167]
About when leadership fails:
The core question about leadership then becomes, How can a leader
fail his followers? The simple answer, which captures the unusual
power dynamic, is "lack of responsiveness to those led." In practice
there are several related ways in which this can happen (and has
happened). The shared core is a failure to act as an effective
moderator. [p.168f.]
Two examples of ineffective moderation are listed. A leader can fail
* because of personality issues - when the leader doesn't have the
right style, doesn't make contributors feel good about their work
(even when it is rejected), or otherwise exacerbates the
underlying potential for ego-based conflicts. [p.168]
* by making a series of design decisions that followers find faulty.
[p.168]
However, failures in leadership are to be distinguished from a fork
for technical reasons:
Of course, even a proficient and respected leader may at some point
develop fundamentally different technical visions for the future of
the project than some subset of followers hold. In that case, the
issue is not really leadership failure but the technical direction
of the project. Forking can occur for technical reasons rather than
a breakdown of leadership *per se*. And that is not always a bad
thing, nor does the open source community always perceive it as bad.
[p.168]
The second part of the chapter is about how complexity is governed. It
starts with a definition of governance as it is used by the author and
poses the core question:
When I use the term "governance" in this discussion, I am using it
in the way it is used un international relations. In that context
"governance" is not government, it is typically not authoritative,
and in fact it is not about governing in a traditional sense as much
as it is about setting parameters for voluntary relationships among
autonomous parties. Given that perspective, the central question
becomes, How has the open source process used technology along with
both new- and old-style institutions of governance to manage
complexity among a geographically dispersed community not subject to
hierarchical control? The answer has four elements: technical
design, sanctioning mechanisms, the license as explicit social
structure, and formal governance institutions. [p.172]
The chapter then talks about these four elements. About technical
design:
The key characteristic of technical design for managing complexity
is "source code modularization." [p.172]
One example for this modularization in Linux is the invention of
kernel modules as a way to separate a at first monolithic, huge
program into a number of small, cooperating modules:
As Torvalds put it, "Managing people and managing code led to the
same design decision. To keep the number of people working on Linux
coordinated, we needed something like kernel modules."
Torvalds's implicit point is simple and crucial: These engineering
principles are important because they reduce organizational demands
on the social and political structure for managing people. [p.173]
This is also formulated as Conway's Law:
In 1968 Melvin Conway made an argument about this relationship that
software developers now call Conway's Law. This is the idea that the
structure of the (technical) system mirrors the structure of the
organization that developed it. According to Conway, it is first and
foremost a consequence of the communication needs of the people
building the system. [p.174]
The second element is sanctioning:
As a political scientist, I am innately pessimistic about the
stability of communities. When a complex political system seems to
operate effectively, it is never sufficient simply to explain
success. What you have to explain is the lack of failure, which is
subtly different. The challenge is to assume that there are
individuals somewhere in the system who, if given an opportunity,
will act opportunistically, take advantage of situations in which
others play by the rules, exploit trust, and act in similar ways
that benefit the "cheater" in the short term but pose a threat to
the aggregate good. [...] Human systems have mechanisms to exact
costs on people who try to break the rules and norms of a community.
If a developer working in a company is not following the rules, he
will be fired. In that case he cannot take the code with him because
the company owns the rights to it. Obviously these sanctions (along
with others) loom in the background and act as a deterrent to
antisocial behavior within a proprietary production process. The
question then becomes how does the open source community, which
cannot fire people or deprive them of access to code, sanction rule-
and norm-breakers whose actions might place at risk the
sustainability of the process? [p.175]
About flaming and shunning as sanctioning mechanisms:
"Flaming" is the most visible form of sanctioning in open source.
Flaming is public condemnation (in the sense that email lists and
the web are public) of people of companies that violate norms.
Flamefests can be quite fierce, but they also tend to be
self-limiting for several reasons. First developers understand the
adage about sticks and stones when it comes to breaking bones or in
this case changing behavior. Flaming might make a person
uncomfortable; and there are costs in that, but not necessarily
decisive ones. Second there is a constraint on flaming that arises
from the foundational consensus on technical rationality. Developers
flame each other when they have ideological disputes, disagreements
about the norms of behavior in the open source community itself, or
sometimes for extreme personal issues. They do not flame each other
in the same way over technical issues. When the dispute is about
code, you criticize the code and not the person who wrote it. Unlike
many academic disciplines, you cannot enhance your reputation in the
open source community by attacking the competence of another
developer. Third, because flaming happens in archived text that
everyone in the community can read, developers with less of a stake
in the dispute tend to keep a finger on the pulse of important
flamefests and intervene to stop them when things go too far.
What makes flaming effective - its very public nature - is what
gives the broader community de facto oversight of just how long it
is permitted to go on. The public context also enhances the way in
which flamefests serve as a means for discussing, deconstructing,
and reconstructing the normative consensus around what are
acceptable and unacceptable behaviors within the community. Because
the lists are archived, they also serve as a valuable education and
socialization function for new developers who are just starting to
work with open source. But flaming by itself would not be effective
in constraining a determined opportunist or for that matter a
stubborn developer with very strong hold beliefs (and there are
plenty of these). The more important form of sanction in a
functional sense is "shunning".
To shun someone - refusing to cooperate with them after they have
broken a norm - cuts them off from the benefits that the community
offers. [p.176]
The third element is about licenses as social structure:
In the absence of hierarchical authority the license becomes the
core statement of the social structure that defines the community of
open source developers who participate in a project. [p.179]
The core constitutional message of an open source license is
fashioned as a statement to the developers. And the foremost
statement is that they will be treated fairly if they join the
community. At that very general level, the statement is partly a
result of the open source process itself. In practice, most
developers who participate in open source expect to be on both sides
of a license - that is, acting at different times as licensor and
licensee. [p.179]
While looking at the Debian social contract this part also contains a
statement about meritocracy:
The implicit principle is *meritocracy* - in this community,
developers are given equal opportunity to succeed (or to fail) based
on how good they are as coders. This is an important principle
precisely because it is difficult to implement in practice. The
owner of software code in the commercial world would obviously has
substantial special rights - she decides when to hire and fire
developers, how to share out the wealth that is generated, what the
future direction of development will and will not be. The "owner" in
the open source world also has special rights. The open source
process does not completely eliminate the gap between privileged and
nonprivileged players, so it cannot promise a perfect meritocracy.
What it does do is minimize that gap in several ways. Eliminating
license fees and royalties from the equation means that the
privileged person cannot get direct monetary gain from the work of
others. More importantly, by creating the right to fork code, the
open source process transfers a very important source of power from
the leader to the followers. The privileges that come with
leadership then depend on the continuous renewal of a contingent
grant from the community. This comes as close to achieving practical
meritocracy as is likely possible in a complex governance situation.
[p.180f.]
The fourth element is about formal governance structures:
All complex production processes need governance mechanisms to make
them work. Two things about governance structures in open source are
distinctive. The first is the need for an organizational form that
supports (or even better, takes advantage of) asynchronous
communication. [...] The second is a slight twist on the notion of
hierarchy. That there is no hierarchy for the division of labor -
that is, assigning tasks to particular individuals - lies at the
heart of the open source process. There can be a hierarchy of
decision-making, for vetting and incorporating the results of
distributed work, yet participation in that decision-making
hierarchy is voluntary and remains voluntary for any individual
developer, because it is always possible to exit and fork. [p.186]
The chapter closes with this summary:
The open source process is an ongoing experiment. It is testing an
imperfect mix of leadership, informal coordination mechanisms,
implicit and explicit norms, along with some formal governance
structures that are evolving and doing so at a rate that has been
sufficient to hold surprisingly complex systems together. There is
no off-the-shelf template for coordination and notauthoritative
governance of complexity in the open source setting. What this
chapter demonstrates instead is a diverse set of experiments, a
challenging environment that brings out the "bugs in the system,"
and an imperfect but recursive and self-conscious error-correcting
mechanism that is trying to find solutions that work. [p.189]
Chapter 7: Business Models and the Law
======================================
The first chapter about this chapter:
Chapter 7 explores some business and legal issues. The open source
process does not exist on its own; it enters an ecology of business
and law that is densely populated by institutions that do things
according to a different set of principles and rules. Yet open
source needs to interact, deeply and effectively, with existing
structures of capitalist economies and legal structures like
copyright, patent law, and licensing. The most interesting set of
propositions begins to emerge where the two interface. [p.18f.]
The chapter outlines the general relationship between producers and
users of software and how Free Software impacts here. It then goes
through a couple of business models around Free Software and continues
to reflect a number of examples where capitalist business and Free
Software are in close contact. It touches a couple of topics around
several intellectual property concepts and closes with formulating
questions for the future.
Chapter 8: The Code That Changed The World?
===========================================
The first chapter about this chapter:
Chapter 8 summarizes the book and draws out implications. I explore
some nascent answers to the broader questions that open source
raises about political economy in the Internet-enabled environment.
And I spell out implications for thinking about the problem of
cooperation in a general sense, and specifically in an international
setting. The general topics include the importance of shifting
property rights, the function(s) of a technological commons, the
logic of distributed innovation, technology transfer and economic
growth, new forms of power within networked communities, and the
very interesting and timely problem of understanding interactions
between differently structured organizations, specifically networks
and hierarchies. [p.19]
This quote nicely summarizes the meaning of open source as it is
understood in this chapter:
Open source is a way of organizing production, of making things
jointly. The baseline problem is that it is not easy for human
beings to work together and certainly not to produce complex
integrated systems. One solution is the familiar economy that
depends on a blend of exclusive property rights, divisions of labor,
reduction of transaction costs, and the management of
principal-agent problems. The success of open source demonstrates
the importance of a fundamentally different solution, built on top
of an unconventional understanding of property rights configured
around distribution. Open source uses that concept to tap into a
broad range of human motivations and emotions, beyond the
straightforward calculations of salary for labor. And it relies on a
set of organizational structures to coordinate behavior around the
problem of managing distributed innovation, which is different from
division of labor. None of these characteristics is entirely new,
unique to open source, or confined to the Internet. But together,
they are generic ingredients of a way of making things that has
potentially broad consequences for economics and politics.
This book explains the open source process - how it came to be, how
it operates, how it is organized. I put forward a compound argument
about individual motivations, economic logic, and social structure
to account for a process that reframes the character of the
collective action problem at play. This argument yields insights
into the nature of collaboration in the digital economy. It also
yields insights about how human motivations operate in that setting
and the possibilities of conflict management that result. At a
minimum these are pragmatic demonstrations about a production
process within, and as a product of, the digital economy that is
quite distinct from modes of production characteristic of the
predigital era. There are broader possibilities. The key concepts of
the argument - user-driven innovation that takes place in a parallel
distributed setting, distinct forms and mechanisms of cooperative
behavior regulated by norms and governance structures, and the
economic logic of "antirival" goods that recasts the "problem" of
free riding - are generic enough to suggest that software is not the
only place where the open source process could flourish. [p.224f.]
The chapter goes on to look at aspects mentioned here. It starts with
looking once more at the notion of property. From this part I'd like
to quote one very interesting comparison of changing property rights
in a wider sense. Here the notion of property rights in stewardship
combined with distribution is looked at:
As an example, consider modern religious traditions in the
contemporary United States. What does a rabbi own, or more
precisely, what is his or her property relationship to a tradition?
Religious leaders at one time held essentially exclusionary keys to
traditions. The Jerusalem Temple locked up the Torah within a holy
of holies; only the high priests could enter. Blessings, sacraments,
and rituals were under Rabbinic control. Excommunication as it was
practiced in the Catholic Church is the essence of an exclusionary
property rights. I am less concerned here with how these rights
changed than with the stark differences they exhibit today.
Certainly a rabbi no longer owns a tradition in the sense that he or
she can exclude you from taking a piece of it, modifying it, and
combining it with other traditions in ways that suit your own needs.
[...] In effect, the property rights regime is much like open
source. People take the religious "code," modify it, recombine it
with pieces of code from elsewhere, and use the resulting product to
scratch their spiritual itch.
It is only one small step from there to redistributing what you have
created to others as a "new" religion, which is increasingly a
common practice. [...] More generally, there has been a dramatic
change in what it means to be a leader in a religious community.
Change the foundations of property, and you change the network of
relationships that radiate outward from that which is owned, in
fundamental and often unexpected ways. [p.228f.]
The part about property concludes:
These experiments imply something about property that is both simple
and profound. The problem is not just that the current regime is
conceptually insecure. The problem is that technology has made
visible the fact that it does not work very well in practice, and
that other things that are not supposed to work, do. [p.231]
The next part of the chapter is about organizing for distributed
innovation. A key notion is that of end-to-end innovation:
End-to-end innovation [where the innovation is done at the ends of a
"stupid" network] goes a step beyond simply reduced transaction
costs. It enables parallel processing of a complex task in a way
that is not only geographically dispersed but also functionally
dispersed. End-to-end architecture takes away the central decision
maker in the sense that no one is telling anyone what to do or what
not to do. This is the essence of *distributed innovation*, not just
a division of labor. [...] Innovation is incentivized and emerges at
the edges; it enters the network independently; and it gets
incorporated into more complex systems when and if it improves the
performance of the whole. [p.233]
However, end-to-end innovation needs organization to work properly:
The underlying problem here is to specify general organizational
principles for distributed innovation, a problem-solving algorithm
that works. The open source process suggests that there are four
principles:
* *Empower people to experiment.* This is a familiar concept. To
make it work depends on technology (people need easy access to
tools) and on socially constructed incentives.
* *Enable bits of information to find each other.* This is an
engineering concept. A diverse set of experiments will produce a
little signal and a lot of noise, and in many different places.
The bits of information that are signal need to be able to find
each other and to recognize each other as signal.
* *Structure information so it can recombine with other pieces of
information.* This is also an engineering concept, an extension of
the notion of modularization. Signals need to be essentially to be
in the same "language" so, when they find each other, they can
recombine without much loss of information.
* *Create a governance system that sustains this process.* This is a
social concept, often (but not necessarily) expressed in rules and
law. The GPL prevents this private appropriation of a solution,
which is an important part of what governance needs to do.
Governance of a distributed innovation system also needs to scale
successfully (organized effectively, more eyeballs really are
better than fewer). And it needs to do this at relatively low
overhead costs.
[p.243f.]
This part concludes:
I don't need to indulge in that here simply to point out that the
next generation of end-to-end innovation will depend on lots of
software code, reliable code, but most importantly compatible code,
recombinant code that interfaces straightforwardly with other code.
The open source process has shown that it is possible to build this
kind of code within its own end-to-end, distributed innovation
setting. The next chapter in the story of distributed innovation
will probably be an order of magnitude more surprising in its
revolutionary implications, and make the consequences of the
first-generation Internet seem quaint. [p.243]
The next part thinks about the role of commons in economic and social
life. It mentions Garrett Hardin's "tragedy of the commons" but gives
a couple of points why this is not the only possible way to think
about commons:
Heller and Eisenberg call this [substitution of existing but by ways
of intellectual property rights unavailable resources] "the tragedy
of the anticommons" to distinguish it from the routine underuse that
is a part of any functioning intellectual property rights system
(and is justified as a bargain for incentivizing production in the
first place). This is not just theory; it is an increasingly visible
problem - for example in pharmacogenomics research in which complex
and overlapping patent claims on genetic code make it difficult to
assemble the package of rights needed to produce a drug. [p.245]
There is a second argument about the function of a commons that is
less frequently made explicit. This argument points to the
participation in creative activity by individuals, simply for the
sake of participation itself. In other words creative action is an
individual good regardless of whether it contributes to measurable
aggregate creativity, innovation or social welfare. [...] We value
the explosion of individual creativity facilitated by the web even
though the vast majority of what is "published" there adds little
that is measurable to society's stock of knowledge. [p.246]
The part concludes:
These claims about the social and economic importance of the commons
are not to say that Hardin was mistaken - rather, that he saw only
part of the picture. [p.247]
The open source process and the analytics of the commons that
follows from it help to illuminate some of the upside implications
of a different property rights regime. Neither regime necessarily
drives out the other; they have coexisted for some time and will
probably continue to do so, even though the boundaries may shift.
Move the boundaries and some things will not be produced. Some
incentives will unravel. Something will be lost. On the other hand,
something will be gained as well. It is harder in some sense to
label and name those gains because we are still in the midst of
developing a language to talk about them and a set of arguments to
categorize and evaluate them. [p.248]
The next parts talks about the opportunities of Free Software for
developing countries.
The following part is about power, transaction costs, and community.
It starts with outlining that the connectivity of the Internet and the
processing power of modern computers is often seen with a market
exchange in mind. From this I'd like to quote a very nice point about
the meaning of a price such an environment:
Imagine a smart chair, connected to a lot of other smart things,
which huge bandwidth between them, bringing transaction costs
effectively to zero. Now ask yourself, With all that processing
power and all that connectivity, why would a smart chair (or a smart
car or a smart person) choose to exchange information with other
smart things through the incredibly small aperture of a "price"? A
price is a single monolayered piece of data that carries
extraordinarily little information in and of itself. (Of course it
is a compressed form of lots of other information, but an awful lot
is lost in the process of compression.) The question for the perfect
market that I've envisioned above is, Why compress? My point is that
even a perfect market exchange is an incredibly thin kind of
interaction, whether it happens between chairs or between people,
whether it is an exchange of goods, ideas, or political bargains. I
want to emphasize that communities, regimes, and other public
spheres can come in many different shapes and forms. The
"marketized" version is only one, and it is in many ways an
extraordinarily narrow one that barely makes use of the technology
at hand. [p.257]
The next part of this chapter thinks about networks, hierarchies, and
the interface. It argues that the interface between a network and a
hierarchy is typically a very creative place:
I am certain that some of the most interesting processes in
international politics and economics over the next decade are going
to take place in this space, at the interface between hierarchies
and networks (rather than solely within either one). [p.264]
The final part of the final chapter is about generalizing open source:
The success of open source is a story about software. If it were
only that, it would still be important for social scientists
thinking about cooperation problems. And it would still have
significant implications for economic growth and development. That
is the minimum case. If the open source process has more general
characteristics, if it is a generic production process for knowledge
that can and will spread beyond software *per se*, then the
implications might be considerably larger. My purpose here is not to
take a definitive position on this question, but rather to lay out
some of the conditions that embed it. [p.264]
The book closes by outlining these conditions:
The open source process is more likely to work effectively in tasks
that have these characteristics:
* Disaggregated contributions can be derived from knowledge that is
accessible under clear, nondiscriminatory conditions, not
proprietary or locked up.
* The product is perceived as important and valuable to a critical
mass of users.
* The product benefits from widespread peer attention and review,
and can improve through creative challenge and error correction
(that is, the rate of error correction exceeds the rate of error
introduction).
* There are strong positive network effects to use of the product.
* An individual or a small group can take the lead and generate a
substantiative core that promises to evolve into something truly
useful.
* A voluntary community of iterated interaction can develop around
the process of building the product.
Some of these hypotheses shade off into arguments about the
motivations and capabilities of the agents. To be more precise, the
open source process is likely to work effectively when agents have
these characteristics:
* Potential contributors can judge with relative ease the viability
of the evolving product.
* The agents have the information they need to make an informed bet
that contributed efforts will actually generate a joint good, not
simply be dissipated.
* The agents are driven by motives beyond simple economic gain and
have a "shadow of the future" for rewards (symbolically and
otherwise) that is not extremely short.
* The agents learn by doing and gain personally valuable knowledge
in the process.
* Agents hold a positive normative or ethical valence toward the
process.
These are expansive hypotheses; the parameters in many instances
would be hard to measure and specify *a priori*. As is the case for
many such hypotheses about social processes, they are broadly
indicative of the kinds of conditions that matter. They tell you
where to look, and even more so where not to look, for answers. That
may not be fully satisfying, but it's not a bad place to start when
you are looking ad something so intriguing and at the same time
unfamiliar. [p.271f.]
Which expresses the research challenge of Oekonux quite well |:-)|. In
fact I think the characteristics Steven Weber outlines are a very
useful additional set of criteria to think about when thinking about a
`germ form`_.
.. ############################################################################
.. _The Success of Open Source: http://www.hup.harvard.edu/catalog/WEBSUC.html
.. _Steven Weber: http://www.polisci.berkeley.edu/Faculty/bio/permanent/Weber,S/
.. _germ form: http://en.wiki.oekonux.org/GermForm
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de