Comparison Table

Comments

General

Personal remark: I always wanted to have such a WikiEngineComparison page and already had a deeper look at WikiEngines but I am very unhappy with all of them. Such feature lists do not help much. They don't describe the wiki engines properly and they especially doesn't answer the important question: "Which is the engine that meets my needs best?" And even more important: "Which engines should I avoid?" I'll try to describe MoinMoin but as already said this is not easy... -- FlorianFesti 2004-03-11 15:59:30

• I get asked this a lot because of my personal wiki and the Personal Telco Project wiki. I finally published a copy of my WikiReview if anyone is interested. It's not intended to be exhaustive in any sense but to answer the questions I get asked repeatedly (ie. "what wiki do you use" and "what wiki should i use for ..."). BTW, I think you're missing out by not comparing MoinMoin to PmWiki and Oddmuse which are two of the best up and coming wiki's available. -- AdamShand

The problem with these comparisons, is you have to learn and work with a wiki for some time to evaluate its qualities and weakness. Nobody can have experience with all wiki engines out there... -- NirSoffer 2004-03-12 02:11:45

• See PythonWikiEngines which already does this for python-based wiki engines.

Another wiki engine comparison is available at http://www.wikimatrix.org -- you can choose which wiki you want to compare in a side-by-side feature table. Their Choice Wizard and/or search can be very helpful if you aren't sure of what names to choose.

• Could somebody with FlexWiki experience add its info to the table? -- Lio

Features

Group Viybel 01/12/2004 : are "Groups" refering to pages' groups or users' groups?

Ease of installation A row in the table above should be added for "ease of installation". I suppose experts can infer that from the other listed items, but a rough idea of how quickly one can set these things up would be helpful.

Ease of Hacking I've not played with any other wikis extensively, but I think "ease of hacking" should be a consideration. I've found MoinMoin to be incredibly easy to extend. Themes, macros, and actions all work together to allow you to do anything you want with the wiki. The simplicity of moin translates into simplicity of change. For the wiki I've been working on we've changed nearly everything. -- PhilipNeustrom

WikkaWiki is extremely "hackable," with extensive development documentation available. --Brian Koontz

WYSWYG editing Could you add a feature of WYSIWYG editing (using htmlArea)? -Benjamin Hill

• Most WYSIWYG editors output HTML. If you can find one which does not generate HTML but wiki markup, we would look forward to integrate it.

Looks like twiki has one - http://twiki.org/cgi-bin/view/Plugins/KupuEditorAddOn - Benjamin Hill

No kupu http://kupu.oscom.org/ is actually a html editor based on epoz http://epoz.sourceforge.net/ which was designed as a wysiwyg editor for zope based websites. The actual addon is rather poor at best, it can only edit pages that already exist, it works by converting the html outputted by kupu into twiki markup. Essentially it is a hideous hack. Although the twiki maintainers are interested in integrating some kind of wysiwyg editor.

Ed.wiki has an integrated WYSIWYG-Editor. But you can't make it with a plugin, you have to rewrite all the wiki logic http://www.wb-giessen.de/edwiki (its german, prepared for i18n, translation needed)

As of MoinMoin version 1.5, there is has a great WYSIWYG GUI editor as described in MoinMoinFeatures

Clobber Protection Added Clobber Protection - Benjamin Hill

Email notification What does email notification mean? Automated email notice of changes in certain page? If so, Mediawiki does not have it yet (as of early 2005). -- Tomos

MoinMoin

Main focuses of MoinMoin are:

• Wiki and only wiki: MoinMoin has a large number of features but they are all related to wiki. There are no discussion section, bulletin boards or other stuff like this. We see this as a strength.

• Lots of MoinMoin features aim at intranet use. Either because they may be problematic in public use (Attachments, ...) (btw. we use most of them in our public wiki anyway) or because they don't scale to very large wikis (embedding search results into pages). Nevertheless there are some MoinMoin wikis on the BiggestWiki list. But if you want to start a wiki encyclopedia you may want to use MediaWiki.

• Extensibility: As you can see above every (well known) wiki supports plugins. MoinMoin supports the following plugin types:

  • macro: embed a function result into wiki page (see HelpOnMacros, MacroMarket)

  • action: do anything (see HelpOnActions, ActionMarket)

  • parser: support other formats as a page in the wiki (see ParserMarket)

  • xmlrpc: do remote procedure calls using xml (that is very easy in python)

