For those wishful thinkers who dream of corporate “knowledge management,” few tools are more seductive than the enterprise wiki.

The dream goes like this: Just set up a wiki (really inexpensive because some tools are open source and free), and it will miraculously fill up with all the knowledge, explicit and tacit, that represents the institutional memory, the know-how, the core assets of any organization.

In the idyllic wiki Web 2.0 future, all your mission-critical information will be easily accessible with a quick keyword search. What’s wrong with this picture? We have plenty of evidence in its favor. Hasn’t Wikipedia shown us all the way?

When Larry Sanger convinced Jimmy Wales in January 2001 to try Ward Cunningham’s idea of the wiki as the quickest way to collect knowledge, it transformed Wales’ idea of a free online encyclopedia. In all of 2000, Wales’ original Nupedia had produced only 12 articles. Yet, as if by magic, within a month of inception, the new Wikipedia had 1,000 articles; 8 months later it passed 10,000. Today it has 5 million registered editors, with 8 million articles in more than 250 languages, and about 2,000 new articles are added every day.

Yet, as the cautionary warnings say, “Your mileage may vary.” If your corporate wiki is not as full as you would like, don’t blame the tool. Content and knowledge management have never been about tools and technology; they’re about people and processes. However, as CM tools go, the current crop of wikis is woefully weak. Wikipedia’s success has been in spite of the wiki tool used, not because of it. The magic was in the social network of individuals who wanted to make a free internet encyclopedia.

Wikis are weak because most do not employ standards-based technology and are clueless about today’s content management best practices like content reuse, modularity, structured writing, and information typing. Lack of standards means that every wiki uses a different markup language to create its special content like hyperlinks, bolded or other text styles, tables, etc. Just consider the number of wiki dialects and their wacky wiki names: DokuWiki, Kwiki, MediaWiki, MoinMoin, Oddmuse, PbWiki, PhpWiki, PmWiki, SlipSlap, TikiWiki, UseMod, WakkaWiki, and WikkaWiki.

This lack of standards-based development results in a lack of interoperability, poor metadata management, and little reusability within the wiki itself. 

Consider the basic Web 1.0. With an ordinary HTML webpage, the amazing “View Source” link allows you to copy and paste the webpage HTML content into another webpage. This is a primitive, but very easy, reuse of content. If you were to paste the HTML into another page, the new page would look the same.

With a wiki, View Source shows you not the wiki markup, but the HTML that was generated by the wiki from your wiki markup. If you copy content from a wiki, you cannot paste it into your wiki or another wiki to use it as a starter page. As a result, wikis have poor reuse of content. (SuLaine Yeo and Eric Armstrong point out that within some wikis there are good reuse methods, templates, copy and paste, and transclusions. But it is not the same as DITA reuse? And does the DITA.WML.org wiki do this? The DITA Wiki is based on MediaWiki, same as Wikipedia.)

The dominant method of wiki navigation is the search engine—both built-in and web-based. Wikipedia is now one of the 10 busiest sites on the web, and Google searches frequently have a Wikipedia entry on their first page of search results. The typical wiki entry point is a deep link, so it must be easy to find the way back to the wiki homepage. Wikis can use the latest categorization and tagging schemes and can generate RSS feeds to notify those following their growth of content blow-by-blow.

We hope to see still more standardization of wikis as they are increasingly built on structured XML in the future. The ideal wiki would just use XHTML and a WYSIWYG editor interface for unsophisticated content contributors. Underneath, it would have hidden structure to facilitate information retrieval. Brute-force full-text search is good, but it’s not good enough.

In the structured writing community, the new DITA XML standard has encouraged hope for a DITA-based wiki tool. The only such effort, DITA Storm from Log Perspective, was recently acquired by Inmedius, the XML CMS vendor strong in the S1000D structured documentation space.

Different markup methods and storage formats make for difficult content migration when (not if) you want to move your wiki full of mission-critical corporate information to an improved future tool. So while making the wiki dream come true isn’t actually contingent upon the tools, we must dare to dream of wiki tools that play by the standards so that the content is as flexible as the environment purports to be.