(Yes, this is a blog post about an one-line change in source code. I felt that making a 1600-word blog post was justified. Irony has been duly noted.)

Quick! What’s one of the biggest collaborative literary projects ever? If you answered “Wikipedia”, you’d be hideously right.

Everyone knows what made Wikipedia work so well: You can actually just join up and add pertinent information yourself. Do not listen to the often heard criticism that you can no longer just hop in and add information; yes, the standards of inclusion have gone up dramatically over the years, but there has never been any sort of bureaucracy you have to deal with to get stuff included in the articles. Previously, people said “just add that stuff in”. Now, we say “research the topic, compile a list of reliable necessary sources, study Wikipedia’s style, and in general make sure that your contribution fits in with the rest of the information - then add your stuff.” If you add sourced material, people are less likely to shoot it down. In a few years, they might even invite you to the cabal which I haven’t been yet invited to and whose existence is only rumoured.

But the greatest thing that Wikipedia demonstrated is that wiki-style collaboration is the best form of collaboration for all literary projects. If it involves collaboration and it involves text, then it should be done in a wiki. Suddenly, there is no overlapping work, there is no confusion, there is no need to be worried about mistakes, there is no need for bureaucracy or verification. People can immediately review and correct each other’s mistakes.

I can say, with utmost certainty, that the only areas where Wikipedia has shown problems and failure are the places where bureaucracy rears its ugly head. Bureaucracy is antithetical to wiki work. You are not supposed to whine about problems, you are not supposed to delegate work or review; everything, everything can be fixed with a healthy dose of .

So why the hell do we still have these bureaucracies set up in literary projects in open source world?

In December 2009, I saw a curious new feature in Inkscape:

Luukut? WTF?

“Trapdoors (rough)”. Yes, you can now add rough trapdoors in Inkscape. Or little doors. Holes in the walls, maybe. Who knows. If you just squinted and went “WTF?”, you’re probably not alone.

Of course, with a few moments of squinting and thinking, it dawned to me. Oh! So that’s what it’s trying to say…

Oh, right.

Why of course! Silly me. But that doesn’t take away the fact that there’s an obvious translation flaw in the application.

It’s spring 2011. A major release or a few of Inkscape has occurred since I noticed and grumbled about the issue in identi.ca. The screenshots are from the most recent version, 0.48.1.

How do you fix this?

How would you fix this?

I filed a bug report. It’s a small issue, of course. People file bug reports about small issues all the time. I have a full confidence that this small bug report gets handled in due time, perhaps even before 2012. In an identi.ca conversation in 2009 when I found out about this issue, I gave a hint to a person who may or may not be involved in Inkscape development - I thought that small issues like this could be fixed easily. Obviously, I should have taken a more constructive approach and filed the bug report right away - otherwise, small things like this could be forgotten. Identi.ca isn’t an Inkscape development site anyway - this was just an unofficial sideline.

I filed a bug report because this is the only way I can make a difference in the development.

Someone in Twitter brought Inkscape i18n guidelines to my attention. In short, the guidelines go like this:

  1. Join a translation team. Definitions of translation teams are not formally specified. I am part of TranslateWiki team, does that count? Who knows. It is not necessary to simply know who here knows more about the translations than you do; you need to know their secret handshakes too. And join their spam mailing list. Which leads us to…
  2. Join the project’s spam mailing list. This is despite the fact that email is getting increasingly obsolete and absolutely sucks for group communications, and mailing lists are a relic from the 1980s that no one in their right mind uses them these days. The technology has advanced in great leaps and bounds since then. We even have discussion forums that can be accessed through web browsers these days, allowing greater transparency for the whole process.
  3. Inkscape uses a highly advanced and efficient distributed version control system called Bazaar, which allows for meticulous tracking of file history, including all of the changes to the file contents. Fucked up? No problem, just revert it. Anyway, in order to do translations, you need to completely bypass it. Either check out a copy of the file through a web interface or copy it from a local bzr checkout. You’re going to leave all of the modern amenities of bzr behind for a while while you work on the translation file!
  4. Under no circumstance you should try to commit and push the changes through bzr. (Didn’t we say so in the previous step?) Likewise, the Launchpad translation interface should be avoided at all costs, because it formats the translation files correctly, thus avoiding all challenge. (Got to stay on the toes!) Instead, format a patch and send it to the patch tracker. When you commit stuff through bzr, they’re usable right away; when you put things in the patch queue, they’ll be committed “when the stars are right”. Much more appropriate, don’t you agree?
  5. Describe your work in detail, because if you don’t waste your time on red tape, people might think that you’ve actually done some real work. The patch will be reviewed (so that it properly refers to hatches and not hatching) and committed.

