MediaWiki vs. Confluence? Not a question of features

When businesses want to make use of professional wiki software, they come quickly to the question of whether they should choose MediaWiki or Confluence. Confluence is a wiki specially developed for the needs of businesses. The concept for MediaWiki is, on the other hand, for the huge online encyclopaedia Wikipedia. Having more than 750,000 downloads per year, MediaWiki has a decisive lead as the standard wiki software, in business too.

Fans of Confluence used to complain that MediaWiki was not really suitable for businesses. And one can find serious comparative studies which completely ignore the possibility to extend and adapt MediaWiki. However, the extendibility and adaptability of MediaWiki is an essential feature of the software. The project page alone lists more than 1,800 extensions.
And, since the publication of BlueSpice, there is a completely free enterprise distribution for commercial users, which can be extended to suit individual needs via modules.

To show how MediaWiki really is a solution for business, I have collected together the most common objections to MediaWiki and I comment on them below.

“Confluence has a WYSIWYG editor”

A visual editor is a great help in terms of user-friendliness and acceptance. MediaWiki has been going a long time without developing its own editor – we will look at the technical reasons another time. However, MediaWiki will be getting its own native editor next year (see the article in MediaWiki Tech Blog).
And there are already visual editors available for MediaWiki, of course. Our colleagues at Twoonix have made a list of them: Wiki4Enterprise. There is even an editor, that from BlueSpice, which does not only write HTML code, but also understands MediaWiki code and redisplays it. Alongside this, BlueSpice offers many convenient dialogues, like those for inserting pictures, documents and categories.


A full choice: BlueSpice uses the leading editor TinyMCE. This is the view of the tool bar in expert mode.

“There is seamless integration of MS Office and Open Office in Confluence”

There is indeed office integration in Confluence. However, there are also many general technological problems here which cannot simply be brushed aside.

We really need to define exactly what we mean by “integration”. Connection to SharePoint documents? There is a module for this in the BlueSpice program. Searching Office documents? Also done in BlueSpice. Import and export of Office documents? Confluence is ahead by a nose here.

For a good reason: import functions are requested by customers in the start phase to transfer documents. So Atlassian, who make Confluence, mad the financial investment to program a tool for this. In practice, however, it is seldom used because after the content is placed in the wiki, there is often no need for it. Or the big migration planned is abandoned before it starts because many documents are hopelessly out of date or there is too much duplication or both.

Nevertheless, it is true: Office import and export facilities are still on the MediaWiki wish list. However, PDF format has been the standard for exporting for a long time. And for this there are very good solutions for professional use from MediaWiki (Collection) and also for BlueSpice (Bookmaker). This is the reason why a MediaWiki Office module is taking its time.

“Confluence offers better search functionality”

Apache Lucene is the most widely used search engine both on the web and in software development. It is integrated in the software packet BlueSpice in a simple, straightforward way allowing searching through documents and file systems and facet filtering.

BlueSpice Faceted Search

The Apache Lucene search in BlueSpice also searches through attached files. Results can be easily filtered for convenience using the faceted search.

“Confluence has a better connection to databases”

Few people realise that with BlueSpice, not just MySQL but also PostgreSQL and Oracle are possible.

“Confluence has a significantly more intuitive and well-developed user interface”

That depends on how you want to use it. The content-centred partitioning of the Vector skin has become predominant for public wikis. For business purposes, there is a professional skin for intranet solutions with BlueSpice (see the post by Radovan Kubani about MediaWiki skins here on the blog).

As MediaWiki is still developing, there is a Usability Initiative. Those who want to know what, for example, Wikipedia will look like soon, and how you can access its information on a smartphone or tablet, can take a look through the keyhole here and look at the “Athena” project.

“The area concept is very granular in Confluence, configuring rights is easier and more transparent”


Rights are conveniently managed through the backend in BlueSpice.

Yes, MediaWiki is built on a different philosophy of rights assignment. The differences between Confluence and MediaWiki have a great deal to do with the history and the aims of the respective pieces of software. This is a very interesting topic but one for another time.

Let us keep to the features: MediaWiki offers a wealth of ways to organise your rights: Namespaces, which can have different read and write permissions and even different designs. The possibility of distributing content into several wikis, which is not such a bad idea for free software. With BlueSpice, one can manage groups and namespaces easily in the backend.
Page-based authorisation is not provided in MediaWiki, but can be realised with, for example, the extension AccessControl. Provided a significantly more intuitive and better solution is not found, which, with a little advice, is generally the case.XXXwhat?

“Confluence’s Administration Area is significantly simpler to understand and handle”

With BlueSpice, this is also just a story (see the online demo: Admin).

“There is a plug-in for confluence for copying data with drag & drop”

Good point. That is something we have been wanting for a long time. We plan to present the relevant BlueSpice module to the public at CeBIT 2013.

