Tag Archives: wikipedia

Mind. Prepare to be blown away. Big Data, Wikipedia and Government.

Okay, super psyched about this. Back at the Strata Conference in Feb (in San Diego) I introduced my long time uber-quant friend and now Wikimedia Foundation data scientist Diederik Van Liere to fellow Gov2.0 thinker Nicholas Gruen (Chairman) and Anthony Goldbloom (Founder and CEO) of an awesome new company called Kaggle.

As usually happens when awesome people get together… awesomeness ensued. Mind. Be prepared to be blown.

So first, what is Kaggle? They’re a company that helps companies and organizations post their data and run competitions with the goal of having it scrutinized by the world’s best data scientists towards some specific goal. Perhaps the most powerful example of a Kaggle competition to date was their HIV prediction competition, in which they asked contestants to use a data set to find markers in the HIV sequence which predict a change in the severity of the infection (as measured by viral load and CD4 counts).

Until Kaggle showed up the best science to date had a prediction rate of 70% – a feat that had taken years to achieve. In 90 days contributors to the contest were able to achieve a prediction rate of 77%. A 10% improvement. I’m told that achieving an similar increment had previously taken something close to a decade. (Data geeks can read how the winner did it here and here.)

Diederik and Anthony have created a similar competition, but this time using Wikipedia participation data. As the competition page outlines:

This competition challenges data-mining experts to build a predictive model that predicts the number of edits an editor will make in the five months after the end date of the training dataset. The dataset is randomly sampled from the English Wikipedia dataset from the period January 2001 – August 2010.

The objective of this competition is to quantitively understand what factors determine editing behavior. We hope to be able to answer questions, using these predictive models, why people stop editing or increase their pace of editing.

This is of course, a subject matter that is dear to me as I’m hoping that we can do similar analysis in open source communities – something Diederik and I have tried to theorize with Wikipedia and actually do Bugzilla data.

There is a grand prize of $5000 (along with a few others) and, amazingly, already 15 participants and 7 submissions.

Finally, I hope public policy geeks, government officials and politicians are paying attention. There is power in data and an opportunity to use it to find efficiencies and opportunities. Most governments probably don’t even know how to approach an organization like Kaggle or to run a competition like this, despite (or because?) it is so fast, efficient and effective.

It shouldn’t be this way.

If you are in government (or any org), check out Kaggle. Watch. Learn. There is huge opportunity here.

12:10pm PST – UPDATE: More Michael Bay sized awesomeness. Within 36 hours of the wikipedia challenge being launched the leading submission has improved on internal Wikimedia Foundation models by 32.4%

Rethinking Wikipedia contributions rates

About a year ago news stories began to surface that wikipedia was losing more contributors that it was gaining. These stories were based on the research of Felipe Ortega who had downloaded and analyzed millions the data of contributors.

This is a question of importance to all of us. Crowdsourcing has been a powerful and disruptive force socially and economically in the short history of the web. Organizations like Wikipedia and Mozilla (at the large end of the scale) and millions of much smaller examples have destroyed old business models, spawned new industries and redefined the idea about how we can work together. Understand how the communities grow and evolve is of paramount importance.

In response to Ortega’s research Wikipedia posted a response on its blog that challenged the methodology and offered some clarity:

First, it’s important to note that Dr. Ortega’s study of editing patterns defines as an editor anyone who has made a single edit, however experimental. This results in a total count of three million editors across all languages.  In our own analytics, we choose to define editors as people who have made at least 5 edits. By our narrower definition, just under a million people can be counted as editors across all languages combined.  Both numbers include both active and inactive editors.  It’s not yet clear how the patterns observed in Dr. Ortega’s analysis could change if focused only on editors who have moved past initial experimentation.

This is actually quite fair. But the specifics are less interesting then the overall trend described by the Wikmedia Foundation. It’s worth noting that no open source or peer production project can grow infinitely. There is (a) a finite number of people in the world and (b) a finite amount of work that any system can absorb. At some point participation must stabilize. I’ve tried to illustrate this trend in the graphic below.

Open-Source-Lifecyclev2.0021-1024x606

