What is TWiki?
A leading open source enterprise wiki and web application platform used by 50,000 small businesses, many Fortune 500 companies, and millions of people. Learn more
Comparison between TWiki and MediaWiki
Which wiki should a company choose?
This article doesn't want to be a TWiki advertisement. Rather, it is intended to help enterprises who are evaluating which wiki software to use by giving reliable arguments and feasible answers
. Here we compare TWiki to MediaWiki
. We want to distinguish both systems and describe their aims.
MediaWiki gets most "leads" from its reference, Wikipedia
MediaWiki is Wikipedia's operating software; that's the killer argument for the system. Many managers see the success of the web encyclopedia and reason that:
- "Wikipedia is successful; we will succeed, too, if we just use the same software."
But that's not true. Successful corporate wikis depend on different criteria and have other success factors. One plausible counter-argument is:
- "If the success of Wikipedia drove its wiki-software to be the best wiki-software for all needs, it would become the only available wiki-software (ie, a category killer). That is, it would lead to a lot of obsolete, and thus abandoned, wiki-projects."
However, the MediaWiki project's fundamental orientation is in conflict with this goal. Although MediaWiki extensions (ie, plugins) can be written for any purpose, the core of MediaWiki has been written for Wikipedia exclusively and is optimized to its needs:
- "MediaWiki is geared towards the needs of the Wikimedia Foundation. The program is primarily developed to run on a large server farm for Wikipedia and its sister projects. Features, performance, configurability, ease-of-use, etc are designed in this light; if your needs are radically different, the software might not be appropriate for you." -- Ref: http://www.mediawiki.org/wiki/Download
So, an extension can written to do just about anything. However, if it requires a core service that doesn't promote the need to support Wikipedia (or worse, conflicts with it), the chances of getting the service added to the core are remote.
The requirements of a web encyclopedia and those of a company are entirely different. A company isn't in need of an encyclopedia, it's in need of an intranet extension based on a wiki. A wiki should be specific to the individual demands of the enterprise; requiring it to also be optimized as a platform for a web encyclopedia results in some conflicts.
As an example of such a conflict, consider the access controls provided by the two wiki engines. MediaWiki is justifiably proud of its high security against vandalism. Indeed, it's possible to undo changes rapidly, and MediaWiki is very good at comparing different versions of documents. Such options may be critical for a web encyclopedia; for an enterprise, however, they are generally irrelevant.
Both the HTTP server and the wiki software save the IP address (ie, identity) of the computer the change originated from. Also, many employees will be logged in to the intranet itself. Every IP address can be personalised by the IT department without any difficulty, and each modification can be retraced. So, an enterprise-level wiki generally "knows" who changed which document.
Consequently, vandalism in a company wiki occurs very infrequently and can be dealt with promptly. However, because MediaWiki doesn't provide access controls with fine granularity (e.g., page and web-level read and edit access by users and groups), it is actually less
suitable than TWiki for an organization which needs these features (e.g., to keep speculative product designs from being marketed prematurely).
It's unlikely that MediaWiki will change the security feature:
- "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. We are not responsible for anything being leaked, leading to loss of funds or one's job. For further details, see Security issues with authorization extensions. This extension requires patches to core MediaWiki code. Extensions implemented using patches may be disabled by or interfere with upgrades and security patches. If a suitable alternative without a patch is available, we recommend you use that extension instead." -- Ref: Extension:Page_access_restriction
In summary, because the needs of Wikipedia differ sharply from those of a typical company, MediaWiki's goals may not match the company's desired feature set.
The strengths of TWiki are the quality and quantity of the applications offered for the system. There are more than 400 TWiki extensions
which work well together to meet a company's needs. MediaWiki also offers a large number of extensions, but many of those aren't fully developed or aren't functional at all.
Most of the TWiki plugins are developed by professionals or companies who really care about the quality and adaptability of their applications with a view to give the community something back. Consequently, the extensions are on a high level of maturity. Moreover, TWiki permits users to write applications which perform a lot of tasks and is far ahead of MediaWiki. Mighty extensions such as ChartPlugin
are a good example on how to raise the intranet's reporting efficiency and effectiveness significantly.
List of arguments for MediaWiki
- MediaWiki is built for Wikipedia, it will surely be developed further in the future.
- The Wiki Markup used in Wikipedia is most likely to become "the" standard syntax for wiki markup (although there is an emerging WikiCreole standard).
- Very good handling of vandalism: It has to prevent unsolicited altering and "hacking" of the platform all day. That is not that important for TWiki as it mostly runs behind firewall environments.
- Very active and broad community.
- Better with scalability: Very good performance for reads (through caching) without customizations; also able to use database access to speed up certain search operations.
- (But: TWiki scales well for most of its use cases to tens of thousands of pages and thousands of users)
- Good I18N using full Unicode.
- RecentChanges is very detailed.
- Creates impression of activity, which can be good for uptake (but often based on minor re-edits).
List of arguments for TWiki
- One of the most widely used wikis in the enterprise.
- Over 400 extensions based on corporate needs.
- Active community with a lot of experience of corporate wiki deployments.
- StructuredWiki features: TWiki has a built-in database (with TWikiForms and SQL-like queries) to quickly create wiki applications, such as to-do lists, contact lists, project trackers, inventory systems, call center status boards, blogs and outage trackers.
- Multiple namespaces (TWiki webs, "wikis"): Groups and projects can get their own "wiki", and still link to related content in other webs (MediaWiki has one primary namespace with support for secondary namespaces).
- Built-in WYSIWYG editor.
- Good performance using ModPerl, TWikiCache, etc - but needs some customization/setup (more at TWikiScalability).
- Reasonable I18N support (but not yet real UnicodeSupport).
- Very flexible access control and authentication/authorization features. Groups can be defined in TWiki or imported from LDAP; content can be locked down based on groups on a page level, web level or site level for view, edit and create.
- Complete audit trail: TWiki version controls everything, even meta data such as access control settings.
- Flexible search: Keyword search, regular expression search, SQL-like query search are built-in; search in attachments possible (with plugin).
- Strong attachment support for document uploads:
- Attachments under version control
- Per page namespace for attachments.
- MediaWiki attachments (uploads/images) use a global namespace so users must use a file naming convention to keep filenames unique and avoid a mess of files where it's unclear which ones are out of date - the MediaWiki upload feature is really designed for JPG/GIF images, not documents.
- TWiki allows any file type to be uploaded, unless specifically excluded by administrator - MediaWiki requires administrator (with ability to edit files directly on server) to add file types.
- Easy to customize TWiki navigation bars - just edit a text page (harder to do this on MediaWiki).
- Revision control uses explicit version numbers: Easy to see from a printed copy of TWiki page which version it was based on - MediaWiki just uses dates.
- Recent changes is less verbose: Changes by same person to a page within 1 hour count as one version - TWiki site will seem less active but also less cluttered.
- Editable InterWiki settings built-in (MediaWiki requires a specific extension to be installed so users can edit the Interwiki settings - only administrator can delete the large default list of Interwiki settings).
-- Contributors: MartinSeibert
I'm using MediaWiki
quite a lot at work at the moment, as it's the wiki already installed by our IT department. Have added to some of the arguments above.
The biggest issue with Wikis is really getting people to use them - having our boss start using the Wiki was a key step forward.
- 21 Mar 2008
There is a very cool site for comparing Wiki softwares characteristics. It shows a big list of Wiki softwares, you can choose 2 or more and it shows a table with a list of characteristics of each:
- 24 Mar 2008
Good point - it is discussed at WikiMatrix
. Some of the above are probably not captured by WikiMatrix
but it's a good starting point.
One new difference added.
- 27 Mar 2008
The argument I hear most often when people switch from MediaWiki to TWiki is that mediawiki is missing some of the enterprise features TWiki has got, i.e. (sub)webs and access controll. The only reason to stay with MediaWiki - imho - is its scalability. If you have to manage a very large knowledge base think hard why not to use MediaWiki in favour of TWiki.
On a more technical level: MediaWiki's table markup is much more flexible while still quite clean. We have a MediaWikiTablePlugin
to bring that to TWiki land. MediaWiki has got parametrized transclusions as TWiki has, but handles parameters differently. TWiki expands markup in parameter position before
doing the transclusion - MediaWiki passes the markup down to the transcluded topic and evaluates it in the called context. So MediaWikiApplications can't easily be ported to TWikiApplications, by far not automatically.
- 27 Mar 2008
Thanks for the additional comments. That gives possibilities to enhance this article significantly with Screenshots and examples.
- 28 Mar 2008
Some more bullets added above. The attachment support is a huge difference btw, TWiki is much stronger here.
- 28 Mar 2008
Some Links that should be brought into this document: http://tinyurl.com/2hhqbm
- 28 Mar 2008
At Intel, MediaWiki
has become the de-factor standard for "public" wikis, that can be read by every Intel employee, while TWiki has become the most commonly used wiki for projects that need access control, need the ability to automate stuff via plugins, cgi, or tools that access the raw filesystem, and which need less support.
- 02 Aug 2008
I assume, that MediaWiki
should be stronger on Scalability (was already mentioned) and public wikis, just for the fact, that these are solutions necessary for Wikipedia, that the system automatically inherits. I will add that to the list above.
- 03 Aug 2008
There is no formal specification for either the MediaWiki or TWiki syntax. However, if TWiki opts to look into adopting MediaWiki syntax, Wikipedia might serve as a pretty solid set of test cases.
- 09 Sep 2008
I've been using MediaWiki
a lot recently at work, where it's been installed quite a bit, though one customer has mandated that we use TWiki. It really doesn't handle attachments well by default - all attachments live in a single namespace, rather than a namespace per page in TWiki, and TWiki generally has more mature support here.
However, I really miss the MediaWiki
'edit by section' feature when using TWiki - really need to install EditChapterPlugin
in TWiki, and it would be nice if this was in the core.
- 09 Sep 2008