Mediawiki vs SharePoint

Its markup makes writing documentation fast and easy (wow that felt like an infomercial)

It doesn’t require any particular browser to be fully functional (or even partially functional)

Document editing is done in browser without the need of external software

Check-out and check-in/save are done in two steps unlike with SharePoint where you must download a document, check it out so no one can make changes while you are working on it, make your changes in MS Word, save changes in MS Word, upload new version to SharePoint, fill out changelog information, and delete the local copy on your computer to avoid clutter and having multiple copies of one document. That might have been a bit over exaggerated but certainly not by much.

MediaWiki tracks content. SharePoint tracks documents. They both provide versioning but because of MediaWiki’s content tracking, it can perform letter-by-letter comparisons on different article versions easily in-browser and without extra plugins (ActiveX, I’m looking at you!)

It has user pages which notify users if a change was made, making them ideal for assigning tasks to members of a team.

Permissions are rarely a concern (when should you be putting super sensitive information in unencrypted docs on a document repository anyway) as where in most SharePoint setups, permissions are often fought with. However, Mediawiki’s permissions structure is simpler and less robust so this isn’t necessarily a pro or a con.

MediaWiki is cheaper and uses fewer resources as a LAMP or WAMP stack requires a far less powerful machine and far less money in licensing fees than a Windows server running IIS and MSSQL.

Mediawiki is very fluid with its templating system and various popular extensions (one of my favorites is ParserFunctions) which allow it to be tailored to almost any project need without the need of an expensive developement team

MediaWiki is the software used by Wikipedia, so support and development for it won’t be going away any time soon. Backwards compatibility will also be maintained for a very long time because one of the biggest and most popular sites on the internet has a vested interest in it working well with their current setup

MediaWiki is secure, again because it is used by Wikipedia. It can be assumed that such a high profile site is under constant attack and investigation. How many times have you seen Wikipedia go down because of a hack? How many times have you seen a SharePoint site go down just because of daily use?

It also supports a standardized wiki markup language so it can be ported to other products much easier than a SharePoint shared docs site can.

As mentioned, SharePoint’s permissions structure is more robust than MediaWiki’s but again, this isn’t really a pro or a con, just a difference.

A SharePoint Shared Docs library can be mounted as a Windows share allowing seemingly local editing of documents.

SharePoint integrates easily into Active Directory. MediaWiki does too, but not by default.

Windows admins should feel more comfortable administering SharePoint. Mediawiki is certainly easier to use, but requires a different skillset to set up and administer as it runs on a different server setup entirely (eg: Linux, Apache, MySQL, PHP).

SharePoint supports browser-based calendars with a backend in Exchange offering mostly seamless integration of team calendars between Outlook and the team site. MediaWiki has nothing like this.