Message 03586 [Homepage] [Navigation]
Thread: oxenT03547 Message: 2/4 L1 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Re: [ox-en] Steven Weber * The Success of Open Source

[Converted from multipart/alternative]

[1 text/plain]

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>.


Stefan Merten <smerten> 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

      Mit Freien Grüßen


- --- 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.

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

  * *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?


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.

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.*

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.

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.

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

  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

  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; Blog, at; Newsletter, at 

Basic essay at; interview at; video interview, at
Want to start your own business? Learn how on  Yahoo! Small Business. 

[2 text/html]
Contact: projekt

Thread: oxenT03547 Message: 2/4 L1 [In index]
Message 03586 [Homepage] [Navigation]