One of the reasons why I think the distributed version control systems are so great is that they cut down the bureaucracy. Want to start developing new great features? Fork the repository. When you’re done, tell the other guy “hey, I’ve got a bunch of cool shit ready, merge plz.” I don’t want to act as a patch gatekeeper; that’s the software’s job. So if you work on some of the stuff I have on github or gitorious, just fork it and do stuff and tell me to merge it back through a push request.

And when you think of it, that’s basically the idea behind wikis - just in a distributed format. No bureaucracy. Just hack this stuff. I’ll merge stuff when I get around to, because it’s easy.

Strange to think that before DVCS, I wasn’t very interested of developing anything in open source world. Sites like SourceForge wanted some bureaucratic steps in setting up the projects in the first place. They wanted mailing lists. They wanted patch queues. GitHub said “want to start a project? Create repository, push shit in. Think it would have made more sense to use Gitorious after all? Just push the shit in there and delete the repository here. It just works.”

Sites like Launchpad.net and TranslateWiki have taken a very simple approach to translating as well. Want to translate stuff? Just go and translate that stuff. Launchpad just messes with the Bazaar repositories. TranslateWiki is, well, a wiki. Don’t worry about messed-up translations. And TranslateWiki had “bureaucracy”, sure - asking for translation rights through a form letter and adding a name to a list. Not very bureaucratic.

And this is the future of open source development: Development should be distributed, translation and documentation should be wiki-like. The easier it is to hop in, the better. The better the tools we have at disposal, the better. Why mess with patch queues when we have modern tools to review code changes? Why be afraid of changes when everyone makes mistakes and mistakes should be freely reviewed and fixed? Do not become The Gatekeeper. Accept the fact that you, just like everyone else, acts as the gatekeepers. Ensuring quality is your job. And you can rest easy if there are days when you can’t do it, because it’s also everyone else’s job.

The slightly ironic part of this stuff is that I don’t really have much regard for people who whine about deficiencies of Wikipedia in blogs. Ultimately, Wikipedia’s content will be just fine. People will be able to fix it. Content isn’t going anywhere (well, it won’t, once we properly pillory and rottentomatify the deletionist zealots). The sky isn’t falling. We can, and should, debate about the bureaucracy and how to fix the challenges the user community faces, and how to ensure quality in Wikipedia. But that debate can also occur in Wikipedia; we have no need to go to random blogs to whine about the EVUL stuff that’s going on in WP.

But here I am, whining about problems getting a small translation fix through an open process, because I’m too stubborn to go through the hoops that shouldn’t even exist in this day and age. Inkscape is wrong in keeping their translation methodology in the stone age. There are still projects out there that make use of the same archaic bureaucratic approach to translating.

The “local translation team” bureaucracy rubbish and the mailing lists can be easily replaced by wikis. Need dictionaries and maintaining consistency? Wiki pages. Lots of them. Need to contact someone who knows more about this stuff than you do? Look at the wiki page, people can list themselves there. Want to join a project? Put your name in. Want to leave a project? Remove your name. Going to a vacation? Add “gone to a vacation” after your name - it’s not hard!

I sincerely believe that getting rid of these barriers, getting rid of all this needless bureaucracy, would increase the number of genuine contributors to open source projects. We need to detach the community aspects from the technical aspects, and make the technical aspects as smooth and easy to use as possible.