MediaWiki limits Enterprise 2.0.

by Gil Yehuda on September 25, 2009

in Enterprise 2.0

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.

{ 3 trackbacks }

Tweets that mention MediaWiki limits Enterprise 2.0. -- Topsy.com
September 25, 2009 at 11:01 am
Proposing some sessions for #e2conf | Gil Yehuda's Enterprise 2.0 Blog
January 20, 2010 at 11:51 am
Quora
October 28, 2010 at 8:50 pm

{ 11 comments… read them below or add one }

1 yeysus November 28, 2009 at 3:12 am

Hi. I think there are 2 aspects to this, one is the business case, the other is the technology. If you want to have only one single-point-of-web2.0 software for your enterprise, you are after technology, and should buy one of the clones that don’t match with real life outside of a company, like Confluence and the likes. Think of it, you don’t have only one software suite for everything you need. Even MS Office has still, many years later, one Word, one Excel, one Access, one PowerPoint and one Outlook. I believe on the philosophy of openness that promotes MediaWiki, so I see MediaWiki at the top of the information road on an enterprise. Like the white pages, you search for something, you find a description, an address, a contact person and so on. Still, you need a second click to actually go to the website of your search term. Or somebody needs to open you a door and authorize you to go inside your searched address. This is the way I see it: MediaWiki on top as an open, informal, way of collecting not only “what” (btw including how-tos), but also “where is the information”, so you link from MediaWiki to your intranet, to your tons of specialised software, databases and portals (I work for an enterprise a few times bigger than Fidelity and much more diverse, I do have many pockets of information with many authorization schemas) and so on. Resuming: Non-regulated MediaWiki on top as a quick and informal Where to find What, below intranet (official communication channel of the corporate) and whatever information you want to link with read/write access control, including closed wiki systems like the ones from SharePoint and Confluence.

Reply

2 Chris Almond October 19, 2009 at 7:34 pm

Hi Gil!…

I’m googling q=transcluding+wiki+pages+in+sharepoint without any luck whatsoever, except for link to this blog entry in the top 10 catching my eye…
Although I sympathize with your concerns, I can’t agree with your conclusion. If you can tell me about an actual, useful, enterprisy content collaboration wiki that grew up on top of MediaWiki, which is now looked upon by its users (not IT and management – the *users*) as inhibiting their transformation into E2.0, then maybe I’ll agree with you.

This also got me thinking again about what E2.0 really is. The best definition I can find is oddly enough hosted by a MediaWiki based source :-)… wikipedia

McAfee’s SLATES is still there, along with Hinchcliffe’s extensions to that definition. I see nothing in the functions they list that aren’t exactly what you would expect to see in a vibrant wiki based community, running on MediaWiki or any other xxxwiki platform. These definitions stay well above the tools and platforms fray, as any definition of E2.0 should.

I’ve worked in two large enterprise cultures where “islands of really good content” sprouted up the intranet. They couldn’t wait for the IT bureaucracy to provided them with a platform that would most likely be hobbled and inflexible, so they deployed their own MediaWiki based solutions. And their wikis thrive. They become mission critical to their teams, departments, etc. But you know all this because you did it at Fidelity.

MediaWiki (or any of the other wiki platforms for that matter) don’t limit Enterprise 2.0. They enable it.

I have personally seen MediaWiki being seen as a threat by big IT toward their own e2.0 plans. But that was all about the platform, the technology, the ownership and the credit. It was not about what really mattered: collaboration efficiency, execution, and business results.

Reply

3 Gil Yehuda October 19, 2009 at 8:47 pm

Chris, thanks for the comment. Indeed I was stirring things up, so I expect some pushback. Funny thing, this very conversation came up today. I was at a client site, helping with an intranet redesign, and encountered someone who told me that they have a mediawiki instance that they are using for developer FAQs. The problem is that the mediawiki site is not going to be used for the “enterprise” — it will be used by a team of developers. There’s nothing wrong with that per se — but it’s not transforming the enterprise — just one team. For me “Enterprise” 2.0 must be more than just Department 2.0.

Mediawiki (and similar point solutions) enable groups to threaten IT’s sluggishness. And they indeed can be very valuable (as I saw at Fidelity with our 15 different active wiki platforms, half of which were on mediawiki) — but we ran into the “multi-headed chicken syndrome” where we eroded our ability to find stuff because we had too many wikis and no unifying strategy to mange content. So yes, E2.0 can shake up IT a bit (which is OK to do once in a while), but IT is not the enemy of enterprise computing. Moreover, if you are going to use a populist technology, MediaWiki is just too geeky to be useful for non-techies. Considering the commercial options that are available today — why would anyone use it when they could spend a few bucks and get something that non-techies would use too? And the answer is… because the people who love mediawiki are the techies. I understand this, because I was there too.

Reply

4 Frank October 7, 2009 at 3:08 pm