As luck would have it, my friend Diederik Van Liere was recently hired by the Wikimedia Foundation to help them get a better understanding of editor patterns on Wikipedia – how many editors are joining and leaving the community at any given moment, and over time.

I’ve been thinking about Diederik’s research and three things have come to mind to me when I look at the above chart:

1. The question isn’t how do you ensure continued growth, nor is it always how do you stop decline. It’s about ensuring the continuity of the project.

Rapid growth should probably be expected of an open source or peer production project in the early stage that has LOTS of buzz around it (like Wikipedia was back in 2005). There’s lots of work to be done (so many articles HAVEN’T been written).

Decline may also be reasonable after the initial burst. I suspect many open source lose developers after the product moves out of beta. Indeed, some research Diederik and I have done of the Firefox community suggests this is the case.

Consequently, it might be worth inverting his research question. In addition to figuring out participation rates, figure out what is the minimum critical mass of contributors needed to sustain the project. For example, how many editors does wikipedia need to at a minimum (a) prevent vandals from destroying the current article inventory and/or at the maximum (b) sustain an article update and growth rate that sustains the current rate of traffic rate (which notably continues to grow significantly). The purpose of wikipedia is not to have many or few editors, it is to maintain the world’s most comprehensive and accurate encyclopedia.

I’ve represented this minimum critical mass in the graphic above with a “Maintenance threshold” line. Figuring out the metric for that feels like it may be more important than participation rates independently as such as metric could form the basis for a dashboard that would tell you a lot about the health of the project.

2. There might be an interesting equation describing participation rates

Another thing that struck me was that each open source project may have a participation quotient. A number that describes the amount of participation required to sustain a given unit of work in the project. For example, in wikipedia, it may be that every new page that is added needs 0.000001 new editors in order to be sustained. If page growth exceeds editors (or the community shrinks) at a certain point the project size outstrips the capacity of the community to sustain it. I can think of a few variables that might help ascertain this quotient – and I accept it wouldn’t be a fixed number. Change the technologies or rules around participation and you might make increase the effectiveness of a given participant (lowering the quotient) or you might make it harder to sustain work (raising the quotient). Indeed, the trend of a participation quotient would itself be interesting to monitor… projects will have to continue to find innovative ways to keep it constant even as the projects article archive or code base gets more complex.

3. Finding a test case – study a wiki or open source project in the decline phase

One things about open source projects is that they rarely die. Indeed, there are lots of open source projects out there that are the walking zombies. A small, dedicated community struggles to keep a code base intact and functioning that is much too large for it to manage. My sense is that peer production/open source projects can collapse (would MySpace count as an example?) but the rarely collapse and die.

Diederik suggested that maybe one should study a wiki or open source project that has died. The fact that they rarely do is actually a good thing from a research perspective as it means that the infrastructure (and thus the data about the history of participation) is often still intact – ready to be downloaded and analyzed. By finding such a community we might be able to (a) ascertain what “maintenance threshold” of the project was at its peak, (b) see how its “participation quotient” evolved (or didn’t evolve) over time and, most importantly (c) see if there are subtle clues or actions that could serve as predictors of decline or collapse. Obviously, in some cases these might be exogenous forces (e.g. new technologies or processes made the project obsolete) but these could probably be controlled for.

Anyways, hopefully there is lots here for metric geeks and community managers to chew on. These are only some preliminary thoughts so I hope to flesh them out some more with friends.

What the post-bureaucratic era will mean for the public service

In a number of blog posts and, in greater detail, in a number of lectures and speeches I’ve been outlining how the social and organizational impact of  information technologies (like wikis and blogs) will uproot and transform the public service. Specifically, in the coming era of self-organizing, the public service will have to find new ways to balance accountability and control with decentralization, accelerated information flows and emergent problem-solving.

There is, obviously, a ton to dive into here, which is what I’ve been having fun doing in my lectures and seminars. The other week while doing a presentation in Ottawa to a group of Health Canada employees, one of the participants asked me what the implications of self-organizing systems and social media would be for the core values of the public service (the Canadian Federal Public Service is the case study here, but this discussion likely applies to most government bureaucracies). More importantly, he wanted to know if they would have to be amended or changed. I’m not certain they do, but that doesn’t mean they won’t need to be reviewed…

