A crucial step in the implementation of a wiki within a company is the selection of the right wiki software. One must assess the major pros and cons of each system in order to make the best choice. In this article, we evaluate the open source software MediaWiki, and draw the conclusion that there is a better option.
Image: MediaWiki Logo
First thing’s first, an enterprise wiki is not the same thing as Wikipedia
Let’s begin by clearing up a common misconception, which stems from the following train of thought:
The biggest wiki in the world, Wikipedia, is based on MediaWiki. Tens of thousands of authors work together effortlessly, Wikipedia pages have a chic look, and millions of users are able to use this system in a stable environment. What could be more natural than using MediaWiki in your own company?
It cannot be emphasized enough: An enterprise wiki is not the same as Wikipedia, and Wikipedia is not an enterprise wiki. The requirements of each system are quite different. Vandalism, for example, doesn’t occur in a company wiki, and scalability to millions of hits doesn’t apply. A company needs to know its own core requirements and align its selection of wiki software with those requirements. The bare bones of a lexicon on the company intranet doesn’t meet the needs of most companies.
MediaWiki within the Intranet
The open source system MediaWiki was developed for Wikipedia, the public lexicon. For this kind of online encyclopedia, MediaWiki offers the best strategic fit.
Now, one could also argue that a good, well-engineered piece of software could also be used for purposes for which it wasn’t specifically designed. This would mean setting up a “Wikipedia” within the company and simply use it for other tasks and purposes later on. And this is what actually happens on a regular basis: at the beginning, establishing cooperation in the wiki requires only the basic functions.
Within Wikipedia, authors with different viewpoints come together to construct an article, although these authors are not always in complete agreement on the text. This is the same thing that happens within a company, both with and without cooperative discussion. With the basic functionalities of MediaWiki, this approach would be sufficient. Further functions could be implemented later as needed.
This is a very common way that companies using MediaWiki find themselves developing their company wiki. MediaWiki is installed, not after thorough research - which we argue would be the best solution - but rather because it offers a basic level of software (which after all is sufficient for Wikipedia) and the company’s primary goal is to establish a wiki. The company’s wiki is thus established and begins to grow in participation, possibly even thrive.
But here, in our view, the company has made a misstep. We believe that after thorough examination of the available enterprise wiki systems, the company would have come to the conclusion the MediaWiki is not suitable as an enterprise wiki. MediaWiki is eventually found to be missing numerous functions that become indispensable and fundamental for the company’s wiki.
Lack of Native Rights Management
As previously mentioned, MediaWiki was designed as a public wiki. On Wikipedia, there are no closed areas, and all information is accessible by all users. This is the purpose of a web lexicon, but not necessarily of a corporate wiki.
Let’s look at a practical example: Within a company exists a product development department, which most likely stores and develops the information within the wiki. Not all employees have (or should have) access, but rather only those who are directly involved in the development of the product. This means that rights control is required, which helps protect certain areas which are then made available to certain employees.
This is also possible in MediaWiki, not directly, but rather via an underdeveloped plugin. Rights management is one of the weakest points in MediaWiki. How will customers in the extranet be connected to and work within a wiki project? How will virtual teams collaborate, for example freelancers working on editorial tasks?
Wikipedia founder Jimmy Wales himself admits openly in an interview that this is a problem, and briefly describes how this followed development within MediaWiki:
“Its disadvantages are that it doesn’t integrate with corporate logins. There is no Outlook integration. I don’t really care about that stuff. […] Wikipedia is about building out the reference library.”
Other wiki systems such as Confluence, Foswiki, etc offer much better rights management, right down to the page level. The commercial system Confluence even allows for a plugin which can curtail read permissions for administrators—for example, when IT employees in the group should not have access to certain business information.
No Useful Rich Text Editor
The second drawback is the lack of a Rich Text Editor (WYSIWYG editor.) In Foswiki and Confluence, users can edit text as one would do in MS Word, with a graphical interface that staff members will find easy to use. MediaWiki does not contain any native Rich Text Editor, and the solutions presented by plugins are barely usable.
Certainly experienced wiki users can access the wiki code directly, and Wikipedia authors have no problem with this approach. But with the introduction of a corporate wiki, one must consider that when it comes to enabling employee usage, any relief in the effort required to use the system is worth its weight in gold. Here is where the lack of a Rich Text Editor can have a very negative effect: the less technologically-savvy employees must first familiarize themselves with the wiki code before they can even begin to do actual work on the wiki, which makes an already difficult activation even more so.
As for the argument that all employees probably know Wikipedia and this is therefore no problem: It is a huge misconception that all or even a significant percentage of Wikipedia users actually contribute to Wikipedia content. In Web 2.0 (outside of the company wiki) the following rule has been shown to apply: 90-9-1, nine out of ten users consume content, nine percent contribute content occasionally, and only once percent do so regularly and often. The vast majority of your employees have never seen the actual wiki code of Wikipedia/MediaWiki.
A good Rich Text Editor significantly increases usability, thus supporting employee usage and leading to more effective and efficient use of the wiki. The enterprise wiki system Confluence as well as Foswiki offer very sophisticated WYSIWYG editors. For MediaWiki there are only rudimentary solutions in the form of plugins which, as previously stated, are hardly workable.
And a change doesn’t seem to be coming any time soon. Socialtext was once thought to be developing a solution, but the link to this project in a blog article on the topic is now dead. The MediaWiki website has this to say when it comes to a Rich Text Editor:
“In 2009 there is no available “ready-to-go” package for incorporating full WYSIWYG into the MediaWiki software.”
This has still not changed in 2010.
No Localization Options
Structured wikis such as Confluence, Foswiki and others offer hierarchies with breadcrumbs. The functionality to define parent-child relationships between wiki documents is completely absent in MediaWiki. The existing corresponding categorization function is for some an adequate substitute, but there is still no way to map content hierarchically.
No Charting Functionality
MediaWiki has no native charting functionality, which would prove extremely important for evaluations and reports within the wiki. So far there are only third-party solutions such as Google. Some companies might be turned off at the idea that Google could pull its revenue and profitability charts from the wiki. In supplier-customer relationships this could even constitute a breach of contract.
The charting functionality of Foswiki and Confluence is simply better in meeting the needs of companies.
Tables, Import, Blogging…
When it comes to list entries, wiki syntax in MediaWiki is poorly implemented. The orientation of figures and tables is problematic, and MediaWiki tables are not generally well supported. MediaWiki has no blogging features and no nested searches or “smart lists.” An option to integrate PDF documents is lacking, and import functions for MS Office documents are immature—features that are important and relevant for corporate wikis and which Foswiki and Confluence professional systems offer.
Companies often have no budget set aside for editors
The focus of MediaWiki is on the applications of Wikipedia. Usability issues along with functionalities which are missing or not fully developed may have no significant impact when large amounts of manual effort are expended by volunteer editors with wiki code expertise working to maintain quality, categorize documents, populate tables, develop workarounds, etc.
This is not feasible within a company. There is often no budget allocated for wiki editors. With this in mind, an enterprise wiki must be able to operate in full immediately and have sophisticated features available.
Conclusion
All wiki systems have their own advantages and disadvantages. MediaWiki has the advantage of being an open source system and thus free. It also allows cooperation on a large scale. Yet this software is not suitable for use as an enterprise wiki.
Its main drawback is the lack of rights management, which plays a crucial role in collaboration within an enterprise wiki. Furthermore, MediaWiki lacks some crucial features, which are missing entirely or replaced with sparse plugins, which are featured in dedicated enterprise wiki systems such as Confluence and Foswiki.
In summation: A wiki is certainly not automatically destined to fail if MediaWiki is selected. It is absolutely possible to operate a fairly well functioning enterprise wiki based on this system. But one must consider that the introduction process will likely face significantly greater challenges and limitations, especially considering that the existing shortcomings are unlikely to be resolved in the near future.
For a public wiki, MediaWiki is the right choice. If however the goal is to promote collaboration and knowledge exchange across projects, the selection decision after weighing all facts is decidedly against MediaWiki. The other options offer better functionality.
What experiences have you had with MediaWiki use within the company? Which problems arose? Did you find solutions to these challenges? Or perhaps are these problems not relevant to your situation? I look forward to your comments and a lively discussion! 
Additional Information
Our special page on MediaWiki and information about wiki introduction
Follow this link to a mailing list on MediaWiki as an enterprise wiki. (Important information for those considering MediaWiki as a company wiki.)
Jimmy Wales and Enterprise Wikis
Enterprise Wikis: Strengths of Confluence compared to Foswiki and MediaWiki
Success Factors for Wikis: Technology is important, but not crucially so
Enterprise Wikis: Criteria and important topics in the evaluation of wiki software
Company Wiki's aren't Wikipedia
Read this post in German.
