One of the reasons I was relictant to write a wiki before starting work on ikiwiki was the wiki/blog spam problem. Now that ikiwiki is reasonably mature, it's interesting to look back at how that turned out.
The basic spam prevention mechanism in ikiwiki is the same as the one many wikis use: By default, it requires registration before you can edit a page. This is a pretty small stumbling block for spammers, especially since ikiwiki doesn't bother with email verification. It even prefills the login form with your username and password after you register. It would take about 5 lines of perl to defeat its registration process. Suprisingly, only one spammer has spammed any of my wikis.
To defeat that spammer, I added the most common second layer defense against spam: A blacklist. Again I implemented the bare minimum, a way to blacklist a given user and ask them to "go away". Nothing to blacklist IPs, nothing more complex. That was put in place last October and I've had no problems with spam since. Around the same time, I made a change that I feared might open up a whole new class of spam, when I added openid support to ikiwiki. As far as I know, noone with an openid has tried to spam an ikiwiki wiki yet.
Ikiwiki did grow one other common spam prevention tool. Josh Triplett added support for a user account creation password, so you have to know the password to get an account at all. This isn't used by default though. The only other possibly anyi-spam measure is that ikiwiki does allow locking down pages so only an admin can edit them, or so they can only be edited via commits to a revision control system. I use these methods for personal stuff like my blog, and might have cut down on the incentive to spam. Spamming a discussion page is just not as interesting as adding spam direct to my blog's rss feed.
It seems likely that any new wiki system will have less spam at the beginning, especially if the spammers have to write code to bypass its registration system. That one spammer spparently did so fairly early is suprising. That no others have tried since is also suprising. My ease at blocking the spammer by simply banning them suggests that they were going after the easiest possible targets, and that it's not yet worth their while to work around even the simplest countermeasures. But if so, why did they add support for an entirely new registration system? My guess is that their existing code happened to work with ikiwiki's registration system. (This would take probably 20 lines of perl. ;-)
Of course, there's all kinds of counterspam measures that I could implement if needed. By the way, if you use ikiwiki and have had problems with spam, I'm of course interested in fixing that. It'll be interesting to see when additional measures turn out to be needed, as the wiki and sites using it become better known.