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?

Overview

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…

18 thoughts on “Wiki's and Open Source: Collaborative or Cooperative?

  1. Pingback: Community Management as Open Source’s Core Competency

  2. Mike Beltzner

    There’s a subtle tools problem here, and in many cases I think that people do work collaboratively whenever possible, but end up partitioning and co-operating when tools fail them.

    In the realm of Open Source Software Development, for example, I often bear witness to two or more people working together to solve a problem on IRC. The conversation is fluid, collaborative, a back and forth sharing of ideas and a convergence towards a solution that represents the best of all that was put forward.

    But then, once the discussion is over, a single person will write the patch and submit it for review. Many people can look at that code and comment, but only one has the ability to actually do the review which incorporates the feedback. At this point, the tools don’t allow for true collaboration – it’s somewhat muted and forced into being partitioned.

    Throughout the lifecycle of a bug there are many interaction points between people working together on problems, some of which are collaboration and some of which are co-operation.

    I think Wikis suffer some similar tool problems, in that they aren’t tailored towards collaborative editing as much as they are towards sucessive editing. Better tools for indicating “this is still rough” and “what about this approach?”, and for having sidediscussions about those topics, and I think you might see more genuine collaboration.

    Reply
  3. Mike Beltzner

    There’s a subtle tools problem here, and in many cases I think that people do work collaboratively whenever possible, but end up partitioning and co-operating when tools fail them.In the realm of Open Source Software Development, for example, I often bear witness to two or more people working together to solve a problem on IRC. The conversation is fluid, collaborative, a back and forth sharing of ideas and a convergence towards a solution that represents the best of all that was put forward.But then, once the discussion is over, a single person will write the patch and submit it for review. Many people can look at that code and comment, but only one has the ability to actually do the review which incorporates the feedback. At this point, the tools don’t allow for true collaboration – it’s somewhat muted and forced into being partitioned.Throughout the lifecycle of a bug there are many interaction points between people working together on problems, some of which are collaboration and some of which are co-operation.I think Wikis suffer some similar tool problems, in that they aren’t tailored towards collaborative editing as much as they are towards sucessive editing. Better tools for indicating “this is still rough” and “what about this approach?”, and for having sidediscussions about those topics, and I think you might see more genuine collaboration.

    Reply
  4. Pingback: 筆記與流年 » links for 2008-03-04

  5. Paul Biondich

    Came across this in my web browsing… I think you’ve stumbled onto something extremely important here in your distinction. Kudos to you for taking the time to write this, you’ve given me some different language to describe something I’ve been trying to nurture in our open source community for the past 4 years.

    Reply
  6. Paul Biondich

    Came across this in my web browsing… I think you’ve stumbled onto something extremely important here in your distinction. Kudos to you for taking the time to write this, you’ve given me some different language to describe something I’ve been trying to nurture in our open source community for the past 4 years.

    Reply
  7. Pingback: Open Edits to the Mozilla Manifesto & Hello Planet Mozilla | eaves.ca

  8. Pingback: Open Edits to the Mozilla Manifesto & Hello Planet Mozilla | eaves.ca

  9. Pingback: Collaboration - a dirty word rescued by connectivity | eaves.ca

  10. Pingback: My Mozilla Summit 2010 Talk: Making the Army of Awesome more Awesome | eaves.ca

  11. Pingback: How GitHub Saved OpenSource | eaves.ca

  12. Pingback: 创建成功的Python项目 - 博客 - 伯乐在线

  13. Pingback: 创建成功的Python项目 » 全信息

  14. Pingback: 创建成功的Python项目 | dust8

  15. Pingback: Crie projetos bem-sucedidos em Python - Leoweb - Web designer | Leoweb - Web designer

  16. Pingback: Crie projetos bem-sucedidos em Python | iMasters

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s