Enterprise MediaWiki vs. SharePoint

"Enterprise MediaWiki" is a general term with a few different meanings. For this essay, we'll use it to refer to the combination of MediaWiki and a variety of useful extensions that are only used in enterprise installations and not on Wikipedia - including Cargo, Semantic MediaWiki and Page Forms.

In the enterprise, Microsoft SharePoint is the biggest competitor for MediaWiki. When companies and other organizations are considering using MediaWiki, for any sort of data management, SharePoint is the alternative they almost always consider, if they consider one.

SharePoint provides a variety of different functionality, but broadly speaking you can think of it as two things in one: a document-management system, and a content-management system. For the document-management part, SharePoint's specialty is providing a central, web-based interface to store and edit Microsoft Office documents: Word, Excel, PowerPoint, etc. For the content-management part, SharePoint provides a way to create standard "groupware" elements like wikis, blogs, calendar events, tasks, plus more free-form items.

If the main goal of your system is to manage Microsoft Office documents, then SharePoint is undoubtedly the way to go - no one handles editing of Microsoft documents better than Microsoft. However, for most organizations, content management is an important feature, or even a crucial one. And for content management, we think Enterprise MediaWiki offers the clear advantage, in almost every way.

Enterprise MediaWiki's main advantage draws from its simplicity. Instead of treating tasks, events, news items, etc. as different things, every item is the same thing: a wiki page. With Enterprise MediaWiki, it's the set of templates used within a page that serve to specify its purpose, and its data structure. That simple approach offers a number of advantages right from the beginning:

• Flexibility. What if, in SharePoint, you want to add additional fields to an event, besides the standard ones? Or you want to have more than one kind of task? It's all doable in SharePoint, but it requires customization, and most likely some custom coding in Visual Basic - after which you have a set of proprietary code that you need to maintain. In MediaWiki, conversely, the same process exists for creating any kind of page type, that involves only creating wiki pages and some markup within them. Unlike with SharePoint, there are no pre-defined page types like events or announcements. But once you get the hang of working with templates and forms in Enterprise MediaWiki, creating any kind of page type, no matter how complex, becomes a fairly simple task.


• Complete version history. Having a version history for everything can be critical, especially when you have many users potentialy modifying documents at the same time. SharePoint has versioning - when changes are made to documents or to groupware items, you can track the changes, revert them, etc. But there are a lot of limits to SharePoint's versioning ability:
  
  
  • In SharePoint, you can check out a file for an unlimited amount of time, and make any set of edits you want, before checking it back in - if you do that, all intermediate edits will be lost.
  
  
  • Let's say, in SharePoint, that you have a page type containing some custom fields. You decide to remove one of the custom fields, but then a week later reconsider, and add it back in. All values for that custom field, both the most recent ones, and all previous ones, will be lost. With MediaWiki, on the other hand, every value that has ever existed in every page is preserved, even as the data structure changes.
  
  
  • In MediaWiki, changes to the data structure are themselves preserved in the version history. The entire data structure is defined via a set of wiki pages; so as the structure changes and expands, previous versions are automatically stored, and can be reverted to. In SharePoint, there's no record of previous versions of the data schema.
  
  
  • Pages that are deleted in MediaWiki are never truly deleted - they can always be restored by an administrator, along with their full version history, if needed. In SharePoint, deleted items are gone for good.


• Better tagging. There's one way in which Enterprise MediaWiki has an advantage over SharePoint even in dealing with Microsoft documents: improved tagging and classification of those documents. When you upload a file to SharePoint, the contents of the file, and its name, are all that's stored about it. So what if you want to find all documents relating to, say, hardware sales in Virginia? You need to see if a list of such files is maintained somewhere, or if all such documents are contained in a specific folder, or do a text search and hope that all such documents contain the words "hardware", "sales" and "Virginia". In MediaWiki, every uploaded file has an associated wiki page attached to it, and you can easily set up a form for users to enter whatever metadata fields you wish to have for documents, to make searching and aggregating easier. The same goes for actual wiki pages: in SharePoint, you can create wiki pages, but you can't tag them - they are unstructured data. With Enterprise MediaWiki, as you might expect, a mostly free-form wiki page can still include a little bit of structured data at the top, to help in finding it later.

(An analogy can be made to the world of cooking: SharePoint can be compared to a large set of knives you can purchase, each one for a separate task: slicing vegetables, cutting meat, cutting bread, filleting fish, etc. Because the aim is to sell these in bulk, their quality is often low; but at least you know, right out of the box, exactly which knife should be used for which task. Many experienced cooks and chefs, though, use the proverbial "one good knife" for almost everything, because once they've gotten used to it, it can do almost everything they need. Enterprise MediaWiki is like the one knife: once you understand how it works, you can do most things with it.)

Additionally, there are more weaknesses to SharePoint, unrelated to its data design:

• Security. SharePoint runs entirely Microsoft software, and while we respect Microsoft as a global software developer, there's no question that Windows NT, IIS and the like have a record of many more security vulnerabilities than the server software MediaWiki usually runs on, Linux and Apache. And MediaWiki's own security is provably strong, given that it successfully runs Wikipedia, one of the world's most popular websites.


• Cost. Finally, there's what some people consider to be SharePoint's biggest drawback: its cost. The cost of SharePoint is quite variable, and it depends on a number of factors, but it's undoubtedly expensive. Between the purchase of necessary software like IIS and SQLServer, and the actual user licenses, implementing SharePoint for a 1,000-person organization will most likely cost over $100,000. And that's not even counting the consulting fees, if you hire consultants to customize your SharePoint installation - they can easily cost even more than the software. In contrast, Enterprise MediaWiki is free and open-source, and the software it usually runs with - Linux, Apache, MySQL, PHP, etc. - is all open-source as well. (PHP is required, and the other three are the standard options.) Implementing it of course takes time and/or money, but in our experience it's a different order of magnitude: the most we've heard of companies or organizations spending on an Enterprise MediaWiki implementation is in the tens of thousands of dollars, while some companies have been known to spend millions on SharePoint.

In fairness, there is one other major advantage to SharePoint, besides its ability to work with MS Office documents: its built-in access control. If you need fine-grained restrictions over who can read which pieces of data, SharePoint is the better tool. In practice, though, we've found that the need for such read-access control is usually minimal: information that's truly private is usually restricted to email or hard-copy anyway. And for good reason: once a piece of information or document is uploaded to a CMS, often simple human error can make it readable to everyone, no matter how good the access-control system is.

For some other features, Enterprise MediaWiki and SharePoint are comparable. In SharePoint, you can query SQL-based databases, and structured files like XML and CSV files. You can do all of that in MediaWiki too, using the External Data extension. And MediaWiki and SharePoint both offer workflow-type functionality, in which certain events trigger pre-specified actions.

Return to main page.