Tag Archives: online collaboration

Open Source Communities – Mapping and Segmentation

I’ve just finished “Linked” by Albert-Laszlo Barabasi (review to come shortly) and the number of applications of his thesis are startling.

A New Map for Open Source Communities

The first that jumps to mind is how it nicely the book’s main point provides a map that explains both the growth and structure of open source communities. Most people likely assume that networks (such as an open source community) are randomly organized – with lots people in the network connected to lots of other people. Most likely, these connections would be haphazard, randomly created (perhaps when two people meet or work together) and fairly evenly distributed.


If an open-source community was organized randomly and experienced random growth, participants would join the community and over time connect with others and generate new relationships. Some participants would opt to create more relationships (perhaps because they volunteer more time), others would create fewer relationships (perhaps because they volunteer less time and/or stick to working with the same group of people). Over time, the law of averages should balance out active and non-active users.

New entrants would be less active in part because they possess fewer relationships in the community (let’s say 1 or 2 connections). However, these new entrants would eventually became more active as they made new relationships and became more connected. As a result they would join the large pool of average community members who would possess an average number of connections (say 10 other people) and who might be relatively active. Finally, at the other extreme we would find veterans and/or super active members. A small band of relatively well connected members who know a great deal of people (say 60 or even 80 people).

Map out the above described community and you get a bell curve (taken from the book Linked). A few users (nodes) with weak links and a few better connected than the average. The bulk of the community lies in the middle with most people possessing more or less the same number of links and contributing more or less the same amount as everyone else. Makes sense, right?

Or maybe not. People involved in open-source communities probably will remark that their community participation levels does not look like this. This, according to Barabasi, should not surprise us. Many networks aren’t structured this way. The rules that govern the growth and structure of many network – rules that create what Barabasi terms “scale-free networks” – create something that looks, and acts, very differently.

In the above graph we can talk about about the average user (or node) with confidence. And this makes sense… most of us assume that there is such thing as an average user (in the case of opensource movements, it’s probably a “he,” with a comp-sci background, and an avid Simpson’s fan). But in reality, most networks don’t have an average node (or user). Instead they are shaped by what is called a “power law distribution.” This means that there is no “average” peak, but a gradually diminishing curve with many, many, many small nodes coexisting with a few extremely large nodes.


In an open source community this would mean that there are a few (indeed very few, in relation to the community’s size) power users and a large number of less active or more passive users.

Applying this description to the Firefox community we should find the bulk of users at the extreme left. People who – for example – are like me. They use Firefox and have maybe even registered a bug or two on Firefox’s Bugzilla webpage. I don’t know many people in the community and I’m not all the active. To my right are more active members, people who probably do more – maybe beta test or even code – and who are better connected in the community. At the very extreme and the super-users (or super nodes). These are people who contribute daily or are like Mike Shaver (bio, blog) and Mike Beltzner (bio, blog): paid employees of the Mozilla corporation with deep connections into the community.

Indeed, Beltzner’s presentation on the FireFox community (blog post here, presentation here and relevant slides posted below) lists a hierarchy of participation level that appears to mirror a power law distribution.


I think we can presume that those at the beginning of the slide set (e.g Beltzner, the 40 member Mozilla Dev Team and the 100 Daily Contributors) are significantly more active and connected within the community than the Nightly Testers, Beta Testers and Daily Users. So the FireFox community (or network) may be more accurately described by a Power Law Distribution.

Implications for Community Management

So what does this mean for open source communities? If Barabasi’s theory of networks can be applied to open source communities – there are at least 3 issues/ideas worth noting:

1. Scaling could be a problem

If open source communities do indeed look like “scale-free networks” then it maybe be harder then previously assumed to cultivate (and capitalize on) a large community. Denser “nodes” (e.g. highly networked and engaged participants) may not emerge. Indeed the existence of a few “hyper-nodes” (super-users) may actually prevent new super-users (i.e. new leaders, heavy participants) from arising since new relationships will tend to gravitate towards existing hubs.