For example, zero in on one of the Public Service’s core values in particular:

Professional Values: Serving with competence, excellence, efficiency, objectivity and impartiality.

  • Public servants must work within the laws of Canada and maintain the tradition of the political neutrality of the Public Service.
  • Public servants shall endeavour to ensure the proper, effective and efficient use of public money.
  • In the Public Service, how ends are achieved should be as important as the achievements themselves.
  • Public servants should constantly renew their commitment to serve Canadians by continually improving the quality of service, by adapting to changing needs through innovation, and by improving the efficiency and effectiveness of government programs and services offered in both official languages.
  • Public servants should also strive to ensure that the value of transparency in government is upheld while respecting their duties of confidentiality under the law.

None of these values are wrong. What will be challenging is how emerging technologies will shift expectations among citizens around how these values should being interpreted and what that means for how government operates.

In his 2008 Bertha Bassam Lecture at the University of Toronto, David Weinberger points out that for the last several centuries we have associated credibility (read: professionalism) with objectivity and impartiality (note values listed above). However, the rise of the internet is beginning to erode the link that once bound credibility to objectivity and impartiality:

“Wikipedia is far more credible because it shows us how the sausage is made makes Wikipedia far more credible. Yet this is exactly the stuff that the Britannica won’t show us because they think it would make them look amateurish and take away from their credibility. But in fact transparency – which is what this is – is the new objectivity. We are not going to trust objectivity, we are not going to trust objectivity unless we can see the discussion that lead to it.”

Replace Britannica in this sentence with “the public service” or “government” and you see the problem. The values of the public service presume that objectivity and impartiality will lead to credibility.  Increasingly, however, this is no longer the case. We want the right to see how the sausage is made. More importantly, as an increasing number of organizations like Mozilla, Wikipedia and DirectLauncher make it clear that such transparency is both technically and practically feasible – even when managing highly complex and sensitive tasks – our expectations around what we expect of government is starting to shift. Who do you trust more? Wikipedia or the Government of Canada’s website? Who let’s you see the discussion? This answer to this question is getting less and less clear.

Indeed it is this increasing number of transparent organizations that throw the last bullet in the section on professional values into sharp relief:

Public servants should also strive to ensure that the value of transparency in government is upheld while respecting their duties of confidentiality under the law.

Even if the public’s expectations of what should be legal confidential does not shift, radical change will still be necessary. Already you see people beginning to demand better access to all sorts of government data sets (think the Sunlight Foundation). And we haven’t even mentioned the whole process of Freedom of Information Requests (FOI). Here is a system that is clearly overwhelmed. But think more carefully about the whole process of FOI. The fact that information is by default secret (or functionally secret since it is inaccessible to the public) and that it must be requested is itself a powerful indication of just how fundamentally opaque government is. In a world where information generation is growing exponentially, will the government really be able to manage and access all of it, and determine what is confidential and what isn’t? This seems like a system destined for real challenges. All of this to say that even if the last line of the value statement above does not change one iota, what it means – and citizens expectations around its implementations – is going to change radically.

This transition – the movement from a public service that is opaque by 21st century standards to one that is transparent is going to be gut-wrenching, challenging and painful, not because it isn’t technically possible, but because it is going to require reversing 200 years of culture, values and modes of operation that are embedded within the public service and deeply embedded within the political class. This isn’t to say that the transition will erode the power or influence of these groups, it won’t. But it will be different, and that in of itself is often scary enough to create resistance and a painful transition.

In conclusion, I suspect that the few of the values will, or need, to change – indeed most are necessary and good. However, while the values themselves won’t change, continuing to adhere to them will require dramatic changes to how the public service operates.

How an old media drudge's actions explain the death of newspapers

Taylor and I have received a lot of link love, comments, and emails since posting the piece Newspapers’ decline is a sign of democracy not a symptom of its death, but one commentator has been the standard bearer in the defense of the traditional newspaper: copy editor and blogger for the Baltimore Sun John McIntyre.

John and I are are involved in a healthy debate over the future of newspapers. In addition to commenting here at eaves.ca, he’s written two critical piece on his own blog. What is most interesting however is that while John disagrees with us in his comments and blog, his actions demonstrate our point. Democracy is better served by the rise of the internet – even if that comes at the cost of the physical newspaper. Why? Because our audiences are better served – and informed – by observing (and participating) in our debate.

