How does Wiki get information

Read this post in English.

An important step in the introduction of a wiki in a company is the selection of the right wiki software: You have to know the most important advantages and disadvantages of the individual systems in order to be able to make a rational decision. In this article, the open source software MediaWiki is to be assessed against this background. Our conclusion: As a corporate wiki, MediaWiki is weak.

Fig .: The MediaWiki logo

First of all: A company wiki is not Wikipedia

A common misunderstanding should be cleared up beforehand. It is based on the following reasoning:

The largest wiki in the world is operated on the basis of MediaWiki: Wikipedia. Tens of thousands of authors work effortlessly into the content, Wikipedia pages sometimes look pretty chic, and millions of users use the stable system. What could be more obvious than using MediaWiki in your own company?

It has to be emphasized once again: A company wiki is not Wikipedia and Wikipedia is not a company wiki. The requirements are completely different. Vandalism? Does not appear in company wikis. Scalability for millions of hits? Doesn't matter in the company. A company must know its central requirements and align itself with them when selecting the wiki software. The mere illustration of a lexicon in the intranet does not meet the needs of most companies:

How MediaWiki gets on the intranet

The open source system MediaWiki was developed for Wikipedia, i.e. for a public lexicon. For an online encyclopedia, MediaWiki also offers the best strategic fit.

One could argue that good, well-engineered software can also be used for purposes that do not correspond to its actual strategic direction. So that would mean in the company a Wikipedia and to use it later for other tasks and requirements. This is exactly what companies actually do in practice: They want to guarantee collaboration in their own company, as in Wikipedia, and initially only need the basic functionalities.

At Wikipedia, authors with different views can find a way to establish an article and work together on texts, even though they don't always agree. This is exactly what should now be mapped in the company both with and without discussion. The basic functionalities of MediaWiki, so the conviction, would be sufficient for this. In principle, you can find out later whether you want to use other functions.

This is usually the wiki history that most companies using MediaWiki look back on. MediaWiki is not installed after thorough research - which would actually be the best solution - but more or less because it is the software with which Wikipedia is operated and because the management's requirement is to establish a Wikipedia in the company . So such a Wikipedia is set up in the form of MediaWiki and may also start to grow and prosper.

In our opinion, companies are making a mistake with this: We are of the opinion that after a detailed examination of the available company wiki systems the conclusion can only be that MediaWiki is not suitable as a company wiki. MediaWiki simply lacks numerous functionalities that are essential and fundamental for a company wiki.

Inadequate native rights management

As mentioned, MediaWiki is designed as a public wiki per se. There are no closed areas at Wikipedia, all information is accessible to all users. That is the whole point and purpose of a web lexicon. But certainly not that of a company wiki.

Let's take a practical example: The company has a product development department that most likely stores and discusses information in the wiki that not all employees should have access to, but only those who are directly involved in product development. This means that a rights control is required, with the help of which certain areas can be protected and only made accessible to certain employees.

In principle, MediaWiki does not offer this option at all, only via a slightly mature plug-in. The rights management is one of the biggest shortcomings of MediaWiki. How should customers be involved in project work via the Wiki-based extranet? How should virtual teams work together in which, for example, freelancers take on editorial tasks?

Wikipedia founder Jimmy Wales openly admits this deficiency in an interview and briefly describes what the further development of MediaWiki is focusing on:

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 of the reference library.

Other wikis such as Foswiki and Confluence offer significantly better rights management down to the page level. The commercial Confluence even allows the read rights of administrators to be curtailed via a plugin, for example if IT employees in the group should not have access to business information.

Not a viable rich text editor

The second drawback is the lack of a rich text editor (WYSIWYG editor). In Foswiki and Confluence, almost like in MS Word, you can edit content in wiki documents via a visual interface, which is very convenient for many employees. MediaWiki does not have a native rich text editor, and the solutions via plugins are hardly usable.

Certainly: Experienced wiki users get along very well with the wiki code, even the Wikipedia authors have no problems with this way of working. But with the introduction of a company wiki and with the efforts to activate the employees, every relief of the work in the system is worth its weight in gold. A lack of a rich text editor can have a very negative effect here: If employees who are not very technology-savvy have to get to know the wiki code before they can actually start working in the wiki, it will certainly not be easier to activate it, which is already difficult.

