What Makes Wikipedia Tick? 1
Whatever your views on Wikipedia, it's clear that the volunteer online encyclopedia has left it's mark on society. But the most important things about Wikipedia have less to do with its contents and more to do with the people contributing and using the service. To understand how and why people collaborate on the Web, you have to understand Wikipedia.
An interview with three leading Wikipedia figures sheds some light on Wikipedia as a collaborative activity.
There is a myth about online collaboration that Open Source practitioners are very familiar with. It goes something like this: "I'll start building something and release it to the community. I'll get feedback from a lot of users, some of whom will fix bugs, write documentation, and build extensions. All of that feedback will create a better product."
Now, this does happen, of course. The reason I consider it a myth is that it happens so rarely that you might as well not count on it. Virtually all Open Source software is designed, written, documented, debugged, and promoted by a single developer with the help of a tiny fraction (say 2-10%) of the committed user base. Pick any good example of Open Source software that works and behind it you'll find a committed user base large enough to make 2-10% a number greater or equal to one. It's not clear this is necessarily a bad thing.
The interview with the Wikipedia leaders confirmed this view. When asked about the idea that lots of contributors makes a good article, Elisabeth Bauer, of the English Wikipedia, had this to say:
The best articles are typically written by a single or a few authors with expertise in the topic. In this respect, Wikipedia is not different from classical encyclopedias.
Her view was shared by Kizo Naoko, of the Japanese Wikipedia who added that short articles tend to remain short and of poor quality.
There doesn't seem to be anything complicated here. Wikipedia places a very low barrier to contribution. It has created a system where active contributors with specialized knowledge feel a sense of ownership over their contributions. Checks and balances insure that these contributors can monitor changes to their work, and correct errors. Finally, the subject matter is so broadly appealing (All of Human Knowledge) that 2-10% of the user base is a massive number.
It may not be complicated, but it's far from easy.
Collective Intelligence and the Dumbness of Crowds
It's the sharp edges, gaps, and differences in individual knowledge that make the wisdom of crowds work, yet the trendy (and misinterpreted) vision of Web 2.0 is just the opposite--get us all collborating [sic] and communicating and conversing all together as one big happy collborating [sic], communicating, conversing thing until our individual differences become superficial.
-Kathy Sierra, The "Dumbness of Crowds"
"Web 2.0" has gotten a lot of people thinking about exciting new forms of collaboration made possible through the Internet. Services like Digg, YouTube, Flickr, and Wikipedia, and especially the way they harness the selfish impulses of individuals for the common good, are seen by many as just the start of even better things to come.
Given the astonishing advances in hardware made possible by Moore's law, and the relentless progress of Open Source software, starting one of these services on your own can be done for practically nothing. Of course, starting a Web 2.0 service and actually seeing it become a raging success are two very different things. What's the deciding factor?
It was while thinking about this question that I ran across a thought-provoking article on Kathy Sierra's Creating Passionate Users. Although mainly focused on software, Kathy's blog is essential reading for anyone trying to create remarkable products. The article that caught my eye was titled "The 'Dumbness of Crowds'". In it, Kathy makes some interesting distinctions between "Collective Intelligence" and "Dumbness of Crowds."
The distinction arises from the number of people involved, the nature of what they're building together, and the process by which differing views are reconciled. For example:
Collective Intelligence a bunch of people writing Amazon book reviews
Dumbness of Crowds a bunch of people using a Wiki to write a book
Collective Intelligence - Flickr's photo collection and tags
Dumbness of Crowds - a bunch of people trying to make a photo together
I could add my own observations:
Collective Intelligence an online RSS aggregator that combines blog feeds from multiple sources within the community
Dumbness of Crowds a publicly-writable Wiki that serves as your community's public face
Collective Intelligence ten users of an Open Source software library stress-testing it in their own work, fixing bugs, and requesting features
Dumbness of Crowds ten programmers trying to design an API
Collective Intelligence ten developers who each start their own project to build their own distinct application based on a piece of Open Source software
Dumbness of Crowds ten developers who set out to design a single application that does the work of ten
The distinction really revolves around the degree to which individual contributions are blindly averaged verses being allowed to retain their individuality. Committees rarely create great works. Even worse - sometimes consensus is fatal.

