So, you want to set up a wiki, but you don’t know which wiki software packages are out there? Check out the WikiMatrix. It features an interesting wizard to help you narrow down your choices!
This page here will introduce you to the most popular choices, and try to help you make your decision.
See also WikiChoosingStories for stories about how individuals chose which Wiki Engine to use to host their wiki.
A software package which runs a wiki is called a MeatballWiki:WikiEngine. There’s hundreds of decent Wiki Engines out there; there are many, many wikis which have all the “basic” features. For most applications, none of the advanced features are critical (just convenient). So, you have such a large selection of good choices that choosing a wiki is more a matter of just randomly settling on one than it is a matter of carefully evaluating all of the alternatives. (i.e. unless you have unusual needs, STOP READING PAGES LIKE THIS AND JUST TRY ONE ALREADY!)
Perhaps the best way to evaluate a given wiki engine is to participate on a wiki running that engine. If you’ve already participated on a wiki whose software you liked, just install that one.
If you are considering a wiki engine which you haven’t personally used, go over to the development wiki for that wiki engine and play around; try out the Sandbox, etc.
Once you start installing candidates and writing your new wiki, be prepared to switch to another engine in the first week or two in case you find your choice really annoying in some subtle way.
Unfortunately, we are still in the stone ages and it is not yet possible to completely automatically migrate content from one wiki engine to another. There may be automated tools for this in a few years, but for now, be prepared to be relatively “stuck” with your choice once the ball really gets rolling. It’s fairly simple to migrate content – tell the community that you’re in the process of migration, and let them copy-and-paste the raw text from one to another. Let those users that whined the loudest about how we need this whizzy new Wiki Engine “volunteer” to translate from one wiki syntax to another wiki syntax.
MeatballWiki:UseMod stands out because of its extremely simple, uncluttered user interface and ease of use, while still offering the most useful advanced features. Out of the most widely used wiki software, surprisingly few meet both of these criteria (perhaps MeatballWiki:PhpWiki does, also).
Oddmuse is a fork of MeatballWiki:UseMod. Most of the advantages and disadvantages of UseMod apply to Oddmuse as well, so we lumped them together. Although UseMod has been around longer, Oddmuse has a more active developer, so you may want to consider Oddmuse first.
The wiki that you are looking at now is running Oddmuse.
MeatballWiki:MoinMoin is a very popular Wiki Engine; lots of plugins available, more features than UseMod & bigger developer community. It’s the largest wiki written in Python. Seems to be liked by open source community.
Used by the award-winning MeatballWiki:WikiPedia.
Has discussion board, file library, wiki, weblog, etc features all rolled into one, but the UI is way too cluttered, and their wiki support is pretty poor, despite tons of random features; last I checked, sometimes page changes wouldn’t show up on RecentChanges (!!), and there was no way to indent a paragraph on a wiki page.
A lot like UseMod; pretty good; uncluttered UI.
Maybe the situation has improved. If so, please remove this paragraph. In 2004/2005 the occasional PhpWiki user joined the WikiChannel asking for help. There was never any help available, so other Wiki Channel members kept recommending MeatballWiki:PmWiki as an alternative that was also PHP-based.
Very nice, easy to use, has some great extensibility features (there’s a long Cookbook with lots of custom extensions, tips, and tricks). You can quickly create skins.
Noosphere is not a wiki, but it’s close; and many people who think they want a wiki might actually prefer Noosphere. Noosphere is the software used by Planet Math (http://planetmath.org).
The principal difference between wiki and Noosphere is that each Noosphere entry is owned by one individual; their idea is that that will instill a sense of responsibility and gravity for each entry. The owner may, if they choose, give read/write access to world, however, emulating a wiki page. Either way, in their setup anyone may COMMENT on a page; so even the page owner can’t sweep a disagreement under the rug.
Tiki is somewhat difficult to learn and use; the others are managable.
While many computer programs are considered easy to use (by current standards), few can be considered to be extremely simple.
Most of the popular software is featureful, but has many buttons on each page.
That’s fine if your community will be mostly seasoned wiki users, but if not, one philosophy is that the interface should be totally unintimidating, and be so uncluttered that users will learn about how wikis work just by stumbling upon the appropriate functions. Specifically, “View other revisions” and RecentChanges must be “stumbleable”.
It may be hard to teach someone “we can all edit each other’s stuff without fear because anyone can revert to a previous version”, but if they stumble onto “View other revisions” themselves, they’ll get the idea.
But if there’s 15 options available on each screen, users will never bother to try them all out. So, this theory goes an uncluttered interface like UseMod’s will be best for new users (at least, that was how I learned).
I haven’t heard of any scaling problems with any wiki software. However, a wiki COMMUNITY usually has scaling problems before wiki sofware does. How to scale a wiki community is a big, unsolved issue in wikiland; see CommunityMayNotScale for discussion on this.
BillSeitz offers 2 counter-examples:
AlexSchroeder adds: Yes, for Emacs Wiki we had similar scaling issues when it came to searching the wiki. We now use Duck Duck Go. At first, we had our own full text index but it didn’t scale well.
For most wikis, all the data is in a directory or a database file, and so you can back stuff up just like anything else.
ANY wiki does better archiving of discussion than email or message boards or newsgroups.
Some wikis save all past revisions, some (such as UseMod) basically allow you to specify how far back to save past revisions, some have an additional feature called “way back mode” where you can go to a past version of a page, and the links will take to the past versions of other pages. There may be more sophisticated mechanisms, but I don’t know of any.
Many wiki engines do support this, but I haven’t paid attention to which ones because I’ve never needed it (please edit this line and add specifics if you know them).
One generic method is to just configure your webserver to do the access restrictions (i.e. don’t involve the wiki software at all). Usually the user has to do an HTTP POST in order to write to a wiki; I know Apache can selectively block POST requests to a website, and I expect the MS webserver can too.
Quite a few wiki engines can be set up so that everyone can append comments to the end of a page (similar to a blog), but only members can edit the page or the comments.
At least one wiki has independent access control lists on every page. One list of people is allowed to append comments to the page. Another list of people is allowed to edit the text of the page. The list of people can include actual user names, a special symbol indicating “everyone”, a special symbol indicating “no”.
Typically, the home page is set to “no one can edit; no one can add comments”. Typically, a user’s page is set to “no one can edit, everyone can add comments.” Users who have bad spelling may set their user page to “only logged-on people can edit; everyone can add comments”.
The “owner” of a page is, typically, the person who initially created that page.
The owner of a page can change the 2 ACLs on that page.
The owner of page can edit the page no matter how the ACLs are set.
In most cases you won’t need to do this, though. WikiPedia has shown that an active user community can repel vandalism. Communal norms can keep new community members in line. As Clifford Adams once said, “…most Wikis replace technical security with social and political limits.” See SoftSecurity for more discussion along those lines.
Some wiki engines let people subscribe to their favorite page(s). Whenever that page is modified, all the subscribers get a notification email. Of course that means people must tell the wiki their email address, usually by signing up as a “member”.
Some wiki have an email address. If you send email to that address, with the name of a page as the only thing in the subject line, it will append that email to the given page as a comment.
(I think TikiWiki does this)
See the “see also"s at the bottom of this page for more.. There’s tons of pages on this topic at WardsWiki, but they tend to include lots of wiki software rather than listing only the most popular/stable ones.
If you have any questions, feel free to post it below and we’ll try to answer it.
The theory mentioned in “extremely simple interface” is my personal theory, of course. Perhaps I didn’t make it clear enough that this is just one guy’s theory, rather than consensus.
On the other hand, if you want something more like a Blog (or a BlogWiki), you might be interested in the Blog engines (TooManyBlogEngines? ?) at http://www.theconnexion.net/cgi-bin/blogwiki.pl?Blog_software
Web Oriented Architectures ... and why Mozilla adopted the Deki Wiki by Jonathan Erickson 2008 describes why one major wiki decided to migrate from one wiki engine to another.
See also TooManyWikiEngines.