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.

Web 2.0 may be all about participation, but the numbers reported by The McKinsey Quarterly suggest a self-selecting oligarchy rather than a democracy. Success may well depend more on engaging the top 2-10% of users rather than appealing to all of them. Food for though when forming your next community, be it electronic or otherwise.

image credit: The McKinsey Quarterly

A recent article discussed the renaissance of the command line. Particularly on the Web, command line interfaces have become so advanced, that most of us don't even realize we're using them. Consider the Google search box, which is nothing more than one of the most powerful command line interfaces ever developed.

A service called YubNub takes this idea one step further. YubNub is a meta command line interface for the Web. The following YubNub command will do a Flickr search for benzene.

If this were all YubNub did, it would be merely interesting. What makes YubNub remarkable is that you can create your own commands that other people can use. I recently added the "ginchi" command to query Google for an InChI. Now you can try it out:

By itself this isn't particularly useful because you can just go to Google and query the InChI directly. However, it's not too hard to imagine several commands like ginchi that could be added. Some would use Google, others would use other services. How about something that searches Mitch Garcia's chemistry journal Yahoo pipe? It would be very convenient to have all of those commands accessible from the same Web page.

Command line interfaces can be phenomenally useful for both beginning and advanced users. The hardest part to get right is not what the user sees as they type, but what happens after they hit the enter key.

Line notations are the perfect match for command line interfaces. The widespread use of SMILES and the precision of InChI offer many possibilities for innovative chemistry Web services.

Chemistry on the World Wide Web is picking up speed like a runaway train. A remarkable number of groups are devoting considerable time, effort, and money to a wide variety of chemical web applications.

-Stu Borman, Chemical & Engineering News, September 16, 1996

Whatever happened to chemistry and the Web? Stu Borman's article is a wonderful read, if for no other reason than to illustrate what makes technology predictions so tricky. Borman cites these developments, among others, as evidence of the rise of chemistry on the Web circa 1996:

• An AltaVista search for the word "chemistry" returned 400,000 documents. (Remember AltaVista? Google now lists over 115 million documents containing the word "chemistry").

• Popular Web browsers such as Navigator 3.0 and Explorer 3.0 support Greek characters, an important characteristic of chemical information. (Support for chemistry in Web browsers has barely improved in the meantime.)

• A Java browser for Chemical Markup Language (CML) was soon to be released. (CML is still in use and supported by many software packages, although it has not been widely adopted. For example, the builders of PubChem opted for a custom XML format over CML.)

• Virtual Reality Markup Language (VRML) could be used display molecules in three-dimensions. (This article gives a brief overview of the rise and fall of VRML.)

• Chemscape Chime, a Navigator plugin that interprets chemical information, could be freely downloaded. (MDL has apparently since discontinued free distribution of Chime. The free as in beer plugin is rarely seen in use on the public Web.)

• Chemically oriented Java applets such as "WebSketch" are proliferating. (Java has had a difficult time making it as a browser technology. Security has had little to do with it, though.)

Stu Borman's article serves as a clear reminder that chemistry on the Web is almost as awkward today as it was at the dawn of the Internet age. The problem isn't lack of content; it's the lack of robust, widely-adopted, open standards that take the peculiarities of chemical information into account, and the free software to support them. Coming to terms with past failures in this area is one way to increase the chances of future success.

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.