Reaction to this post has been overwhelming – I made it the basis of a presentation at the 2007 Free Software and  Open Source Symposium at Seneca college. You can watch it here as a slidecast.

A good friend of mine, Mike B. and I have been exchanging thoughts on open source projects. Mike’s experience is grounded in the ‘traditional’ world of open source – he works on the web browser Firefox (which if you don’t use, you should). I freely admit my own open source credentials are more suspect – I draw my lessons from my experience engaging in a form of open source public policy through Canada25. Beyond, that, what I know is based on what others are kind enough to share with me, and what I am able to learn through articles, books and podcasts.

For those not interested in the whole spiel below the short version is this:

Companies or foundations that run open source project are not software firms, they are community management firms whose communities happen to make software. Consequently to survive and thrive these projects need to invest less in enhancing governance structures or employees who/that will improve their capacity to code. Instead, we should consider skills and structures that emphasize facilitation, mediation, and conflict management – tools, skills and structures that will enable the community to better collaborate.

More detailed thoughts I’m fleshing out an idea flow that goes something like this:

1. Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package. (I’ll talk more about Canada25 as open source in the future)

1. The core competencies of a community management organization are different from those of a software firm. Specifically, core competencies reside in their capacity to support and enable the community to collaborate and contribute to the project. Furthermore, the community’s contributions will not likely be limited to a single function (such as coding new features) but will need to include all aspects of the projects evolution including discussions about the direction of the software or marketplace and its impact on strategy. As people volunteer more time and become more invested my hypothesis is that they will want (at least) input (not to be confused with decision-making authority) in more strategic decisions.

1. Consequently, the structures and skill sets of those working on an open source initiative need evolve over time:

1. 1. In the beginning, because of their size, open source projects can pretend to be software firms – this is because the community is sufficiently small that everyone knows one another so that levels of trust are high and the need for formal community structures are low. In this earlier phase:

i. Respect and influence is based on raw brain power/problem solving capabilities – rather than seek permission those who code solutions to problems earn respect, and others listen and/or follow their lead

ii. Common values and operating assumptions in the community are not, and don’t need to be encoded – it is small enough that those who ‘get it’ opt in, and those who don’t opt out.

1. 1. Success changes everything. As open source projects becomes increasingly successful (and, possibly, more political) the context around the community changes:

i. Success means more people join the community. This is not only true of the number of people, but also of the type of people (e.g. skill set, cultural background, etc…). This increase places stress on the community infrastructure. Specifically, an increase in participants can:

1. reduce levels of trust and the sense of community, raising transactions costs to effective collaboration

2. erode the assumed common community value as new entrants join the project for different reasons

3. decision-making becomes increasingly complex as the consultative nature of open source projects does not obviously scale. This may cause individuals/groups to feel disenfranchised and/or frustrated (and never underestimate the damage to productivity frustrated people can cause – thank you for this Shaver)

ii. As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.

1. 1. Community Management as Cope Competency. My interest in all this is how we can take the ideas, methodologies and tools that come out of the negotiation/conflict management/collaborative decision-making arena and port them over to the open source space.

i. Training up in facilitation skills. Getting the core group of project employees trained up on how to collaboratively solve problems. Some basics might include:

1. using interests and not positions when resolving disagreements

2. using Chris Argyris’ theories about how (particularly smart technical people) fight over conclusions, by failing to share the data and analysis behind their thinking – often referred to as the ladder of inference.

ii. Rethinking decision-making processes – chiefly by setting expectations of how decisions will be made, what criteria will be applied when making them. It is likely essential to give community members a common set of criteria to use to evaluate decisions, that way they we can reframe discussion from what they like more to what adheres to the communities standards the closest. This is true for technical decisions, but also strategic or governance questions. The key around decision-making is not how democratic it is, but how well we set expectations for community members and then adhere to those expectations.

iii. Open source communities may fear accepting that even greater collaboration and openness is their core competency because it raises the underlying question no one wants to ask: Is the open source model scalable , and competitive?

The false answer is no: To believe that becoming more competitive and/or moving quickly means we need to consult less.

The true answer is yes. We can’t be competitive by running away from our core-competency, if we do that the we end up playing by the rules of the established corporate players, rules that we can’t win using. Forget their playbook, we have to get back in the box. We have to become faster, more efficient and easier to use at what we do best: engaging and enabling everyone in the community (customers, volunteers, etc…) to collaborate.

1. Leaders Matter: The good and bad news is for project leaders – for example, paid employees of the project – is that you are THE role model for the community. Every action you take validates or invalidates certain behaviour types. If a employee behaves in an unconstructive way it will be hard to tell others in the community that this behaviour is out of bounds.

I suspect that most open source projects:

1. 1. Know this
   2. It causes nervousness
   3. Because participants are smart, we rationalize ourselves out of this problem

But… we can’t. And we shouldn’t. This is our single most important chip. It is what allows us to shape the behaviour and culture of the community. Let’s embrace it and use it.

Sorry for the long post – generated out of some thinking with friends at Canada25, Canada2020 and Firefox. Hope you have lots of thoughts, reactions and comments, definitely want to refine my thinking and there is likely a lot of refining to do.

UPDATE: If you found this piece interesting I’ve written a follow up on to this piece, entitled Wiki’s and Open-Source: Collaborative or Cooperative?