Paradoxically, the problem may be made worse by the fact that most humans can only maintain a limited number of relationships at any given time. According to Barabasi, new users (or nodes) entering the community (or network) will generally attempt to forge relationships with hub-like individuals (this is, of course, where the information and decision-making resides). However, if these hubs are already saturated with relationships, then these new users will have hard time forging the critical relationships that will solidify their connection with the community.

Indeed, I’ve heard of this problem manifesting itself in open source communities. Those central to the project (the hyper nodes) constantly rely on the same trusted people over and over again. As a result the relationships between these individuals get denser while the opportunities for forging new relationships (by proving yourself capable at a task) with critical hubs diminishes.

2. Segmentation model

Under a Bell Shaped curve model of networks it made little sense to devote resource and energy to supporting and helping those who participate least because they made up a small proportion on the community. Time and energy would be devoted to enabling the average participant since they represented the bulk of the community’s participants.

A Power Law distribution radically alters the makeup of the community. Relatively speaking, there are an incredibly vast number of users/participants who are only passively and/or loosely connected to the community compared to the tiny cohort of active members. Indeed, as Beltzner’s slides point out 100,000 Beta testers and 20-30M users vs. 100 Daily Contributors and 1000 Regular Contributors.

The million dollar question is how do we move people up the food chain? How do we convert users and Beta testers and contributors and daily contributors? Or, as Barabasi might put it: how do increase nodes density generally and the number of super-nodes specifically?Obviously Mozilla and others already do this, but segmenting the community – perhaps into the groups laid out by Beltzner – and providing them with tools to not only perform well at that level, but that enable them to migrate up the network hierarchy is essential. One way to accomplish this task would be to have more people contributing to a given task, however, another possibility (one I argue in an earlier blog post) is to simply open source more aspects of the project, including items such as marketing, strategy, etc…

3. Grease the networks nodes

Finally, another way to over come the potential scaling problem of open source is to improve the capacity of hubs to handle relationships thereby enabling them to a) handle more and/or b) foster new relationships more effectively. This is part of what I was highlighting on my post about relationship management as the core competency of open source projects.


This post attempts to provide a more nuanced topology of open source communities by describing them as scale-free networks. The goal is not to ascertain that there is some limit to the potential of open source communities but instead to flag and describe possible structural limitations so as to being a discussion on how they can be addressed and overcome. My hope is that others will find this post interesting and use its premise to brainstorm ideas for how we can improve these incredible communities.

As a final note, given the late hour, I’m confident there may be a typo or two in the text, possible even a flawed argument. Please don’t hesitate to point either out. I’d be deeply appreciative. If this was an interesting read you may find – in addition to the aforementioned post on community management – this post on collaboration vs cooperation in open source communities to be interesting.

Messina and Firefox

So I know I’m late to the party but wanted to contribute some thoughts to the Messina debate on Mozilla.

What I find most interesting are not the specifics of the discussion, but the principles beings discussed and the manner by which they are being discussed.

Break Messina piece down and he is essentially making two assertions:

1. “I don’t understand Mozilla’s strategy” and (unsurprisingly!) here are my ideas
2. “Let the community rule”

The response, has been fairly quiet. Some were clearly frustrated. Others saw it as an opportunity to raise their own pet issues. What I haven’t seen (on Planet Mozilla) is a post that really engages Chris’ ideas and says “I don’t agree with Chris on ‘a’ or ‘b’, but he’s right about ‘c.’ ” To be fair, it’s hard to react well to criticism – especially from someone you count on as an ally. When you spend your day fighting billion dollar beasts you don’t exactly want to spend time and energy defending your rear.

However, the silence risks increasing the gap between Mozilla and those who agree with Chris (which judging from his blog may or may not be a fair number of people). I was struck that one commentator said: “I didn’t know somebody could talk like this about Firefox until now.” Such a comment should be a red flag. If the community has some sacred cows or self-censors itself, that’s a bad sign. For this, and other reasons, the thrust of Messina-like rant’s may have significant implications for the future of Mozilla.

The problem is that as the Mozilla community grows and the choices for where to concentrate resources become less and less ‘obvious,’ the community members will increasingly want be part of the strategic decision-making process. When the objective is clear – build a better open browser – its easy to allocate my scarce economic resources towards the project because the aim is obvious (so I either buy-in or I don’t). But as success takes on more nebulous meaning, I need to understand why I should allocate my time and energy. Indeed, I’m more likely to do so if a) I understand the goal and b) I know I can help contribute to deciding what the goal should be.

