In this two-part article, we give a detailed comparison of the wiki top dog MediaWiki and Confluence.
We already wrote a few words about MediaWiki and Confluence some years ago. At that time, we wrote about the main objections to MediaWiki.
That article is still worth reading and remains largely valid. Ultimately the key argument then was that the choice of tool did not depend only on features, but also on the concept behind the software. This is a timeless truth.
However, MediaWiki does not need to fear a direct feature comparison. Importantly, the enterprise distribution BlueSpice has already decided the feature question in my view. This can be seen on our newest internal feature-comparison table, published here and offered for free download:
I can hardly believe it: the current version of BlueSpice, BlueSpice 2, will be four years old this year. It feels like just a few months ago that we announced Version 2. Anyway, it is now time to start thinking about a new version and to continue writing the road map.
At Hallo Welt! we have spent the last months collecting ideas, and checking and weighting requirements.
At our yearly strategy meeting, Markus Glaser presented his technical plan. So now it is official that we will publish a new BlueSpice Version 3 in the first quarter of 2018. The road map for our new MediaWiki distribution contains essential innovations and improvements we have wanted for a long time. BlueSpice 3 will achieve a new level of stability and flexibility. Continue Reading
Yesterday we published a new feature list. It was necessary to record the latest extensions. But we used the opportunity to mention a lot of important features that BlueSpice with MediaWiki as basis technology automatically includes: for example security features, many reporting functions and mobile device support.
These features have been neglected in the past, despite the fact that they show that MediaWiki is the leading system for collaborative knowledge systems for good reasons. Hallo Welt! assumed that these features are well known. Now we wanted to show that BlueSpice already includes in its standard what others advertise as an extra.
There are now 152 features grouped in 17 topics. We could have extended the list considerably, but we focused on the most important features in order to make decision-makers’ work easier.
This year Hallo Welt! will continue to expand the extension pool of distributions and take important steps towards the integration of extensions. Of this steps our pro customers will benefit in the first place.
Moreover BlueSpice offers unique opportunities in order to develop its own products and customized solutions. These opportunities we will explain in more detail elsewhere, when it comes, for example, to the subject of technology partnerships.
Maybe another note: The feature list is not the same as the official extension list (software catalogue). The extension list shows which extensions are included in the distributions and are supported by us. The official extension list can still be found here.
Now I hope you enjoy studying BlueSpice features 2016. Comments and questions are of course always welcome.
This little helper from MediaWiki enables administrators to search and replace words or text passages. The changes can be done in the content of wiki articles and in article titles. Fast and easy, because the modifications will automatically be made in all relevant articles.
Special page to search and replace single words or text passages in articles
Search and replace in article titles
Usage of placeholders and regular expressions
“Replace text” has been tested to be operational for MediaWiki and BlueSpice by the BlueSpice developer Hallo Welt!
We set ourselves a couple of goals for 2015 and 2016 at our strategy meeting at the start of January. The most important ones relate to the MediaWiki distribution BlueSpice. We are making this successful product truly open source, offering new prospects for customers and partners.
100% subscription, one product, no more modules.
We have been developing the BlueSpice service model further and further over the last five years. In the future, BlueSpice will be made available in an integrated distribution. This means that the additional modules that require payment will be collected together in a single edition. Customers will thus be able to use all the modules from the outset. And, above all, you will gain tremendously from new developments as all our latest innovations will be contained in this distribution. This means that those new developments will always be available for subscribing customers whenever they want. This will save you the trouble of having to purchase them separately. Furthermore, as there will no longer be costs for each module, getting started with a professional solution will be significantly better value.
In parallel, there will still be the popular distribution BlueSpice free, which is downloaded 20,000 times a year, and used in over 130 countries and more than 20 languages. The free distribution contains the same scope of services as before, and remains the ideal first step in collaborative knowledge management.
Supporting growth and propagation
Why are we doing this? Firstly, because now we can. The major Linux distributions Red Hat and Suse have always been the examples we have followed: The best open source models for customers and developers are made in the Linux environment. However, moving away from project business and without outside capital, we are only now able to take this step.
Another reason is that we want to build the best open source wiki with new partners. This is only possible with extensive openness, technically and economically. The module system has been good for us and our customers. However, it is now blocking us from developing MediaWiki further into the most popular Wiki software for businesses. A module system will become too complex and opaque for customers and developers as we grow further. Also, we do not want to lose our way in administration, but rather to concentrate on development, integration and quality assurance.
Radically open source
For this reason too, we are radically opening the development to external developers. They can, from this year, contribute to all BlueSpice extensions, including those which had been previously unavailable. In this way, we open up the project for other developers, accelerate the programming and improve quality assurance.
Last but not least, BlueSpice should become more compatible with SemanticMediaWiki (SMW) so that customers and partners need no longer decide whether to choose SMW or BlueSpice. Using both is already a possibility. But, by the end of the year both worlds should interlock better.
It will be a busy and interesting year. The new version will already be ready for examination and ordering at Cebit. We have already set out the stages which will follow this. We will be moving towards an ecosystem, which is a familiar concept from other open source projects.
We look forward to all your support and cooperation.
Sometimes it can be useful to change the title of a wiki article, but without moving the page. This means, that the URL stays the same and all links that refer to this site remain active. Only the title in the content will be displayed differently.
For example: You created the page “Prices” as a subpage of “Products”. The title will be shown this way “Products/Prices”. You don´t like it, because you only want “Prices” to be shown as the page title? Just use the variable DISPLAYTITLE to define any title, which should be displayed. Here is the code, according to our example:
There are lots of use cases for this feature, e.g. if you want to shorten a very long title, if you want to hide the prefix of a namespace (like turning “Portal:Quality Management” into “Quality Management”), and so on. Or also if you want to overcome the MediaWiki obstacle of the mandatory capital letter (for example an article about the “IPod” looks much better if you change it to “iPod”).
Attention: Please take into consideration, that it could confuse your users when they are looking for the article. They keep the title in mind, but can´t find it because the wiki system is still using the real title of the page.
Communication and notification – the end of the classical discussion pages
Another MediaWiki construction site is delivering good news: The MediaWiki Communication System. This concerns the discussion pages. These will soon disappear, in the form we know them now. More precisely: The discussions pages will fundamentally change and merge with the notification system.
The reconstruction of the MediaWiki communications system will take place through two new extensions:
Echo allows the individual following of changes, gives an overview of the whole system and is a framework for a variety of communication services. Echo is already in Wikipedia as a new notification system.
Flow makes discussion easier. One can more easily follow discussion processes; answers are shown via Echo. And much more. The aim of these developments is to build up a modern discussion and collaboration system for all Wikimedia projects. An interactive prototype is already online.
In the end, MediaWiki will have access to a new communication layer, which has long been overdue. It is important to note that the combination of articles and discussions – a characteristic and principle for the success of MediaWiki remains. The articles will not be separated from the discussions which relate to them. The linking of articles with discussions is a basic principle which makes MediaWiki unique, giving it something special compared to other solutions. Flow and Echo can really bring this basic principle of MediaWiki to its full potential.
However, many in the Wikimedia community are sceptical. For them, the current systems is absolutely adequate. Behind this, there is an interesting debate.
Erik Möller writes: “Do we want discussions to take place in a document mode, or do we want a structured commentary mode?”
This is the difference between saving discussions on a page or in a database with other possibilities for sorting and filtering.
Even though saving onto a page has a certain charm – particularly with respect to archiving, it is unlikely that this principle can be maintained for long. The advantages of following different discussions in a central place are convincing and overriding.
Collaborative data collection – Wikidata & Friends
A further signpost to the future is the development of collaboratively managed databases. The project OpenStreetMap is already well known, and creates map material using the wiki principle.
Wikidata follows a similar path, a collaboratively managed database. The different language versions of Wikipedia need not only pictures and videos, which are currently collected centrally in Wikimedia Commons. Providing metadata centrally is just as important.
Before, each language version needed to be changed by hand.
To provision all Wikipedias and for all use cases, is a very ambitious aim. After all, the data is not included in a homogeneous data schema. The data samples differ enormously by topic and cannot be centrally predetermined. This can only be done by authors. The authors can freely specify the data fields and composition themselves. They can add to new data fields or delete them. This also means that authors need to agree on uniform nomenclature and consistent data management. Further, the sources of the data must be shown so that one knows where a number, name or value has come from.
The effort is, however, worthwhile: One of the next steps will be to display the data better, in order to, for example, show personal connections in politics and history better. This will be significantly easier with Wikidata. For example:
This will develop, in a similar manner to the project Wikimedia Commons, a publicly accessible store of data, under a free licence, meaning a part of the web’s memory will become open to all.
This development is, therefore, pioneering for the free web. Initially, data will be collected for the Wikimedia projects, but very soon other projects will be able to consider using Wikidata software. For example, when data is to be collected about a specific specialised area which is too in-depth for Wikipedia; or when it is necessary to keep control over the data sets. I am thinking of Lobbypedia or more extremely Wikileaks. This requires protected Wikidata infrastructure, which is kept by a circle of trustworthy people.
The end of the category pages and SemanticMediaWiki?
Alongside the build up of this database infrastructure, another MediaWiki feature will soon belong to the past. We are talking about category pages. Up until now, the category information (indexing) was inserted in the wiki source text. This concept has, like discussion pages, its charm, but it leads to very laborious management in the long term. Due to this, it is likely that Wikidata will eventually replace the category system. The category pages are, however, often also used as practical portals. This function must be maintained. But these are the topics of interest for the years to come, and the discussion has only just started.
This is also true for the future of SemanticMediaWiki. Some see Wikidata as the successor technology on the horizon. For this, though, Wikidata needs to develop significantly as regards implementation and adaptability. And as Semantic needs absolutely no extra technology, and is being driven on by a very lively community, there is no end in sight. It is actually more likely that the Semantic community will anticipate many developments which will only later be taken on in Wikidata.
Lastly, I would like to highlight another very promising development: Great strides have been made in the automatic translation of content. The extension Translate, which has been in use for a while now, is developing to translate system texts from open source software projects. Henceforth, this function will be extended by a technical translation aid which will already be able to suggest whole text passages as translations and improve their quality significantly because one can use Wikidata. The first versions were introduced at Wikimania 2014 and the end of the second step has recently been announced. Languages are being added one by one and the functionality is being continually extended.
All these developments are focused on the needs of Wikipedia and possibly on its sister projects. It is, however, necessary to make these developments useful and available in the long term for other use cases and non-Wikimedia projects. For this reason service providers will have to provide the necessary services – from development and customisation up to maintenance and support at a high level.
There is a lot happening for MediaWiki at the moment. Further development of the software has been getting recognisably bolder for more than a year. It is getting exciting! In 2015 we will see many changes which up to now have been being worked on in the background. In just a few years, the system will no longer be comparable with today’s MediaWiki. Both the technical architecture and the user guidance is being rethought and tailored to the new expectations of the users. We want to quickly introduce you to the newest development projects.
The new impulses in MediaWiki development come primarily from the Wikimedia Foundation (WMF), the operator of Wikipedia and its sister projects. The foundation sees its core task for the future as software development and is looking to build up its personnel in this area a great deal. The new executive director of the foundation, Lila Tretikov, announced in October 2014 that the majority of investment will flow into product development and software development. Within this, priority will go to building up mobile functionality (for more on this see the entry by James Temple).
Skinning – Improved overview
Normal users will notice the changes most in the design of Wikipedia. The new skin “Winter” will soon be implemented. You can already see an interactive prototype on the web.
Clearly a fuller redesign which was envisaged with the skin Athena is no longer being pursued. However, the appearance of Wikipedia and therefore of the standard software MediaWiki will still become significantly better organised, and more modern and consistent. The new design should invite participation, ease processes and give the user better orientation. The classical functions – editing, discussing, compare versions etcetera – are being moved more to the foreground and being better organised. Also, some functions which were more hidden are being integrated more elegantly in the skin.
Wikipedia will be made more visually attractive, and so MediaWiki too, with the extensionMediaViewer. This allows picture sources to be displayed better and larger. Additionally, one can click through the pictures contained in an article.
Mobile front end
The MediaWiki developers are not focussing their skinning on responsive design, but rather by offering their own user interface with the name MobileFrontend which will be continually developed further. Where the developments in the mobile area will lead, we cannot say at present. However, we can expect that the editing and maintenance of text, uploads and user communication will be built up.
In the meantime, Wikipedia fans have an improvement to the WikipediaApp, which also has a nearby function: By using geographical data, the app shows Wikipedia articles about buildings and facilities in the immediate area.
On top of this, there is a nice app for the dictionary Wiktionary and one for Wikimedia Commons. Nevertheless, there is still a lot to do. In particular apps for other wikis – including company wikis – will be needed in the near future. We have a first version of the Enterprise Distribution BlueSpice ready. These developments are aimed at the concrete needs of the user.
More convenient dialogues
There are also developments to the dialogues. In Wikipedia, you can already see these improvements when inserting categories, comments or templates. Therefore, the plans for the extension Upload Wizard are very promising. UploadWizard guides the user step by step through the uploading of data and has been developed for Wikimedia Commons. The Wikimedia Foundation’s Multimedia Team are expanding this extension step by step to 2015. In this way, documents uploaded via Wikipedia can be uploaded to Commons simultaneously. Uploading via Drag&Drop is also being considered.
Task: Continuity and integration for businesses and organisations
These are the most important developments for the whole project. We at Hallo Welt! have already pre-empted many features with BlueSpice. Insofar as MediaWiki is now providing tools which fit better into the software landscape, we benefit because we no longer need to continue some developments. We can concentrate on the conception of the enterprise distribution.
However, there is a great deal of work waiting for us here as the new MediaWiki features are in some places not particularly far developed in terms of the scope of the services they provide. They need to be further customised to fit the use cases found in businesses. This is because an enterprise distribution has necessarily different requirements to those of Wikipedia. Our task is to combine the extensions in the right way, to standardise them and to integrate them.
In particular, the WMF developments have the drawback that they are introducing new technology which is little supported by hosts or internal IT departments. Specifically, we mean the webservice Parsoid, a special Wikitext parser; the virtual machine HHVM; and the programming language Luafor template programming.
Hallo Welt! aims to provide a continuous and reliable development, alternative solutions and integration so that MediaWiki can always be used productively and in an up-to-date way outside the Wikimedia world.