For the past several years now I’ve been talking about how community management – broadly defined as enhancing a community’s collaborative skills, establishing and modeling behaviour/culture and embedding development tools and communications mediums with prompts that “nudge” us towards collaborative behaviour – is imperative to the success of open source communities. (For those interested in this, my FSOSS 2008 on the subject has been slidecasted here, and is on on google video here.

Re-reading Shirkly’s latest book, Here Comes Everybody, has re-affirmed my thinking. Indeed, it’s made me more aggressive. Why? Consider these two paragraphs:

This ability of the traditional management structure to simplify coordination helps answer one of the most famous questions in all of economics: If markets are such a good idea, why do we have organizations at all? Why can’t all exchanges of value happen in the market? This question originally was posed by Ronald Coase in 1937 in his famous paper “The Nature of the Firm,” wherein he also offered the first coherent explanation of the value of hierarchical organization. Coase realized that workers could simply contract with one another, selling their labor, and buying the labor of others in turn, in a market, without needing any managerial oversight. However, a completely open market for labor, reasoned Coase, would underperform labor in firms because of the transaction costs, and in particular the costs of discovering the options and making and enforcing agreements among the participating parties. The more people are involved in a given task, the more potential agreements need to be negotiated to do anything, and the greater the transaction costs…

And later, Shirky essentially describes the thesis of his book:

But what if transaction costs don’t fall moderately? What if they collapse. This scenario is harder to predict from Coase’s original work, at it used to be purely academic. Now’s it not, because it is happening, or rather it has already happened, and we’re starting to see the results.

My conclusion: the lower the transaction costs, the greater the playing field will favour self-organizations systems like open source communities and the less it will favour large proprietary producers.

This is why open source communities should (and do) work collectively to reduce transaction costs among their members. Enabling the further collapse of transaction costs tilts the landscape in our favour. Sometimes, this can be down in the way we architect the software. Indeed, this is why – in Firefox – Add-Ons are so powerful. The Add-On functionality dramatically reduces transaction costs by creating a dependable and predictable platform, essentially allowing coders to work in isolation from one another (the difference between collaborative vs. cooperative). This strategy has been among the most successful. It is important and should be pursued, but it cannot help collapse transaction costs for all parts of a project – especially the base code.

But what more can be done? There are likely diminishing returns to re-architecting the software and in finding new, easier ways, to connect developers to one another. The areas I think offer real promise include:

• fostering cultures within open source communities that reward collaborative (low transaction cost) behaviour,
• promoting leaders who model collaborative (low transaction cost) behaviour
• developing tools and communications mediums/methods that prompt participants to improve the noise to signal, minimize misunderstandings, limit unnecessary conflict, and help resolve differences quickly and effectively (the idea being that all of these outcomes lower transactions costs).

This is why I continue to think about how to port over the ideas, theories and tools from the negotiation/collaboration field, into the open source space.

For open source communities, eliminating transaction costs is a source of strategic advantage – one that we should find ways to exploit ruthlessly.