Consider our exchange in the abstract. Here are two differing perspectives (mine and John’s), which would never share the pages of even his newspaper. Not only are they directly engaged with one another, but we link to one another – sending readers to one another! We may disagree, but the act of linking requires us (and asks our readers) to acknowledge and engage the other.

But consider too, the very practical. The centerpiece of John McIntyre’s attack on our post was his claim that the US constitution does protect the freedom of the press. In countering our assertion that “Newspapers are not a precondition for democracy—free speech is” John argues that:

“The Constitution does in fact protect newspapers. The First Amendment prohibits Congress from “abridging the freedom of speech, or of the press.” Or of the press. Newspapers. Over the past couple of centuries, the legal understanding of the press has been expanded to include, for example, broadcast. But it is clear in the text that the authors of the Bill of Rights foresaw a need to protect the press — what we could now understand as organized journalism — in specific language beyond the protection of the individual right.”

But this is actually a misreading of the constitution. The term “the press” wasn’t referring to newspapers or claiming that they are necessary for democracy (or that even journalism is for that matter). It was stating that Americans have the freedom of expression both in speech and in writing. In this manner, the constitution could have said “abridging the freedom of speech, or of blogs, or word documents, or PDFs.” Indeed, it was one of John’s own reader’s (slugwell) that supplied the legal analysis from Princeton University that confirmed his misinterpretation:

“Despite popular misunderstanding the right to freedom of the press guaranteed by the first amendment is not very different from the right to freedom of speech. It allows an individual to express themselves through publication and dissemination. It is part of the constitutional protection of freedom of expression. It does not afford members of the media any special rights or privileges not afforded to citizens in general.”

This back and forth – this focusing of the argument, the identification of errors and misunderstandings – is physically impossible in the traditional newspaper, and for reasons of culture and pride, remain rare in online editions. And yet, this is what makes blogs so compelling to their readers. Readers are able to learn more, dive deeper and participate in the evolving product (there is no final product on the internet). Alternatively, if they aren’t interested (as many readers of both John and my blog probably aren’t) they move on.

In his second post, John decries Wikipedia because “it advises its readers not to rely on the accuracy of its entries.” At least it advises its readers! But John himself benefited from (or was victim to) the very forces that make Wikipedia trustworthy – others came to point out the errors of his analysis. This is, paradoxically, what makes Wikipedia so trustworthy (and the Baltimore Sun less so – their retractions and errors are printed discretely, away from the prying eyes of readers). Even as he decries “new media” he enjoys and takes part in its benefits.

But let me finally return to this notion of respect. I don’t agree with John, but I respect him – which is why I link to and write about him. More importantly, I think we agree on more than we disagree. John states that he was responding to “a Canadian blogger’s post rejoicing in the death of the newspaper.” Let me concede that our tone sometimes makes it seem we are gleeful about the decline of newspapers, this is not the case. Let us be clear, Taylor and I aren’t celebrating the death of the newspapers. While we take issue with the industry’s argument (and hubris) that they are a precondition or necessary for democracy, anyone who reads our piece, Missing the Link will note this line:

“However, unlike the work of our techno-utopian contemporaries, our critique should not be seen as a jubilant celebration of a dying industry. Traditional media has served society well, and with the right attitude and adjustments, could continue to do so for the foreseeable future.”

As avid newsreaders and commentators, our problem is with how newspapers – and the news industry in general – has been profoundly unimaginative, blind, angry and reactionary towards new technology and possibilities. Our goal in bursting bubbles is to focus the debate on what’s possible and what’s next. Above all, we want news writers to once again talk about how they can better serve the public, not on how the public should serve them.

How GCPEDIA will save the public service

GCPediaGCPEDIA (also check out this link) is one of the most exciting projects going on in the public service. If you don’t know what GCPEDIA is – check out the links. It is a massive wiki where public servants can share knowledge, publish their current work, or collaborate on projects. I think it is one of two revolutionary changes going on that will transform how the public service works (more on this another time).