In this regard Mozilla need to constantly re-examine how it manages strategy and engages with its community (which I know it does!). Personally, I agree with Messina that Mozilla is not a browser company. Indeed, in a previous (not entirely well formed) post, I argue that Mozilla’s isn’t even a software company. Mozilla’s is a community management organization. Consequently its core competency is not coding, but community management. The concern (I think) I share with Messina (if I read between the lines of his rant) is that as Mozilla grows and becomes more successful the decisions it must make also become increasingly complex and involve higher stakes. The fear is that Mozilla will react by adopting more corporate decision-making processes because a) its familiar – everybody knows how this process works and b) its easy – one can consult, but ultimately decisions reside with a few people who trust (or at least employ) one another.

However, if Mozilla is a community management organization then the opposite is true. Mozilla needs a way to treat its strategy like its code, open to editing and contribution. I know it already strives to do this. But what does open-strategy vs. 2.0 look like? What does community management 2.0 look like? Can Mozilla make its community integral to its strategy development? I believe that at its core, Mozilla’s success will depend on its capacity to facilitate these discussions (I may even use the dreaded term… dialogues). This may feel time consuming and onerous, but it pales in comparison to the cost of losing community members (or not attracting them in the first place).

If Mozilla can crack this problem then rants like Messina’s won’t be a threat, they’ll be an opportunity. Or at least he’ll a place where he can channel them.

Wiki's and Open Source: Collaborative or Cooperative?

This is a follow up to my previous post Community Management as Open Source’s Core Competency which has become the most viewed post on this site. I’ve been meaning to follow it up for some time, sorry for the delay.

Online communities, and in particular their collaborative nature, have been generating a lot of buzz lately. But are online communities collaborative?


The more I reflect on it, the more I suspect the answer is a qualified no. While at present there is a tremendous amount of online cooperation, this is not the same as collaboration. This is not to say the cooperative capacity of online communities has not been a boon, but simply an effort to recognize and concern ourselves, with its limits.

I suspect the world’s most interesting and challenging problems cannot be solved in isolation from, or even in cooperation with ,others. Elegant and effective solutions (those most useful to users or consumers) likely benefit from, and probably require, an interplay of ideas and perspectives. Consequently, for those involved in online collaborative projects – such as Wiki’s or open source – understanding the distinction between cooperation and collaboration is critical. If online communities cannot foster collaboration then they will fall short of the hype and ambitions they have set for themselves. Conversely, communities that figure out how to enable their members to collaborate (as opposed to merely cooperate) may end up having a decisive advantage.

Defining the problem

Why distinguish between collaboration and cooperation? Because the subtle difference between these words describes a lot about where we are versus where we need to be vis-à-vis online communities. Admittedly, Websters’ defines the two words very similarly. However, I would argue that collaboration, unlike cooperation, requires the parties involved in a project jointly solve problems.

Truly collaborative processes enable differing and possibly conflicting views to merge and create something new and previously unimagined (think of Hegel’s thesis and anti-thesis coming together in a synthesis). Many online projects – offered up as collaborative – do not meet this standard. For example, some on-line projects, particularly open-source software projects, break problems down into smaller pieces which are tackled by individuals. Sub-dividing a problem and allowing a network of volunteers to opt-in and provide solutions it is a highly efficient. However, those involved in the project many never need to talk, exchange ideas or even interact. Indeed tricky problems may often end up relying on a single clever hacker, operating alone, to solve a problem. While this can be part of a cooperative effort – people with a common goal contributing labour to achieve it – I’m not sure it is collaborative. Equally, many wiki’s simply replace old information with new information, or rely on an arbiter to settle differences. This is at best cooperative, at worst competitive, but again probably not collaborative. (Side note: Please understand, I do not mean to belittle the incredible success of online communities. Indeed the achievements of open source projects and wiki’s are remarkable. However, my concern is that cooperative approaches may only be able to solve a specific, and limited, problem type. Cultivating collaborative communities may be necessary to solve larger, more complex and interesting problems.)

