In 2005, I wrote a book on managing open source projects, [30] much of which is about exactly what this chapter is about: setting up tools to make teams more effective.
A while after the book was published, and its full contents placed online, volunteers started showing up to translate it into other languages. Naturally, I was extremely pleased by this, and wanted to help them as much as possible, so I set up some technical infrastructure to enable the translators to collaborate. Each target language generally had more than one volunteer working on it, and having the translators for a given language work together was simply common sense. In addition, certain aspects of the translation processes were common across all the languages, so it made sense even for translators of different languages to be able to see each other's work.
It all sounds good on paper, doesn't it? But what actually happened was a deep lesson in the consequences of failing to understand a team's tool needs.
The infrastructure I set up for the translators was basically an extension of what I had used myself to write the book: a collection of XML master files stored in a Subversion repository, written to the DocBook DTD, and converted to output formats using a collection of command-line programs driven by some Makefiles.
Let me try saying that in English:
I wrote the book in a format (XML) that, while a bit awkward to work in, is very easy to produce web pages and printable books from. For example, here's what the beginning of Chapter 3 looks like in the original XML:
<chapter id="technical-infrastructure"> <title>Technical Infrastructure</title> <simplesect> <para>Free software projects rely on technologies that support the selective capture and integration of information. The more skilled you are at using these technologies, and at persuading others to use them, the more successful your project will be. This only becomes more true as the project grows. Good information management is what prevents open source projects from collapsing under the weight of Brooks' Law<footnote>, <para>From his book <citetitle>The Mythical Man Month</citetitle>, 1975. See <ulink url="http://en.wikipedia.org/wiki/The_Mythical_Man-Month"/> and <ulink url="http://en.wikipedia.org/wiki/Brooks_Law"/>.</para></footnote> which states that adding manpower to a late software project makes it later. Fred Brooks observed that the complexity of a project increases as the <emphasis>square</emphasis> of the number of ...
Here is what that becomes after being run through the converter to produce web output:
Chapter 3: Technical Infrastructure
Free software projects rely on technologies that support the selective capture and integration of information. The more skilled you are at using these technologies, and at persuading others to use them, the more successful your project will be. This only becomes more true as the project grows. Good information management is what prevents open source projects from collapsing under the weight of Brooks' Law[8], which states that adding manpower to a late software project makes it later. Fred Brooks observed that the complexity of a project increases as the square of the number of … .
One can certainly see the similarity between the two texts, but there's no doubt that the XML master files are harder to read. For me, that was OK: the inconvenience of working in XML was outweighed by the ability to produce different types of output conveniently.
I managed the collection of XML files using a version control system called Subversion, which is very familiar to programmers, but less widely known outside the programming community. Similarly, the converters—one for web output and another for printed output—were powerful and flexible tools, but somewhat hard to use, especially for non-programmers. Just to set them up you must first have various other supporting programs installed on your computer. The overall process is difficult under any circumstances, but it's a bit less difficult if your computer runs on a Unix-like operating system (again, common among programmers, but not other demographics), and a bit more difficult on Microsoft Windows.
All of this was fine when I was the only author. I'm a programmer anyway, I was somewhat familiar with all those tools already, and since I was putting in a lot of effort to write the book in the first place, adding a little extra overhead to learn some tools was well worth it. I knew it would pay off in the long run, and it did—for me.
But the situation for the volunteer translators was completely different. They were not all programmers, most had no prior experience with these tools, and they therefore faced a steep learning curve right at the start (always the worst place to face a steep learning curve!). Furthermore, since any given translation was being done by several translators, for each individual the ratio of tool-learning to real work was worse than it had been for me: each translator paid the same tool-learning cost I paid, but each translator was not writing an entire book, and therefore had less benefit across which to amortize that cost. The translators showed up with one particular kind of expertise—the ability and desire to take English text and rewrite it in another language—and found themselves asked instead to take on a task completely unrelated to that expertise: that of learning a whole new set of tools, tools that they might or might not use elsewhere in their lives.
The wonder is not that some of them rebelled, but rather that we got any useful translations at all. We did get some: as of this writing, the German translation is draft-complete, the Japanese is about 80% done, the Spanish about 60%, and so forth. (The French are a more interesting case; we'll get to them in a moment.) But seeing what the translators had to go through to get this far makes me wonder how much more could have been done if I hadn't imposed such a high tool overhead on the process. Take a look at the translator guidelines I wrote up at http://producingoss.com/translations.html#guidelines to get a sense of how much engineering was required of the participants. (I'd just show those guidelines here, but they'd take up too much room, which already tells you something.)
Unfortunately, for a long time I didn't realize how punishing the aforementioned system was. I knew it was less than ideal, but it's very hard to tell why any particular translator isn't doing as much work as he said he would—and it's impossible to notice when a translator doesn't volunteer in the first place because he's daunted by the requirements.
Eventually, though, we got a wake-up call from France:
From: Bertrand Florat <...> Subject: French translation To: ProducingOSS Translators Mailing List Date: Sun, 17 Feb 2008 16:54:32 +0100 Hi Karl, Just to keep you in touch, Etienne and myself moved to the Framalang wiki to finish the book translation. We plan to port all its content to docbook format once done (it's about 90% done now). I think it could be a good idea to link the French translation from http://www.producingoss.com/fr/ to http://www.framalang.org/wiki/Producing_Open_Source_Software so people can benefit from the almost-done translation right now, and it could bring new translators. What do you think? Cheers, Bertrand
In other words, the French translators decided to route around the technical infrastructure that I had set up to help them translate the book. Instead, they copied all the English data over to a wiki, where they could do their editing in a convenient, familiar environment. When they're done, [31] they plan to port the translation back to XML.
That's a pretty searing indictment of my infrastructure, I'd say. And looking at the Framalang wiki site (http://www.framalang.org/wiki/Producing_Open_Source_Software), I can't really blame them. It is much more suited to the task of coordinating translators than the ad hoc system I'd set up. At Framalang, the original text and translation are displayed next to each other, in different colors. There are special functions for tracking who is responsible for what portions, for giving feedback, for providing a centralized list of agreed-on translations for common terms, for labeling what work remains to be done, and so on. All of these things can be accomplished in my ad hoc system, too, of course, but the difference is that they aren't handed to the translators for free: the team is forced to reinvent the wheel over and over, whereas Framalang just gives out the keys to the car (see the figure on Conclusion).
Bertrand's announcement prompted another translator to voice some dissatisfaction with the homegrown infrastructure:
From: "Manuel Barkhau" <[email protected]> Subject: Re: French translation To: [email protected] Cc: [email protected] Date: Sun, 17 Feb 2008 17:21:35 +0100 Reply-To: [email protected] Bonjour mon amis, on a different note, maybe you would like to share you're experience with the wiki format vs. subversion. How much participation have you received apart from the main translators. How many translators joined your effort, quality of their work etc. Something I especially miss with the current format, are reader statistics and feedback. ciao, Manuel
Seeing this on-list correspondence made me think back to private conversations I'd had with some of the other translators. Many of them had had problems working in XML. Even though the translators themselves generally understood the format well enough to work with it, their editing tools often did not. Their word processors (particularly on Microsoft Windows) would sometimes mess up the XML. This was something I'd never experienced myself, but that's only to be expected: I'd chosen the format in the first place, so naturally it worked well with mytools.
Looking back, I can correlate the conversations I had with frustrated individual translators with dropoffs in their contributions; a few of them actually stopped doing translation altogether. Of course, some turnover is to be expected in any volunteer group, but the important thing is to notice when dropoffs happen for a specific reason. In this case, they were, but because I was personally comfortable with the tools, it didn't occur to me for a long time that they were a significant gumption sink for others. The result is that I effectively turned down an unknown amount of volunteer energy: many of the translations that were started have still not been finished, and some of the responsibility for that has to lie with the awkward tool requirements I imposed.
[30] Producing Open Source Software (O'Reilly; http://producingoss.com/).
[31] In fact, they finished their first draft of the translation while I was writing this chapter.