I know some supporters out there fear that GCPEDIA – if it becomes too successful – will be shut down by senior executives. These supporters fear the idea of public servants sharing information with one another will simply prove to be too threatening to some entrenched interests. I recognize the concern, but I think it is ultimately flawed for two reasons.

The less important reason is that it appears a growing number of senior public servants “get it.” They understand that this technology – and more importantly the social changes in how people work and organize themselves that come along with them - are here to stay. Moreover, killing this type of project would simply send the worst possible message about public service sector renewal – it would be an admission that any real efforts at modernizing the public service are nothing more than window dressing. Good news for GCPEDIA supporters – but also not really the key determinant.

The second, and pivotal reason, is that GCPEDIA is going to save the public service.

I’m not joking.

Experts and observers of the Public Service has been talking for the last decade about the demographic tsunami that is going to hit the public service. The tsunami has to do with age. In short, a lot of people are going to retire. In 2006 52% of public servants are 44-65. in 1981 it was 38%, in 1991 it was 32%. Among executives the average ages are higher still. EX-1’s (the most junior executive level) has an average age of 50, Ex 2’s are at 51.9, Ex 3’s at 52.7 and Ex 4’s at 54.1. (numbers from David Zussman – link is a powerpoint deck)

Remember these are average ages.

In short, there are a lot of people who, at some point in the next 10 years, are going to leave the public service. Indeed, in the nightmare scenario, they all leave within a short period of time – say 1-2 years, and suddenly an enormous amount of knowledge and institutional memory walks out the door with them. Such a loss would have staggering implications. Some will be good – new ways of thinking may become easier. But most will be negative, the amount of work and knowledge that will have to be redone to regain the lost institutional memory and knowledge cannot be underestimated.

GCPEDIA is the public service’s best, and perhaps only, effective way to capture the social capital of an entire generation in an indexed and searchable database that future generations can leverage and add to. 10’s of millions of man-hours, and possible far more, are at stake.

This is why GCPEDIA will survive. We can’t afford for it not to.

As an aside, this has one dramatic implication. People are already leaving so we need to populate GCPEDIA faster. Indeed, if I were a Deputy Minister I would immediately create a 5 person communications team whose sole purpose was two fold. First to spread the word about the existence of GCPEDIA as well as help and encourage people to contribute to it. Second, this team would actually interview key boomers who may not be comfortable with the technology and transcribe their work for them onto the wiki. Every department has a legend who is an ES-6 and who will retire an ES-6 but everybody knows that they know everything about everything that ever happened, why it happened and why it matters. It’s that person everybody wants to consult with in the cafeteria. Get that person, and find a way to get their knowledge into the wiki, before their pension vests.

Lessons from the Globe and Mail's Policy Wiki

I’ve been observing the Globe Policy Wiki with enormous interest. I’m broadly supportive of all of Mathew Ingram’s experiments and efforts to modernize the Globe. That said, my sense is that this project project faces a number of significant challenges. Some from the technology, others around how it is managed. Understanding and cataloging the ups and downs of such this effort is essential. At some point (I suspect in the not too distant future) wikis will make their way into the government’s policy development process – the more we understand the conditions under which they flourish, the more likely such experiments will be undertaken successfully.

Here are some lessons I’ve taken away:

1. The problem of purpose: accuracy vs. effectiveness

Wiki’s are clearly effective at spreading concrete, specific knowledge. Software manuals, best practice lists and Wikipedia works because – more often than not – they seek to share a concrete, objective truth. Indeed “the goal” of Wikipedia is to strive for verifiable accuracy. Consequently, a Wikipedia article on Mohandas Karamchand Gandhi can identify that he was born on October 2nd, 1869. We can argue whether or not this is true, but he was born on a specific day, and people will eventually align around the most accurate answer. Same with a software wiki – a software bug is caused by a specific, verifiable, set of circumstances.  Indeed, because the article is an assemblage of facts its contributors have an easier time pruning or adding to the article.

Indeed, it is where there is debate and subjective interpretation that things become more complicated in Wikipedia. Did George Bush authorize torture? I’ll bet Wikipedia has hosted a heady debate on the subject that, as yet, remains unresolved.

