September 28, 2006
Overengineered Wikis
According to Wikipedia,
A wiki is a type of website that allows users to easily add, remove, or otherwise edit and change some available content
To add to that, a wiki usually has a minimal markup from which readable output (usually HTML) is generated.
Wikis are cool technology. Unfortunately, general adoption of wiki technology suffers from a critical fault: specifically-tailored, overengineered solutions.
Wiki software packages come with all sorts of features-- file uploads, WYSIWYG, user permissions, spaces, plugins, advanced caching, etc. This is all fine and dandy, but they are missing one significant feature: indirection of core wiki abilities.
At its core, a wiki is just a parser for a grammar, a versioning system and a front-end to the system. Wiki syntax is just like HTML, BBCode, TeX, XML, etc. It is a markup language. Nothing more, nothing less. Wikis are different from (most) content management systems in that they store a complete history of every change, much like RCS, CVS, or Subversion. Again, nothing special here. All wikis have these two attributes. The only thing that makes one wiki software package different from another is the front-end to control it all.
My peeve is as follows. If two of the three qualifying attributes for wiki software are common among all wikis, how is it that wiki software varies so much? Why, when I install a wiki, don't I have the choice of selecting the markup parser? Why also can't I select the version storage system? These components should be interchangeable, should they not? At the programming level, there should just be a set of common interfaces for interacting with a wiki parser as well as storing content. Everything that makes one wiki software different from other wiki software should be the UI, ACL's, file attachments, and whatever other gadgets are part of wiki packages.
Let's take MediaWiki for example. MediaWiki powers Wikipedia and because of this, its wiki syntax is probably the most recognized of all in existence. When selecting a wiki, one might want MediaWiki based solely on the popularity of the syntax. However, MediaWiki simply doesn't work for many scenarios. You want access control? You are out of luck. You want a very simple interface, again, you are out of luck. You look at DokuWiki. But wait, its wiki syntax is different and it only stores revision information in files. This isn't suitable! The same holds true everywhere you turn. One wiki offers a great set of features, but the limiting factor is often the syntax or the storage engine, something for which you have a hard requirement.
In case you haven't guessed, this all goes back to deploying a wiki farm at Case. We are already dedicated to MediaWiki on wiki.case.edu. Unfortunately, MediaWiki doesn't support ACL's (despite what the access control patches available claim to do) and it doesn't easily support the concept of spaces. Making MediaWiki perform as part of a wiki farm is like hammering a square peg in a round hole. The ideal solution is to take something like SocialText and plug in the MediaWiki syntax. But wait, you can't plug-and-play wiki parsers. Back to square one. Ugh.
Trackback
You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/9226 .