Many businesses have made the leap to using computers to store their knowledge base: information about how their business works. Until recently, the available solutions were limited to using a hierarchy of documents on a network somewhere or an expensive document management system. Enter the Wiki: an easy-to-use way to link documents together into a browsable web site that grows as employees add information to it.
We've had a Wiki at Encodo for over a year now and wanted to share our experiences and recommendations.
All companies have information to manage. Some have more than others, but all have basic information about themselves like pension, insurance and bookkeeping information. On top of basic stuff like that, employees need enough information about the operating environment in order to get started -- for new employees -- or to remember how to do something -- for old hands.
Naturally, businesses differ widely on how this information is handled and made available. In the old days, there was a dusty shelf somewhere with hopelessly out-of-date binders full of papers that defined how the business operated. In more recent days, the mighty file server plays the role of dusty shelf, with at times haphazardly structured folders taking the place of heavy binders.
Enter the Wiki. A Wiki is a type of CMS that makes it very, very easy to create new pages of information and links between those types of information. The binders have made their way into a browsable web site, letting businesses form links between related bits of information that a set of binders or even a folder structure on a file server never allowed.
Just because information can be organized as it should be, doesn't mean that it will be. The degree of organization depends largely on the level of organization of the business itself and the amount of discipline exercised by its employees. Since any document can be linked to any other, there is none of the rigidity imposed by a classic system of folders. On the other hand, it can be difficult to impose structure -- and, depending on software, effectively impossible to impose restrictions on which person can see or edit which documents.
Assume a business has decided to go this route and wants to set up a Wiki of its own. When most people hear the word "Wiki", they automatically think of the Wikipedia, an online encyclopedia built by the world. A quick search reveals that the software that runs this gigantic site is available for free under the open-source MediaWiki project.
The software is relatively easy to install, requiring only a server of some kind, running both PHP and MySQL. Earlier versions of the MediaWiki required PHP4 and weren't packaged very well. Newer versions require PHP5 and are much easier to install. All configuration is done directly in PHP, using somewhat arcane, but now thoroughly documented, files found at the root of the web site.
Here at Encodo, we started off with MediaWiki 1.4x, graduated to 1.5x, then started to run into some limitations in functionality. We used the Wiki for almost all of our documentation and ran into a few problems:
If you're in the market for a Wiki, you won't suffer from lack of choice. A quick visit to the WikiMatrix helps narrow down the field considerably. Using the following criteria,
we came up with the following list of software to evaluate:
Confluence is a very nice looking solution offered by the fine folks at Atlassian, but costs quite a bit. WackoWiki and SnipSnap looked a bit new and lacked documentation, while MediaWiki was the one we already had. Between MoinMoin and XWiki, we found that XWiki offered the best mix of features, good documentation and user interface.
XWiki provides a UI to manage its "Spaces", which are like folders and can have their own security settings. Security settings are managed through the site rather than configuration files. XWiki is written in Java and runs in any Java web container, including, of course, Tomcat, which we already had installed. Configuration is, in general, accesible from a relatively nice user interface; customization and plugins can be written in Java or Groovy (a functional variant of Java). File uploads are attached directly to pages (as opposed to the global heap of media supported by the MediaWiki) and notifications are supported through an optional plugin.
All in all, it seems just the thing for our corporate intranet and we will be converting our current MediaWiki to an XWiki in the near future. To this end, we've written some scripts to ease importing the data from one to the other. The Wiki syntax isn't exactly the same, so the data has to be massaged a bit; we are also using regular expressions to match and sort a large number of the page to appropriately named spaces on import. The importer is a perl script that downloads HTML pages from the current Wiki and saves them to a local folder (or sub-folder, if it is determined that the page belongs in a named space). From there, a Groovy script imports the pages into the new XWiki, creating spaces as needed.
If used correctly, a Wiki quickly becomes a central knowledge base for a company. That means that it has to be able grow with the company as the company's needs change. The MediaWiki is far too open and simple a storage mechanism for a mature intranet in all but the smallest companies; the project is taking steps to address these issues, but it's not there yet. XWiki, on the other hand, provides the kind of basic functionality businesses expect when migrating from a file server-based knowledge management system. Having ended up with a good part of the company's knowledge stored the Wiki, we had no choice as to whether to migrate or not. In this case, XWiki's scriptabality eased the pain and cost of migration.
Sign up for our Newsletter