MediaWiki is a free software wiki package originally written for Wikipedia. It is now used by several other projects of the non-profit Wikimedia Foundation and by many other wikis. Since MediaWiki is so well-known, a frequent question is: What is the difference between MediaWiki and Tiki?
MediaWiki is the most deployed wiki engine. As such, it enjoys a massive virtuous circle. However, since MediaWiki is primarily developed to run Wikipedia (and your project is not Wikipedia!), it may very well be that MediaWiki is not your best choice. Many people pick MediaWiki just because so many others do. Similar to "Nobody ever got fired for picking IBM", often, people will not go through a proper analysis and consider other wiki engines such as DokuWiki, TWiki, XWiki_old, MoinMoin, etc. Since it's so well-known, you will likely need arguments to explain this. This page is here to help
If you are already using MediaWiki and you are thinking of moving to Tiki, you can use the MediaWiki importer
- Both are free and open source web applications with a powerful wiki.
- Both can run on standard, inexpensive hosting.
- Both support Wiki markup. Please see (if) Why Wiki Syntax Is Important to your project.
- Both are written in PHP and can be used with MySQL
- Top-2 wiki engines with the most consultants
- While people often compare them, Tiki is also comparable to Drupal and Joomla! as it's a full-featured CMS which happens to be Wiki-centric.
- MediaWiki is focused on being a great Wiki for projects such as Wikipedia, whereas Tiki is more of an out-of-the box Content Management System / general purpose wiki with all the features built-in. Because of these design choices, Tiki has more features out-of-the-box. MediaWiki doesn't offer forums, bug tracker, blogs, etc
- Tiki is more centralized. Tiki is the all-in-one model while MediaWiki (like Joomla!) is the small-core-and-add-what-you-need model. Each model has its pros & cons.
- In MediaWiki, there can be more than one "extension" for the same feature so they have different names. Whereas in Tiki, there is only one and thus, the name is descriptive.
- Tiki has all the features built-in (and you just activate/deactivate features), thus, every Tiki instance of a given version has the same code base. This makes it easier for a hosting company and for upgrades. In contrast, if you maintain dozens of MediaWiki sites, they will have different modules installed depending the use case.
- When Tiki is upgraded, all the features are supported and the upgrade is smooth. In MediaWiki, some of your plugins/extensions may have become abandoned or be incompatible with the new version.
- MediaWiki is highly optimized for performance and distributing content on hundreds of servers (which is needed for Wikipedia)
- In MediaWiki, pages are case sensitive so https://meta.wikimedia.org/wiki/Case_sensitivity_of_page_names is different than https://meta.wikimedia.org/wiki/CASE_sensitivity_of_page_names which can make sense on Wikipedia, but for most other wikis, it's more user-friendly that http://doc.tiki.org/Wiki and http://doc.tiki.org/WIKI show the same content. Domain names & emails are not case insensitive, so it's the same for Tiki wiki pages.
- While Tiki is a very large and popular project ( over 200 contributors to main code base and a huge number of installs), MediaWiki is several times larger in terms of install base.
- MediaWiki usually handles multiple languages by having separate installs while Tiki uses the cross lingual wiki engine for synchronized translations. Please read: The Cross-Lingual Wiki Engine: Enabling Collaboration Across Language Barriers
- MediaWiki is GPL, Tiki is LGPL. The main difference between the GPL and the LGPL is that the latter can be linked to (in the case of a library, 'used by') a non-(L)GPLed program, which may be free software or proprietary software.
- Thanks to the Smarty template engine, Tiki can look like MediaWiki, but what about the other way around?
- Tiki has more enterprise features built-in, such as LDAP.
- Tiki has a very elaborate permission system while MediaWiki is very clear that "If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data." and also "MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content."
- The MediaWiki lifecycle is focused around Wikipedia with the goal of limiting support for old versions. (why support old versions which are no longer used by Wikipedia?). The Tiki lifecycle also limits support for old versions but every third version (3, 6, 9, etc.) is identified as Long Term Support (LTS). (useful if you don't want to upgrade too often but still want the security fixes (ex.: enterprise). Non-LTS versions are no longer supported once a new release is out. Tiki has a time-based release schedule.
- Thus, with Tiki, you can have over 3 years of support on LTS versions, while a maximum of 1 year on MediaWiki
- If you are a consultant or enterprise, Tiki will be much easier for you because it has so many more features built-in and if you develop something, it has a much higher probability of being accepted in the core. For MediaWiki, your feature will be accepted in the core if it's suitable for Wikipedia, but if not (which is often the case for enterprise features), that feature is destined to forever be a 3rd party extension.
- Tiki has built-in (but optional) WYSIWYG
- Tiki offers threaded comments instead of talk pages
- In Tiki, you can attach files to a page or use the File Gallery feature.
Contributors (All Time) click "View as graph"
Commits (All Time) click "View as graph"
So, one thing to note is the great Wiki:TopTenWikiEngines list, which does a nice job of narrowing down the field of contenders for new implementers.
I think choosing MediaWiki as the de facto standard wiki engine is a horrible idea:
- MediaWiki development has always and will always be focused on Wikipedia.
- It is difficult to extend.
- The code is indefensibly badly written. I know – I’ve written quite a bit of it.
- It is difficult to skin.
- It requires a database.
- No WikiWords.
- It is so slow that it requires tons of Squid server, memory cache add-ons, etc., etc. just to run correctly. The code is developed as if you have all these extra servers available, and if you don’t they’re stubbed out.
That’s not to say that I don’t think that MediaWiki is important for any discussion of wiki technical interaction, but I don’t think MediaWiki is the VHS of the wiki world. I do think that wiki engines should have an easy way to turn on “MediaWiki syntax mode”, so that admins who know they’ll have a WikiPedia-savvy community can easily get started that way. (I think PmWiki 2 will have MediaWiki syntax as an option.) But as we move into the WysiwygWiki era, I think that’s going to be less important.
The simple answer is this:
- Tiki Wiki is designed to meet your needs;
- MediaWiki is designed to meet the needs of the Wikimedia collection of projects, and heavily rooted in its unique ecosystem.
"It’s great that MediaWiki is so flexible and versatile, but that comes at the price of complexity. It can be troublesome to set up and maintain, which may lead to chronic frustration."
- Wikipedia content guidelines and how they relate to Tiki software features
- Five Key Differences between Wikipedia & Enterprise Wikis
- some background information about MediaWiki and TWiki (not to be confused with Tiki )
- Evan Prodromou, MediaWiki developer talks about MediaWiki
- MediaWiki to TikiWiki converter
- Where MediaWiki is C, Tiki is C++.
- Interesting Features from other Web apps