Why Open-Source systems tend to be cooperative and not collaborative

My guess is that unlike cooperation, online collaboration is rare. Why? Probably because online collaboration it is hard. Few people should find this surprising since face to face collaboration can itself be pretty hard. (I make a living off helping people do it better…) People approach problems with, among other things, different assumptions, stated and unstated goals, and data sets. Effective collaboration requires people to share these differences and resolve them. Anyone who has ever been to a business meeting (even among colleagues from the same company) knows that the process for achieving this is often neither self-evident nor easy. Numerous issues can sabotage collaborative efforts – including those that have nothing to do with the substance of the problem. For example, our ideas often end up being linked to our identity. Even just modifying our idea, or worse, adopting someone else wholesale, can feel like admitting someone else is smarter or better – something that may be difficult to do, especially in a voluntary community where your value and credibility is linked to your capacity to solve problems or provide ideas.

From what I can tell online projects only exasperate the challenges of face to face collaboration. Without personal relationships, trust, body language or even intonation, it is easy for communication to break down. Consequently, it is difficult for people to resolve differences, exchange ideas, or brainstorm freely. In short, it is difficult to collaborate.

Successful online projects seem to manage this by being either a) small – relying on a tight-knit community whose strong relationships enable them to collaborate; or b) large – achieving success by doing the opposite of collaboration: separating problems into discrete pieces that individuals can handle alone.

In the large group scenario, interaction may often be limited to peer review processes where criticism – not constructive problem-solving – is the dominant form of dialogue. Consequently, interactions are limited, and usually arbitrated by some central authority. This has the benefit of capping the level of conflict but the discourse among members may remain highly combative.

Such tension can be healthy: collaboration is inherently conflictual. Most ideas spring from parties sharing differing, conflicting perspectives and jointly working to develop a solution that meets both their interests. Eliminate all conflict and you eliminate the opportunity for new ideas. However, too much conflict and the opportunities for collaboration diminish. Large communities – particularly those involved in projects that have some cache – are insulated from the inevitable burnout and frustration that causes members who skin isn’t “thick enough” to drop out. Other community members jump in and fill their spot. It isn’t pretty, but it is sustainable, in a manner of words.

Some recommendations for community managers

Consequently, the goal of online communities should be to determine how to manage, not eliminate, conflict.
So far, to be collaborative – to enable people to work together and jointly solve problems – online communities appear to have two options: (please send others!)

1) Build relationships between their users – stronger relationships can (although not always) enable people to overcome breakdowns in communication. However, building relationships generally takes time and is to scale. To date, the voting system on the Omidyar network – which rewards those perceived as having ‘good’ behaviours and ideas – is the most effective I have seen to date. Although the behaviours are not defined, one can presume that those with higher ratings are likely to be more trustworthy and easier to collaborate with than those with lower ratings. However, this system does not help users develop collaborative behaviours or skills, it simply rewards those who are already perceived as being more collaborative then the mean. Consequently, users with poor collaborative skills, but possessing expertise or substantive knowledge essential to the success of a project, may struggle to contribute. Even more troubling, the vast majority of your users could be inept at collaborating, and this system will do nothing to raise the bar or improve the community. It will only highlight and identify who is least inept.

2) Develop online communities with built in methodologies and processes that encourage or even compel users to jointly solve problems. Here one can imagine an online community that forces users to work through Chris Argyrisladder of inference. While likely more difficult to design, such a system could compel users to be collaborative (possibly even regardless of their intentions).

A lot of the theory around collaborative decision-making is explored in greater detail in negotiation theory. This post is part of my continuing effort to flesh out how (and even if) negotiation theory can be applied to online collaborative networks… I promise more thoughts in the future – in the meantime please send or post yours!

One closing note – if there is a compelling link between negotiation theory and collaborative online networks then it would suggest a new interesting area for inter-disciplinary studies. For example, Stanford has the Centre for Internet and Society and the Gould Negotiation and Mediation Program. It would be interesting to know if these two centres believe they share this area of mutual interest. Maybe I’ll work up the courage to email Lawrence Lessig and ask…

Community Management as Open Source's Core Competency

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