This is a recension of the book The Success of Open Source by Steven Weber (Bookzilla hardback, Bookzilla paperback). Stefan Merten read the book.

Discuss the recension on its Wiki page.

---

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

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

---

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.

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.

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.

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.

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.

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. open [...] In effect, the property rights regime is much like 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.