Four years ago I would not have said MediaWiki limits Enterprise 2.0. I was a big fan of MediaWiki. I was the WikiMaster of the very visible Enterprise Architecture Wiki at Fidelity Investments — one of 15 wikis in active use at the time. I had admin privileges on some of the other wikis too — and got a good sense of how they all worked. I started off with JSPWiki – very old-school. I played with a few others. Eventually I landed on Confluence and stayed there for a while. I even ported my entire MediaWiki site to Confluence — something which took about a half a day for all the text and about two weeks for all the other tables, images, and templates. Since then I’m been known to mess around with other wikis too, including Jive, SocialText, and PBWorks, to name the more popular ones.
Whereas many analysts hear about technologies at vendor briefings and see them in demos, I have built them, shaped them, and taken them down myself. So I’d say I have had a fair share of hands-on time with wikis. With that said, I’ve come to a conclusion — MediaWiki inhibits Enterprise 2.0. Shocking conclusion considering that it was MediaWikis success that really opened things up for Enterprise 2.0 initiatives at Fidelity. But I took a long look at the screen/mirror and this is why I came to my conclusion.
- Wiki Markup. Editing a page on a mediawiki feels like travelling back in time to the mid 80s using a PDP11 or some DEC Vax station. The only difference is that the screen is not green. Sure you can get a WYSIWYG plug-in, but they don’t work right. One the one hand Mediawiki powers the most successful wiki in the world (Wikipedia) – so I cannot claim that it’s not useful or functional. The problem is that when you just focus on a workforce of thousands (not a consumer-space of millions), the participation dynamics changes. Wiki-markup is a big barrier for authoring new pages, and it’s just OK for fixing pages, as long as you avoid tables. It’s the manual transmission of wikis. Sure you can drive a stick shift with just a bit of practice – but imagine a rental car company (in the US) that only offers stick shift – they’d go out of business. Wiki-markup inhibits the contributions of many potential contributors. So if you know that your employees will resist – why deploy it? There are better tools out there.
- Only open. Mediawiki appeals to “orthodox wikians” who insist that all information in a wiki must always be visible. And the wiki is quite resistant to any page level security features. Every attempt I have seen to secure pages is easily foiled with a simple transclusion operation. One of the architects of MediaWiki told my programmer at Fidelity that it is simply not designed for the kind of security we wanted. Sure you can always secure server access – but that’s a whole other story. I’m talking about partitioning spaces within the wiki. You think you can secure namespaces – but I can foil the security – and there’s nothing worse than a false sense of security! Realistically, there are some things that need to be secure. Maybe 5% or 10% of your enterprise wiki. But if your wiki only accommodates 0%, then you’ll loose 75% of your potential users.
- Document silo. If you allow document attachments to MediaWiki, then you really mess up your document management processes. Real companies hope to manage their documentation in an centralized manner (e.g. SharePoint, Lotus Notes, Documentum, or at the very least a Network File Share). Sure, these are hardly the kind of systems that people like to use — but they do perform a corporate function. Most successful enterprise wikis that I have seen either integrate with a document repository (so that your documents are stored where you want them stored, but show up on the wiki where you want them to show up), or they don’t allow document attachments — which is fine, but it limits the kinds of collaboration you can do.
- Collaboration dead-end. Once you roll out a wiki, you might want to some other social networking features (e.g. like the kind that Lotus Connections, SocialText, Jive, Mindtouch, and just recently, PBWorks, and many others provide) and perhaps some other features that those platforms offer (blogs, forums, microsharing, etc.). You cannot make MedialWiki support these features without a lot of customer design work – and even when you do, it’s unimpressive. Your MediaWiki content suddenly becomes an island of really good content – with little ability to integrate into another platform (with the exception of displaying stuff from the RSS feed).
So whereas I one loved Mediawiki – my love for it has waned. It has not kept up with the marketplace. MediaWiki was a great option a couple of years ago. It was much better than JSPWiki and the many other open source wanna-be professional-class wiki knock-offs. But for some reason a huge, popular Open Source product did not beat commercial software in this marketplace. The commercial options are simply better.