“The wiki-structure in the form of parent-child relationships between wiki documents can also be easily adjusted with drag & drop”


Hierarchical chapter navigation: Combine articles via drag & drop into a book and navigate through all the pages of the book.

The possibility of arranging content hierarchically is very helpful. To those who maintain the content. Not only for the users who only read. They type their search terms into the search. Studies show that users do not really browse at all.

For this reason, and because for complex wikis it is the only way, MediaWiki has an extensive category system that can be arranged hierarchically to enable the maintenance of content. A hierarchical “chapter type” arrangement can be helpful for handbooks and similar formats and also for small collections of knowledge. Particularly at the start when well-known documents are transferred to the new medium. For this, portal pages can be easily created in the wiki. Let me also mention the possibility of creating subpages, which become important when in-depth additional information needs to be posted which does not fit into the main article for organisational or content-formatting reasons. However, generally many hierarchical arrangements dissolve during the transition to a wiki.

Using the module Bookmaker in BlueSpice, one can collect together individual articles into books very easily by drag & drop and overlay the hierarchical chapter navigation on the relevant pages. All of these possibilities exist.

The challenges are note to do with the fundamental conception of a wiki and the maintenance of the concept which does not happen just by having a hierarchical system. And MediaWiki has developed many features that are particularly useful here (for example maintenance pages). BlueSpice extensions such as the Workflow tool or Responsibilities help you to keep these tasks under control.

Better connection to other applications

This is a large topic and can only be dealt with briefly here.

  • Running staff blogs: BlueSpice offers an internal blog function. WordPress is the leading and best software in the world for larger blog farms. This can be, for example, attached to the wiki’s search with BlueSpice. WordPress also opens many further possibilities to extend in the direction of social media.
  • Ticket system: Confluence can likewise be connected to Jira, a program developed by Atlassian. Like Confluence, Jira is very good software. The open-source alternative is clearly OTRS, which is already used in almost all global businesses when customer requests need to be organised on a large scale. We also use OTRS – so it is also a solution for SMEs.
  • SharePoint: MediaWiki and BlueSpice MediaWikis can be connected to the module SharePoint Connect.

Brief conclusion

All the functionality that a professional wiki needs is available for MediaWiki. With the template system, maintenance pages, analysis, through to semantic extensions, MediaWiki actually offers customisation options missing in other solutions.

When planning, one needs to consider the content, the users and the organisations principles in order to be able to make a sound technological decision. This is true for every type of software and business wikis are no exception. So MediaWiki or Confluence could be the better choice.

It is also important to look to the future:

  • Confluence is moving, in my opinion, pointedly in the direction of a central social media-suite and sees itself more and more as an alternative to systems like Jive and SharePoint. MediaWiki is leading for the topic knowledge management and documentation, in particular for high-performance solutions. The lines of development are different.
  • It is also noteworthy that being free software, MediaWiki and BlueSpice prevent vendor lock-in. While under a licence model, the knowledge base can only be used as long as one is paying the charges, under free (standard) software, the data is always available. The user buys support, maintenance and customisation when required. This is also the case, incidentally, for cloud solutions. The user can take the data and software home and run it themselves. More on this soon.


See the comprehensive comparison of BlueSpice MediaWiki and Confluence 2017.


4 Comments to “MediaWiki vs. Confluence? Not a question of features”

  1. pierrelabrecque 24 August 2013 at 03:17 #

    Hello !
    I’ve read this article attentively and found this: “Page-based authorisation is not provided in MediaWiki, but can be realised with, for example, the extension AccessControl.”

    Well, I have a security concern (in an enterprise) with this. If we read:
    and also:

    I would like to know how is really secure (sensitive documents) Mediawiki with BlueSpice.

    Thanks for your attention,

    Pierre Labrecque

  2. mglaser 22 December 2013 at 23:11 #

    I tend to compare access control in MediaWiki (and in BlueSpice) with a closed and locked door. You can not accidentially see what’s in the room, and you need to have some lockpicking skills to enter. But if you know where to kick the door, you’ll be able to open it.

    Access control in MediaWiki is not built in by design. Depending on the extensions you use, it can be pretty unsafe, as content is often fetched directly from the database, bypassing exisiting security features.

    So, short answer: no. Long answer: If you have the demand for a really secure compartmentalization, (e.g. in highly sensitive research areas) use separate MediaWikis instead. But in my experience, the “locked door” is often good enough to meet the needs of an enterprise environment.

  3. martinbrg 9 February 2014 at 17:30 #

    We use MediaWiki+Confluence side by side.
    Reason for using Conf is mainly in the tight integration with JIRA and the friendly UI.

  4. […] already wrote a few words about MediaWiki and Confluence some years ago. At that time, we wrote about the main objections to […]

Leave a Reply