[WikiWorks: MediaWiki consulting]

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:

(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:

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.