I finished Steven Weber's "The Success of Open Source" a while ago, but it's taken me a while to make my note-taking pass, and even more time to figure out how to get a decent post out of my notes. Getting this post out has been holding me back from really digging into The Wealth of Networks, so here goes. Weber looks at the phenomenon of open source through the lens of political economy. The major questions from this view point are about motivation of individuals, coordination, and complexity.

One of the interesting conceptual handles that I took out of the book was 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. The computer scientist David Parnas takes this argument a step further by defining a software module as "a responsibility assignment" for a piece of an organization first, and only secondarily as a subprogram.

The open source process relies on a foundational consensus around technical rationality -- that is its stake driven firmly in the ground. It is actively evolving organizational structures around that stack. Thus open source developers really are forced to live by the lessons of Conway's Law. The architecture of the technical system drives the organization, rather than the other way around.

The reason Conway's Law actually works in favor of the open source process is that early architectural formulations are approximations are are always unstable. The formal hierarchical organizations that enclose proprietary software development are resistant to change and often end up driving the technical architecture (the dysfunctional flip side of Conway's Law). In the ideal case the organization should follow this organization rather than lead it.

Conway's Law definitely provides some more food for thought when look at the ASF's community is more important than code mantra.

A key notion in the "commons movement" is that of non-rival goods. Weber takes this a few steps further and gives us another term, "antirival" goods:

I believe the solution to this puzzle lies in pushing the concept of nonrivalness one step further. Software in many circumstances is more than simply nonrival. Operating systems like Linux in particular, and most software in general, actually are subject to positive network externalities. Call it a network good, or an antirival 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

The point is that open source software is not simply a nonrival good in the sense that it can tolerate free riding without reducing the stock of the good for contributors. It is actually antirival in the sense that the system as a whole postively benefits from free riders.

The twist is this: Under conditions of anti-rivalness, as the size of the Internet-connected group increases, and there is a heterogeneous distribution of motivations with people who have a high level of interest and some resources to invest, then the large group is more likely, all things being equal, to provide the good than is a small group

I think that the issues of governance and culture are going to become more important as familiarity with open source practices continues to increase both in software and other fields.

The Internet does not solve foundational problems of organizing complexity. It does not create working divisions of labor. Reducing or even removing the costs of geographically widespread and time-dependent collaboration is important, but that effort still leaves other collaboration costs unsettled -- decision making, human emotion, resolution of technical uncertainties, and so on. In principle, the Internet can increase these difficulties because it can be set up (and in the open source process, is set up) to be non-excludable

When I use the term "governance" in this discussion, I am using it in the way it is used in 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?

Weber uses developments in modern religious communities as another example of reversing power dynamics in communities. I've observed this myself in some (but not all) religious communities.

More generally, there has been a dramatic shift 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 unexpected ways.

I will come back to this point later when I discuss power and communities; but for the moment, recognize an interesting corollary. In nonauthoritative settings -- that is, in relationships primarily characterized as bargaining relationships -- power derives in large part from asymmetrical inter dependence. Put simply, the less dependent party to the relationship (the one who would be harmed least by a rupture) is the more powerful. In the kinds of modern religious communities I am talking about here, it is the leader who is dependent on the followers more than the other way around. This dependence changes the dynamics of power. Leaders of open source projects understand the consequences intuitively -- the primary route to failure for them is to be unresponsive to their followers. In Hirschman's terms, this is a community that empowers and positively legitimates exit while facilitating voice.

There were several interesting points around open source and innovation:

Innovation starts from the edge and migrates to the center as it proves itself -- there is a meritocracy of ideas as well, at least ideally.

End-to-end innovation 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. There are no weak links in the chain because there is, in a real sense, no chain. 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.

This is of course an idealized version of the story. An end-to-end technological architecture may indeed be truly neutral, but technology does not exist on its own. The political and organizational interfaces that touch the technology and link it to human action typically are biased.

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
• Enable bits of information to find each other
• Structure information so that it can recombine with other pieces of information
• Create a governance system that sustains this process

The search problem of local vs global maxima applied to the innovator's dilemma at the level of individuals.

Distributed innovation systems like open source have a simple advantage here that helps compensate for the inherent tendency to stick to debugging an existing architecture. Any single open source developer might suffer from individual versions of the innovator's dilemma in her own decision making about where to invest her time, but the decision as a whole remains disaggregated among the community. ... Ultimately the freedom to fork code distributes much more widely the ability to make different bets on the exploration-exploitation trade-off, and that raises the probability that on aggregate some decisions will pay off. Put simply, end-to-end innovation systems depend on a market logic of disaggregated decisions rather than on a central intelligence to manage the innovator's dilemma.

The challenges facing the application of open source techniques to areas like user interface design.

But it is possible that end-to-end innovations systems will generally underperform in these specific kinds of user interface settings, for two related reasons. Some programmers believe that understanding direct user experience requires extensive physical interaction -- that is focus groups, not internet mailing lists. The more general point here is that design for components like user interfaces still rests on the transmission between individuals of a great deal of tacit information. This requirement makes it difficult to modularize and difficult to develop in parallel distributed settings. End-to-end innovation systems lack a good mechanism for getting at the underlying concepts of tasks like this in novel ways. That may change as advances in information processing move more human experiences out of the tacit realm and into communicable forms, but for now this seems a notable constraint.

Standards and open source: Open source aids standardization preventing the gaming of standards as described in Information Rules: A Strategic Guide to the Network Economy. I wish that open source was doing better at benefitting standardization as a source of unencumbered implementation experience.

In other words, releasing source code is a credible commitment against the possibility of using a standard for technological lock-in and hold up. Proprietary standards cannot make this commitment in the same way.

The success of open source is introducing many kinds of tensions between markets and communities. Weber has an interesting idea for looking at the needs of markets and communities:

In this kind of discourse, the failure of a community to take shape because of high transaction costs is just as much a market failure as is the nonevent of a contract to exchange money for widgets that would make both sides better off but does not happen because the widget owner can't find the buyer. The perfection of markets and the realization of potential communities are theoretically identical.

Weber believes that the next steps in research on open source have a lot less to do with transaction cost economics:

I do not have a full-fledged model to propose at this point, but I suspect any model will have to focus on at least two factors that transaction cost economics does not emphasize. The first is the relationship between problem solving innovation and the location of tacit information, information that is not easily translated into communicable form. ... The second is the importance of principles and values, in contrast to efficiency as an organizing concept.

A few days ago I commented on the difference between projects using open source methodologies and those which are loosely inspired by open source methodologies. I emphasized the governance end (meritocracy vs democracy). Weber also adds the property regime.

Many of these projects gain their ideological inspiration from the open source process and tap into some of the same motivations. Many are interesting experiments in using Internet technologies to organize volunteer efforts and affinity groups. But in many instances, these projects are not organized around the property regime that makes the open source process distinctive.