I recommend taking a look at SMW+ (http://en.wikipedia.org/wiki/SMW%2B). It tries to overcome some of MediaWiki’s shortcomings (especially Access Control), which are mentioned here.

Reply

5 sdfghj September 27, 2009 at 1:53 am

The problem appears to be that you want a CMS rather than a wiki. Which is fair enough CMSes are useful things. Mediawiki isn’t a CMS though yet and doesn’t pretend to be.

Reply

6 Will September 26, 2009 at 11:54 am

As to your complaint about editing in wiki markup, the problem I’ve found is that the tools that currently exist (take the Jive SBS text editor or Confluence Rich Text editor) that promise rich text editing are so buggy that, unless you know how to go under the hood, they are nearly unusable. For example, in one product (I won’t name names) it has been a year with no undo command in the text editor. In another, the rich text editor looks radically different than what is published. In a commercial wiki we have moved to, you can no longer edit section by section like you could in MediaWiki, and a page cannot tell you something as simple as where it has been transcluded elsewhere.

I actually like the control I get through wiki markup. Unfortunately you are right about how it doesn’t work in an Enterprise, but I feel this is for different reasons – we are simply so lazy a culture that no one can be expected to learn a few tags of markup.

Reply

7 Gil Yehuda September 26, 2009 at 9:03 pm

Will,
Thanks — you make a very good point. There is a difference between an occasional edit and an active wikian. The occasional employee will be much happier with a rich text editor that is simple, clean, and works. The active wikian may need more specific control over things like table spacings, image placements, and other details that markup gives you. I’ve had my share of frustrations getting Confluence to lay out pages the exact way I want it. It did take getting used to and giving up some control. It was once my dream that Adobe Buzzword (buzzword.acrobat.com) became the model that everyone copied — ‘cuz I really grew to like it.

Reply

8 Gil Yehuda September 25, 2009 at 12:43 pm

Readers who are interested may wish to follow a branch dialog on this post here: http://chieftech.com.au/mediawiki-limits-enterprise-20

Reply

9 Steven Walling September 25, 2009 at 1:48 am

Your specific points are 100% correct. The markup is an enormous barrier, it has no real flexibility in user permissions, and it quickly becomes a messy document silo even in the most savvy organizations.

But is it so much worse than SharePoint or the other enterprise software that eat up precious time and energy?I don’t think so. It’s certainly to be avoided, but a rant dedicated to it is overkill from my perspective.

Remember that MediaWiki wasn’t created to be anything except a venue for public collaboration. That anyone uses it for work behind the firewall is practically a fluke.

The platforms that truly deserve to be taken down a notch are those supposedly tailored to the enterprise, but which cause just as much harm as MediaWiki does (and most are proprietary to boot). How about a rant against one of those vendors, instead of free software that isn’t meant for the enterprise to begin with?

Reply

10 Gil Yehuda September 25, 2009 at 7:45 am

Steven,
You make a great point, so much so that I chuckled when I realized the irony here. The ostensible “wiki” functionality that is crudely slapped onto SharePoint 2007 is so bad that it has never impeded me. I have never encountered it being used for anything that was not, in-effect, a disposable document. So whereas I have great disdain for it, I did not have the urge to articulate it being a limiting factor to E2.0.

I suggest that if an enterprise has SharePoint 2007 and thinks that the collaboration features will be easily leveraged, then they are in for a surprise. The only successes that are based on SharePoint 2007′s features that I have seen are those where significant investment was made in order to make it work (or where they leveraged one of a couple of nice E2.0 platforms that extend or integrate with SharePoint 2007).

In the SharePoint 2010 time-frame we’ll have to revisit this, since by then Microsoft should have what we really wanted in 2007 (deliberate pun). And perhaps more — but that’s for another discussion.

Whereas MediaWiki has proven to be a small problem to me recently. Why? Because many of those who invested in enterprise wiki projects about 3 years ago used MediaWiki – yes, a fluke, but one that worked if someone was diligent and made it work. The fact that it was Open Source (non proprietary) was, to them, a “Good Housekeeping Seal of Approval”. And so they created really valuable wikis. (Many case studies on this — including those in the State Department, Defense Department, Financial Services, Semiconductors, and other industries.) Now these groups want to step into “more than just a wiki” projects and don’t know what to do with their MediaWiki-based, successful, wiki. The content is worth keeping, but the server is not affording the kind of expansion that one would get had they been on a commercial platform. So when I ran into the “but we have an Enterprise Wiki on MediaWiki, so how would that work with the…platform” conversation recently — I just thought “uggh” and wrote this post.

Reply

11 Steven Walling September 25, 2009 at 11:58 am

I can definitely imagine a lot of ways that legacy MediaWiki (implemented back when the market wasn’t as flush with enterprise-specific wikis) would be a barrier to progress right now.

In the context of what you ran into, which I’m sure is not a fluke, the post is pretty much spot on.

Reply

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Previous post:

Next post: