Invitations and Becomings

I've been a big advocate of wikis and in particular Wikipedia for a long time now, and during that time, I've always argued that you can't discredit Wikipedia by exposing factual errors, for the simple reason that - with enough contributors - exposing an error is practically equivalent to fixing it. In any case, there's no formal distinction to be made between reading and writing Wikipedia (that's the point!), so you can fairly ask any critic who finds an error, why they didn't just fix it. (Let's call that the well-fix-it-dear-henry argument).

I think that argument still holds, but there is another way of looking at it, that makes it seem a little less rosy. If you treat the content of Wikipedia as code, and ask how robust it is, it looks pretty awful. The dark-side of always having people available to fix bugs as they arise, is that those bugs can appear anywhere at any time, and what's worse, they can pop up again later.

From a coders perspective, of course, an intermittent bug is the worst kind. You can't reproduce the problem, in order to ensure you've fixed it. Of course, the antidote to this in the development world is bug-tracking. The closest thing to this in Wikipedia is the article history (probably one the most revolutionary and underestimated features of a wiki), and the pages that need attention lists that the community creates.

I'm not trying to say that Wikipedai is broken... it isn't. But thinking about it from a development perspective really exposes where the pressure comes from that inspires forming a mini-community within the greater Wikipedia community, an elite if you will, who hold themselves responsible for systematically improving the code in a coordinated effort.