To make it short: it is very easy to integrate other formats or applications into MoinMoin and "integrate" means: making them available within wiki pages and not just putting a link on them.

• Ease of use: MoinMoin is intended as a tool for collaboration. It does not primary focus on good looking documents but on glueing communities together. (Although MoinMoin pages don't look that bad)

See MoinMoinFeatures for details.

Main flaws of MoinMoin:

• It is not built to scale up to very large wikis (>>10.000 pages).

Other flaws related to the developers:

• Only few unit tests
• Design problems - little separation of logic and view, unclear responsibilities

MediaWiki

MediaWiki - the version used at wikipedia is NOT easy. Try to add some content and you will see how hard and annoying it is. Too much options and syntax, lot of work to download a file and in-line it in your text. MoinMoin is much better - less clicks and simpler syntax. I wonder if its because of my experience with moin syntax? -- NirSoffer 2004-03-12 01:49:32

MediaWiki is certainly pretty slow despite lots of kit to support it. -- AndrewCates

• I guess scalability has its cost... -- FlorianFesti 2004-10-01 10:00:58

I think Wikipedia is slow many times, but others are very fast - an example: http://www.tsunamihelp.info/wiki/index.php/Main_Page -- Tomos

Wikipedia has thousands upon thousands of users... It is not possible to make any conclusions about performance without looking at server capacity and load. One thing we can say is that Wikipedia has proven it can handle huge numbers of pages and accesses. -- Erik

• Yeah, scalabity is not null. They do a hard job increasing it to a level where it needs to be in order to support those billions of page impressions. (loadbalancers, DB replication, turkcache, static HTML caches, etc. pp.). One might ask if it might be desirable to have scalability built-in.

MediaWiki and MoinMoin have different targets. See the related comments from Brion (a media wiki developer) in MediaWiki.

• This is true. The way attachments are handled in MediaWiki make it, in my opinion, untenable for an intranet. MediaWiki has one flat space for attachments, so that every one has to have a different name. File uploads are also handled using a "special" page that's separate from the page you want to link the attachment, making link to a file even more difficult. I think this is just a reflection of the fact that MediaWiki is designed for the wikimedia projects, where you have people working on a single collective project. Everything is encouraged to have "top-level" visibility. In a company, where working groups are often working on separate projects, features like subpages and page attachments make sense. You don't want John to have to worry that Fred down the hall already uploaded memo.doc. --GregWhittier

For a more specific comparison, see MoinMoinVsMediaWiki.

WackoWiki

http://wackowiki.org/doc/

Is also a nice wiki based on php and mysql. -- Dick Stins

• Feel free to add it to the table above.

Nice Features, but I don't like the markup it uses.

Structured Data and Dynamic Pages

For some applications it´s very important to store and receive structured data. Here TWiki has an amazing functionality: The data can be stored using forms, and it can be retrieved in dynamic tables with sorting and filtering. see FeatureRequests/IntelligentDynamicTables. -- TobiasPolzin 2006-01-17 20:52:40

File Storage

Which is more effecient, storing wiki pages in a flat file, like JSPWiki does? or in a mysql table, like PhpWiki or XWiki do? I am concerned about the efficiently of handling big number of pages and attachments as well. Is a mysql table good enough to keep up with the growth of a wiki?

What do people think of that? -- Marion Hanz

Start by defining what you think "big" is. -- JürgenHermann 2005-11-09 18:12:12

I simply don't have a long experience with wikis to be able to state how is the efficiency by using a database or a flat file, that's why I'm posting this point here. Regarding installation and set-up though, of course a flat file storage is better, then it does not require more than just setting a page or attachment directory in some config file. A database-envolved set-up might be cumbersome for an unexperienced user, but this is not my issue. I am more interested in the performance and maintenance of the data in both cases in a growing wiki. - Marion

I just noticed that you are refering to "big number of pages", sorry, did not think, you meant that. Well, the wiki of choice will be set at a university department for the purpose of research. Employees as well as students will have an access to it. It will be an active wiki, which means, there will be a lot of contributions happening which in the end will make the wiki having to deal with a "big" number of pages and attachments, the size of both including versions are of course meant with big number. - Marion

Is big 1000, 10000 or 100000 pages?

Do you actually have something to say for this topic, or you are just trying to get an attention?? - Marion

I tried to answer your question, after getting a precise one. I stop now.

What should that mean? are you mad? Thank you anyway for having made an effort, although no one saw something from you. Things do not stop when you stop though...

As JürgenHermann asks I am interested in the answer too about how much pages we are speaking here? I don't know why it is so difficult to tell I like to use a wiki server which is able to handle about 100000 different pages. Whatever you tell us it is very easy for one of us having already a wiki to create such an amount of pages if we don't have them already. Afterwards we could probably tell something about maintanace, performance. -- ReimarBauer 2005-11-11 10:04:54

Ok, since it is for research purposes, I'd like the wiki to be able to handle a number of 200000 different pages. Which kind of wiki is better for maintanace and performance? Marion

I have organized our wiki by a farm configuration. So each group has it's own wiki instance with for example a separated search engine, separated title index, separated acls. Do you ask here for a similiar installation or do you want a TitleIndex over 200000 pages? I like to tell some more about the background I was asking this. If you set up one wiki for all institutes then you need a very good acl ruleset to destinguish who is able to give someone rights to edit a page. Probably the institutes people do have some pages which should not be seen in public and they have some pages which a subset of their members should edit and all others could only read. And some other pages could be edited by all members. By using one wiki for several institutes you have to add a prefix to a lot of pages. e.g. institute_FrontPage, institute_*templates. It could be difficult to find something useful by search. I believe it is more difficult to use one wiki instead of a farm. -- ReimarBauer 2005-11-11 22:25:08

I don't have time to update the TWiki column unfortunately, but TWiki 4.0 improves on quite a few areas listed here, including clobber protection, performance options (now works better with mod_perl, SpeedyCGI, etc), skins, security, code modularity, internationalisation (translated into several languages), etc. http://www.wikimatrix.org/ is more up to date, or see http://twiki.org/ for latest features. -- RichardDonkin

I currently run a wiki at my company (internally) and it has around 24,000 pages. It's running on a quad core RHEL 5 box with 3 GBs and is served with Apache running mod_fastcgi (4 threads). For text searches, we are using lupy (since non-indexed searches take forever, oh and for best performance, we are reindexing the wiki every night). We are noticing big slowdowns on our server due to the text search being dog-slow (even with lupy, if someone did a 4 word search it may take anywhere from 30 sec to 600+ seconds, depending on the terms being searched). Does anyone know of anyway to speed up moinmoin? Should I jump ship to media wiki since with a database backend, I could easily replicate and load balance to improve performance? - counterpoke 8/9/2007

• Converting 24.000 pages (and I guess also quite some users) to another engine would be a major pain, I guess, so I just suggest to wait until moin 1.6 and Xapian is ready. If you want to help, you can install the 1.6dev on a test machine and try it. -- ThomasWaldmann 2007-08-09 22:32:02 Start by running your wiki with at least 4 processes - not threads. With threads, all your searches are running on one core instead of all 4. Since you have lot of RAM, and you did not tell us about other software on your server, you may like to run much more processes. Do you really need one wiki with 24,000 pages, or you really want a farm with few smaller wikis? you will get much better performance with a farm, if you don't really need to search the whole set of 24,000 pages. -- NirSoffer 2007-08-09 23:07:04 I'll try MoinMoin 1.6, but isn't the problem I'm facing due to the the flat file storage that MoinMoin uses? Oh and, I am using 4 different processes, not threads. I have tried running 8 threads, but I did not notice any speed increase in real life or through ab2 testing. This is a dedicated machine with nothing else running on it. Regarding the wiki farming technique, my superiors want a wiki search interface where one could search though the entire wiki, so I think that's out of the picture. Oh, and the page count has tripled in the past year (1 year ago it was 8k, now it's 24k), so I'm also worried about hitting the "100,000" page limit specified on Wiki matrix. Thanks for the quick responses. - counterpoke 8/9/2007 There is no strict page count limit, that 100.000 pages number was just a guess. Xapian has a much better performance than lupy (and also less problems). IIRC, putting content from a wiki farm into a common index is already implemented. You might also want to look at the HowTo/Tune Performance page and using the timing.log of 1.5.8. Sometimes on can track back bad performance to silly things going on (e.g. many users having a search macro on their wiki homepage searching all pages where they have signed some stuff). BTW, we are currently working on a storage backend api for 1.7, so someone could even make a SQL backend (or whatever) rather easily after this backend is implemented. Note that doing silly things will ever kill your performance, no matter whether you use SQL or filesystem. -- ThomasWaldmann 2007-08-10 00:50:56

See also

• http://www.wikimatrix.org/ - Wiki Feature Comparison