To dispel the objection that all employees would know Wikipedia and therefore there shouldn't be any problems getting started: It is a huge fallacy to assume that all or even a significant percentage of Wikipedia users also contribute Wikipedia content. In Web 2.0 (unlike in a corporate wiki), the so-called 90-9-1 rule applies: nine out of ten users only consume content, nine percent occasionally contribute content, only one percent does this regularly and frequently. The vast majority of your employees have certainly never seen the Wikipedia / MediaWiki wiki code.

A good rich text editor increases usability significantly, supports employee activation and leads to more effective and efficient use of the wiki. The company wiki systems Confluence and Foswiki offer very sophisticated WYSIWYG editors. For MediaWiki there is a rudimentary solution only in the form of plugins, which (as I said) is hardly acceptable.

Apparently there is no change in sight either. Socialtext once started to develop a solution, but the link to the project in the blog entry on the topic is now dead. On the MediaWiki website, it says in terms of rich text editor:

In 2009, there is no available 'ready-to-go' package for incorporating full WYSIWYG into the MediaWiki software.

This has not changed in 2010 either.

No localization options

Structured wikis like Foswiki or Confluence offer hierarchies with breadcrumb paths. The function to define parent-child relationships between Wiki documents is completely absent in MediaWiki. The existing categorization function is not an adequate substitute, there is no way to display content hierarchically.

No charting functionality

MediaWiki does not have any native charting functions, which are extremely important for evaluations and reports in the wiki. So far there have only been solutions for this through third-party providers such as Google. And many companies will not be very comfortable with the idea that Google will get its own sales and profitability charts from the controlling area of ​​the wiki. In supplier-customer relationships, this circumstance might even represent a breach of contract.

The charting functionalities of Foswiki and Confluence integrated into the Wiki are simply better suited here and meet the needs of companies.

Tables, import, blogging ...

Wiki syntax is poorly implemented in MediaWiki for list entries. Aligning images and tables is problematic, although MediaWiki does not generally support tables very well. MediaWiki has no blogging functions, nested searches and “smart lists”. There is no way to properly integrate PDF documents, the import functions for MS Office documents are immature - all interesting and important features that are relevant for company wikis and for which Foswiki and Confluence, in contrast to MediaWiki, mature, professional solutions Offer.

Companies don't have a budget for editors

MediaWiki focuses on Wikipedia realities. Not fully developed or missing functionalities and usability problems have no significant effects if a very high manual effort is made and there are a lot of volunteer editors who deal with quality assurance tasks, bring wiki code expertise, categorize documents, enter tables, workarounds elaborate, etc.

However, this is not possible in the company: there is often no budget at all for wiki editors. That is why a company wiki must work to the full immediately and provide fully developed features immediately.


All wiki systems have advantages and disadvantages. MediaWiki has the advantage of being an open source system and therefore free of charge. It also serves the purpose of collaboration. And yet the software is not suitable for running a company wiki.

The main drawback is the aforementioned rights management, which plays a decisive role in collaboration in a company wiki. Furthermore, MediaWiki lacks some functions that are crucial for a corporate wiki, which replace possible plugins only sparsely or not at all and which have real Company wiki systems like Confluence and Foswiki.

Basically: A wiki introduction is certainly not automatically doomed to failure if you select MediaWiki. It is certainly also possible to operate a reasonably functioning company wiki based on MediaWiki. But you have to reckon with significantly greater challenges during the introduction and be aware that you are severely limiting yourself with the Pro-MediaWiki decision, especially since the existing restrictions are not expected to be lifted in the medium term.

For a public wiki, MediaWiki is the right choice. However, if cooperation and exchange in projects are to be promoted, the decision must be against MediaWiki after weighing all the facts. Here other solutions offer the better functionalities.

What is your experience with MediaWiki in a company? Do you know the problems mentioned? Have you found solutions to these challenges? Or are these problems irrelevant in your company? I look forward to your comments and a lively discussion! 🙂

additional Information

Our special page on MediaWiki and with information on wiki introduction

There is a mailing list on MediaWiki as an enterprise wiki that should be read when considering MediaWiki as a corporate wiki system.

The page on with information on how to use MediaWiki as a corporate wiki (which, however, is very sketchy and unconvincing)

Jimmy Wales and Enterprise Wikis

Company wikis: strengths of Confluence compared to Foswiki and MediaWiki

Success factors for wikis: Technology is important, but is overrated

Decision criteria and important questions when evaluating wiki software

Social Software: The Wikipedia Fallacy

Five differences between Wikipedia and corporate wikis


Learn more about the Creative Commons license

ConfluenceConsultingCreative CommonsCompany wikisFoswikiMediaWikiOpen SourceWikiWikipedia