A policy wiki however, lives in this complicated space. This is because the goal of a policy wiki is not accuracy. Policies are are not an assemblage of facts whose accuracy can be debated. A policy is a proposal – an argument – informed by a combination of assumptions, evidence and values. How does one edit an argument? If we share different values, what do I edit? If I have contradictory evidence, what do I change? Can or should one edit a proposal they simply don’t agree with? In Wikipedia or in online software manual the response would be: “Does it make the piece more accurate?” If the answer is yes, the you should.

But with is the parallel guiding criteria for a policy wiki? “Does it make the policy more effective?” Such a question is significantly more open to interpretation. Who defines effective?

It may be that for a policy wiki will only work within communities that share a common goal, or that at least have a common metric for assessing effectiveness. More likely, Wikis in areas such as public policy may require an owner who ultimately acts as an arbiter deciding which edits stand and which edits will get deleted.

2. Combining voting with editing is problematic.

The goal of having people edit and improve a policy proposal runs counter to those of having them vote on a proposal. A wiki is, by definition, dynamic. Voting – or any preference system – implies that what is being voted on is static and unchanging; a final product that different people can assess.  How can a user vote in favour of something if, the next day, if it can be changed into something I may disagree with it? By allowing simultaneously for voting and editing I suspect the wiki discourages both. Voters are unsure if what they are voting for will stay the same, editors were likely wary of changing anything too radically because the voting option suggests proposals shouldn’t change too much – undermining the benefits of the wiki platform.

3. While problematic for editing, the Policy Wiki could be a great way to catalog briefs

One thing that is interesting about the wiki is that anyone can post their ideas. If the primary purpose were to create a catalogue of ideas the policy wiki could be a great success. Indeed, given that people are discouraged from radically altering policy notes this is effectively what the Policy Wiki is (is it still a wiki?). Presently the main obstacle to this success is the layout. The policy briefs currently appear in a linear order based on when they were submitted. This means a reader must scroll through them one by one. There is no categorization or filtering mechanism to help readers find policies they specifically care about. A search feature would enable readers to find briefs with key words. Also, enabling users to “tag” briefs would allow readers to filter the briefs in more useful ways. One could, for example, ask to see briefs tagged “environment,” or “defense” taking you to the content you want to see faster.

Such filtering approaches might distribute readers more accurately based on their interests. In a recent blog post Ingram notes that the Flat Tax briefing note received the most page views. But this should hardly come as a surprise (and probably should not be interpreted as latent interest in a flat tax). The flat tax brief was the first brief on the list. Consequently, casual observers showing up on the site to see what it was all about were probably just clicking on the first brief to get a taste.

Wikipedia: Community Management as its core competency

Last week Paul Biondich lent me The Starfish and the Spider and I just finished reading it (I know, I didn’t put it in the sidebar). Indeed, a number of people I respect have had great things to say about it – John Lily suggested the book ages ago and I remember reading his review and wanting to pick a copy up.

Tons of exciting ideas in the book. One that excited me most related to an idea (articulated by many people) that I’ve been trying to advance – namely that Community Management is core to open source. Specifically there was this exciting piece on how Jimmy Wales, the “catalyst” behind Wikipedia, spends his time:

Jimmy focuses a great deal of attention on maintaining the health of the Wikipedia community. “I go to speaking engagements all over the world at conferences, and everywhere I go I meet Wikipedia volunteers,” he told us. “Usually we go off to dinner and talk shop about Wikipedia. The Wikipedia gossip is the same all over the world-just the characters are different. The problems that affect community are always the same problems.” When he doesn’t meet the members in person, Jimmy spends “a ton of time writing e-mails internally, to the community, touching base with people, discussing issues that come up on the mailing list.” But “as far as working with Wikipedia, I don’t write articles. Very, very little do I ever edit. But I do engage with people on policy matters and try to settle disputes. (page 112 – paperback edition)

It could be that in starfish organizations the role of managers and leaders isn’t to tell people what to do, but help settle disputes, grease the wheels and make sure that groups are working well. Is this to say other expertise are not needed? Not at all. But it is great to see another take on how soft skills such as dispute management, facilitation, negotiation and mediation may be essential for sustainable success of starfish organization (like open source communities).

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…