There appear to be two broad applications for wikis being used by organizations. The first is as a collaborative tool, most often used to manage projects as a replacement for e-mail. In this sense, it represents a middle ground between e-mail and more formal project management tools. The second application is as a knowledge management platform. The ease-of-use inspires organizations to capture tacit employee knowledge and other details that tend to never be documented.

First and foremost, a wiki engine is a content management system and many organizations use wiki engines for anything you'd use a content management system for - more than likely in their intranet. Wikis are an excellent entry-level content management system because they are easy to edit, require very little training and no specialized software (other than the browser and web server).

E-mail Replacement

Wiki engines can also be used as a project management tool. In many cases, users report that they are using wikis as a replacement for e-mail. There are a few different issues - the first is mailbox clutter. So much information (and clutter) crowds the typical professional's mailbox these days that messages are easily lost (overlooked or inadvertently routed to junk mail folders by overly eager spam filters).

The second issue with e-mail relates to document management and versioning. Many organizations use Microsoft Word for any number of different uses. Word's internal version tracking is used, which can be very powerful and quite handy at times. Unfortunately, e-mail works by spawning innumerable copies of Word documents (constrained only by how many recipients there are). Unless carefully managed, each document can represent a fork of the original document, with changes made to different copies of the same document, leading to a nightmare merge scenario, not to mention the simple difficulty of knowing with relative assurance that you are viewing the most recent version of the document (you can view the most recent version of

of the document, but you don't know if that your copy is the latest copy).

Wikis nicely present the very latest version of every page (plus a history of edits and who made the edits). The wiki becomes the authoritative source of the document to be managed by the project. Mailboxes are decluttered (and reduced in size) and documents are easier to find.

Wikis grow weeds. Wikis get tangled.

User Groups

Software companies have often established user groups - communities of users of a given software product as a way to minimize their own support costs by shifting some of the weight to the community. Wikis are a natural extension to the user group, and users will participate if given the right environment. This falls into the extranet approach (the content may or may not be available to the general public, but these wikis tend to have more secure control over who gets to participate.

It is unlikely that the average company would benefit from a theoretically pure public wiki that anyone could edit because the community-at-large (which would be everyone on the Internet) does not have aligned goals with respect to one company. In other words, there are competitors, disgruntled former employees, etc, that are beyond the reach of the normal social pressures to behave reasonably well.

Note: I'm not quite satisfied with this framework. An interesting exercise would be to compare Wikipedia with the MediaWiki.org site. The MediaWiki.org site is the site that documents MediaWiki, the PHP application upon which Wikipedia is built. Since I am writing a book about MediaWiki, I think I can firmly attest to the fact that MediaWiki is incoherent and horribly disorganized. Why is Wikipedia successful and MediaWiki a failure?