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.
eaves.ca 
Pingback: why collaborative skills matter in open source | eaves.ca | Open Hacking
whoa, this is terrific post!one question: do hierarchies that are built on merit and performance (like mozilla's meritocratic nature) foster collaboration early on so all can participate? i may be missing your point, but was trying to think about how mozilla fosters success in its community. it seems that a new developer will find a level of credibility and acceptance at mozilla by showing what problem he or she solved with code and how it was done, but not necessarily through collaboration. so, a new developer has to present all that he or she does before actually reaching out for help…just to get in the door… does building a community on meritocracy create a barrier that is an initially very high transaction cost? and, because there is that initial transaction cost, does it persist throughout the culture to try to climb the ranks of the meritocracy?
Seth – I want to be careful commenting since I'm not a coder and what I've learned comes through my conversations with friends within the Mozilla community. Moreover, I don't want my comments to be seen as criticism of how the community is structured – Mozilla is an amazing beast, I'm focused on how we can further improve, and learn from, it.I think you do hit on a point here. That the initial barrier to entry is high, and there is a risk that, for some, credibility only comes by presenting completed solutions and that reaching out before then means you will struggle to get help or acceptance within the community. This could be a barrier hindering community growth and participation. Moreover, this could impact the culture and structure of the meritocracy by self-selecting community members who value work that is completed and who themselves tend to share their work when it is in a finished form.
While it's difficult to argue the success of products like FireFox, Apache's HTTP server or IBM Canada's Eclipse which act as platforms into which an individual can plug whatever she feels like – it's worth mentioning that they all have a high-transaction cost core platform onto which the “swarm” is built.The ability to functionally decompose the software architecture is determined largely by the kind of system you're building – as open source grows to fill every niche the kind of software that can be built in the “tiny widgets loosely joined” method shrinks. Which is why those monolithic open source projects that already exist are so impressive – Linux kernel, WINE, the W3C corpus, PHP, Java, etc.Mozilla's BeSpin (which looks alot like a Web 2.0 version of Sun's Enterprise IDE) is a step in the right direction – code editing becomes an online collaborative (rather than offline cooperative) process. It's Google Docs for Code.The next step is to do a wiki-IDE…
DavidHave a look at one of my favourite old books written by Eric Jantsch called “The self-organizing Universe” It is a superb treatise from the philosophy of science genre looking for meta-theories of change. Written while he was at Berkeley in the 1970's it has not lost its hold on me as a way of understanding how we respond to change from neutron splitting to social organization. I might be able to find you a copy if you do not have access to one at UBC or SFU.Warm regards,Sharon
Hi David,I'm seeing a bit of a gap here, and hoping you can clarify or help me out. The title of the post is “why collaborative skills matter”, but there was little mention of what those actual skills are, other than a need to negotiate and/or focusing on the reduction of transaction costs. Collaborative skills are one of many components that make up soft-skills or interpersonal skills – a crucial element of successful collaborative/cooperative engagement. On something as specific as coding for firefox or open source software, that require little person-to-person interaction, I suppose interpersonal skills are less of a concern, but once we start addressing how groups work together, the technology will only take us so far. Constructive relationships are needed in order to keep us moving forward and the tools now at our disposal can obviously be a significant component to facilitating some of that interaction, but the soft/interpersonal skills that are required to maintain those relationships are getting far too little attention compared to the hard skills. I'm just curious as to whether or not this is implied in your title and needs not be explicit…? Too often it seems in recent discourse on social media and collaborative tools, we focus on the technology and forget about the importance of interpersonal development. The tools are a facilitator but we, as individuals, still have to do the work, make the connections, maintain the relationships.
Sharon – thank you. Let me see if I can locate a copy.
Tariq – this is exactly my point. I think the soft skills (mediation, negotiating, listening) have received less attention than necessary. So I'm in part interested in how we encourage or foster those skills through the tools we use (rather than just calling something that connects people “collaborative” – I've seen too many flame wars on IRC and email to believe they are inherently collaborative) as well as how we can “nudge” people to behave better while using these mediums.
Pingback: why collaborative skills matter in open source | eaves.ca | Intellectual Talk - more than just blogging
Pingback: tending the garden › collaboration = conflict + people
Pingback: Drie Regels voor Open OverheidsData Medialandschap - trends, kunst en technologie