Ubuntu and Debian
Introduction: The authority and power of software repositories
This paper deals with the authority and power of software repositories, especially Launchpad and Rosetta, the repositories that contains the source code and translations of Ubuntu. It does this by extending some of sociologist Max Weber's notions of authority. Weber's idea of “charismatic authority” is well known to many free software developers, and to those who comment upon and study this phenomenon. The informal, personally achieved authority of the charismatic leader, like that of Linus Torvalds, has been well known since Eric Raymond wrote his papers The Cathedral and the Bazaar 1 and Homesteading the Noosphere.2 Eric Raymond's message is substantiated by a detailed empirical account and states that Free software projects stick together, rather than to fork, pretty much because this authority is respected. Raymond has made some very fine observations.3 But they are not enough. In the project that this paper is part of, the focus is on the two other, well known authorities of Weber, the traditional and the bureaucratic-rational one.
The basic idea of this paper-to-be is that repositories are traditional and bureaucratic-rational authorities, and that they do important coordination and integration work in free software-projects. As long, that is, as they are respected by their users.
By the term “tradition” I don't think of something from which one could, should or inevitably will emancipate oneself (in a modern progressive sense). I use the word “tradition” in a wider, more in communication-theoretical way. When a population share a language, this, following language philosopher David Lewis, means that there is a convention in the given population of truthfulness and trust in that language4 (Lewis 19755). To respect and be a part of such a convention of truthfulness and trust means to respect the authority of a tradition, the tradition of that language. And to share a convention of truthfulness and trust in a language means to respect the standards – the rationality, the protocols and bureaucracy – of that language. A note on words can here be in place: A “repository-in-use” is a bureaucracy because it is a particular kind of rationality which is partly externalised into formal and mechanical procedures. A “repository-in-itself” is nothing but a dead machine. A repository-in-use is a bureaucracy and it is made up of some actions, norms and representations that are internalised by its users, and some actions, norms and representations that are externalised into the machine. When I speak about “repositories” in this paper, I always mean “repositories-in-use”, unless otherwise stated.
These repositories, then, share some important features with languages. As languages, they are traditions and rationalities, and by being so they make communication possible.
It seems to me that an important problem that some (or many?) Debian Developers and Debianites in general have with Ubuntu is related to the way in which Ubuntu challenge the authority and tradition of Debian. Thus, Ubuntu pose a treat of making communication impossible. The treat of non-communication, the treat of forking.
Now it might be argued that the Debian fear of Ubuntu is precisely just that; fear, given by some of the Seven Deadly Sins, like envy, pride or greed. This is speculative. I don't know much about people's motives and I don't want to speculate about them. Rather I would like to take the arguments against Debian seriously, not to uncritically buy into them, but neither to dismiss them at hand.
The rest of this paper is mainly empirical. It first presents some of the criticism against Ubuntu and Launchpad. Focusing on Rosetta in particular I then go on to explore that criticism in more detail. I partly do this by drawing on my own experience with translating KDE into Norwegian.
Launchpad: Evil or just Adding Value (tm)?
Now, you all know that the appearance of Ubuntu stirred up some feelings in parts of the Debian community. One of the major starting points of the emerging conflict was an interview and a blog entry by Ian Murdock, spring 2005. This quote pretty much sums up Murdock's concern:
[Ubunbu is] diverged so far from Sarge that packages built for Ubuntu often don’t work on Sarge. And given the momentum behind Ubuntu, more and more packages are being built like this. The result is a potential compatibility nightmare.
Mark, this doesn’t end well. If you want a glimpse of what will happen, take a look at the RPM world, where software developers and ISVs have to build a different RPM for every RPM-based distro (either that, or the ISVs have to choose the one or two most popular RPM-based distros to the exclusion of all others–or perhaps that’s what you have in mind?). (Murdock at ianmurdock.com)
Several debates on Debian-devel followed suit, with this tread as probably the most famous one: Is Ubuntu a Debian derivative or is it a fork?6 This tread itself forked into multiplicities, but some of its important branches discussed the distinction between “fork” and “derivative” with examples of how Ubuntu could, should or actually did feed its changes back into the Debian repositories. Another major thread discuss the way in which Ubuntu gives proper credit to Debian developers, see the tread Ubuntu and its "appropriation" of Debian maintainers. At the same time (May – June 2005) the thread Canonical and Debian discussed, to put it very briefly, the power of Canonical versus that of the Debian elite (known with slightly self-ironic paranoia as “the Cabal”).
Later the same summer, at DebConf5, in Helsinki, summer 2005, Mark Shuttleworth and several others did a lot of work to try to reconcile the parts and resolve the conflict, for example in the two plenary sessions “The Ubuntu Talk”, held by Shuttleworth, and “Debian Derivatives”, a plenary chaired by the Debian/Ubuntu developer Benjamin Mako Hill. Very briefly summarised, Mark and other Ubuntu/Debian developers worked quite persistently to establish a legitimate position for Ubuntu, in the very heterogeneous and partly connected landscape that makes up Debian as a totality.
Talking to Debian developers towards the end of DebConf5 I still met a lot of scepticism towards Ubuntu and Canonical, and the scepticism was not directed towards Ubuntu per se, but most often to the way in which its repository, Launchpad, was organised, and the way in which it did, or did not communicate its changes back to the Debian and upstream repositories. People were also sceptical to the fact that Launchpad is not Free or Open Source software. “I would never submit my code”, a developer told me, sharing taxi to the airport after the conference, “to a repository where I have no insight into the flow of information inside it”.
Now, Christian Perrier, who is central in the internationalisation of Debian, is one of the Debian developers who has attended the Ubuntu-Debian discussions with a constructive attitude, working quite persistently, it seems to me, to bridge conflicts rather than to add fuel to the fire (see for example this thread7). However, in March 2006 he is making an emotionally engaged, slightly frustrated and clear statement on the importance of the non-free-ness of Launchpad, and its language tool, Rosetta, in particular:
Rosetta, langpacks... Jordi, we know that Rosetta is good (though Javier raised interesting concerns about it and more generally translation portals). But, eh, please spend some time convincing Mark that releasing the damn thing as free software would be the best Canonical could do to the community. I know you guys are probably nagging him nearly daily with this but, believe me, that would be the best that Canonical could do for i18n. Mark, listening? :-) (Perrier, Tue, 28 Mar 2006, at his blog, Bubulle's weblog8)
Perrier must have met many sceptics, like the one I shared taxi with, most certainly may more than I have.
There have also been a lot of blogging activity around the Debian-Ubuntu issue, and Launchpad/Rosetta in particular. Without having the slightest chance to cover the multitude of this writing, I will present an argument made in two clear blog entries from the time around DebConf5. Both blogs are written by Debian developers.
Sunday, July 17, the last day of DebConf5 in Finland, Debian developer Joachim Breitner posted a blog-entry called Launchpad, Google and why Microsoft is not the problem. I site it at length, to show the full argument:
I just came out of Scott's talk on revision control and package management. He also talked about Launchpad, a project by Mark Shuttleworth's Canonical Ltd. Launchpad collects, as far as I can tell, all (relevant) Free Software in source format from everywhere including the complete history, as well as all modifications done by the distributions, and puts it in a single revision control system. Supposedly, this has happened to a certain extend already, and fills up 1700 Gigabyte on their drives. This can be accessed then, for example, by the Debian maintainer to very easily integrate the changes that the Red Hat maintainer did to his sources, and the other way around, and so on. The technical usefulness is almost unlimited, and it seems as if this might be a service to the Free Software community larger than sourceforge.net and freshmeat combined.
So why would I blog about it? Because this is as dangerous as it is useful. What Canonical is trying to achieve here is to collect all the work that the free software have made and will made, and put them under their control. Sure, it is all accessible, sure, the code might even be free software someday (where someday is probably the moment that launchpad is so established that competitors, even with the same software, have no chance of establishing themselves), but the data is in Canonical's hand, and by this, we all depend on Canonical to continue providing the service. [...]
And why is this more dangerous than Microsoft? Microsoft did a pretty clever thing: By good marketing, clever programming and commercial pressure, they locked in a lot of people to use Microsoft products and formats. This is evil, but we have found a solution to that: reverse engineering and Free Software. Microsoft can be coped with. But Google and Launchpad were even cleverer. Instead of locking something in, they open everything: It is free, it has nice usable APIs to integrate in applications, and they suck all that opened data in and keep ahold of it. And while Microsoft has a record of doing a bad job when it comes to technical quality, thus helps the alternative, non-evil, Free Software, Google, and probably Launchpad, excels in what they doing, thus reducing the immediate need for alternatives altogether. (See: Launchpad, Google and why Microsoft is not the problem9)
It seems that Canonical with their Launchpad, just as Google, may be able to “control” information which is freely available to all, just by organizing a whole lot of it. And then, apparently, there is the problem that Launchpad is not free software, and thus hides the way in which it works.
Mark Shuttleworth responded to this blog entry, in the commentary section of Breitner's blog. Her is a part of his reply:
This is a well-written blog post, I can't fault your logic, and I understand where your concerns come from. I can only say that I hope, in the fullness of time, you'll be very happy with the way we handle Launchpad.
Over time, it will be open sourced. Right now we compete with Progeny and Red Hat and other companies, so we need to have a unique offering to do so effectively, and that's Launchpad. There are already libraries and tools in LP that we have open sourced on request, especially in Rosetta, the translation infrastructure. ... (Shuttleworth at Breitner's blog)
Another Debian Developer, Anthony Towns, commented on this remark by Shuttleworth:
... to me, the only logical conclusion to that is that LaunchPad will be free when Canonical/Ubuntu are the only players in the market, or when Canonical’s current business model fails and they switch to a different one. Which is fine: if you write some software from scratch, it’s your choice what you do with it; but unless you’re an underpants gnome or a slashdot commenter, the above doesn’t qualify as a “plan” to free LaunchPad. (Towns at indolence log)
While another active hacker, Dick Davies, commented:
So have I got this right - Google (and Launchpad, although I've no experience with that) are evil because they don't suck?
They're just Adding Value (tm) to Free stuff and choosing not to make themselves free. That's not evil, that's their choice, surely? (Dick Davies at Breitner's blog)
Now, I cannot judge from these entries who is right and who is wrong in this debate, or indeed if there is any real difference in the positions presented above. Because Shuttleworth is going a long way to give Breitner right in his analysis, and basically just legitimatises his plan with reference, in the latter part of his entry, to their common enemy:
.... One thing I can say, though, is that a web service (or even a remote app service) can never create the same level of pain that a proprietary OS can do. Having watched what Microsoft has done, I'm largely motivated by a desire to ensure that countries like South Africa never have to pay a tax like that again. (Shuttleworth at Breitner's blog)
As an anthropologist and an outsider I could be content with presenting the different positions with respect to Launchpad and the Ubuntu-Debian relationship, and abstain from taking side in the difference, or from any deeper understanding of the conflict. I am not quite content with such a view from a distance. Rather I want to dig a bit deeper, to see if I can get a better understanding of the stakes. Is Launchpad, and Rosetta in particular, “evil” or is it just “Adding Value (tm)”? I have not found any clear cut answer to this question, and I am not claiming that there is an easy, final or universal answer to it. However, by studying and taking part in the translation of KDE to Norwegian I have reached something like a tentative, partial and temporary “conclusion”. That conclusion, to put it very briefly, is that there is something ... (fishy?) about Launchpad. Now, here is the story that has led me to this ad hoc and provisional conclusion.
Rosetta and SVN – a Norwegian case
The translation of KDE into Norwegian is administered by a project called “Skolelinux”, also known as Debian-Edu. Notably, this administration consists of two things: Skolelinux maintains the SVN-repository of the language files, and they arrange a series of gatherings. There has been 35 gatherings since early 2002, which gives an average of seven a year. They have to a large degree been held during a weekend, often at schools that run Skolelinux, mostly in Norway but increasingly in Germany and France. At most of these gatherings several translators have met, and worked with translating the small strings of text from English to the two versions of written Norwegian. Skolelinux considers its SVN-repository of Norwegian KDE as the upstream site for these language files, and it has been generally accepted as such.
In May 2005 Mark Shuttleworth attended a Skolelinux gathering, held in Bergen, Norway. He presented the idea of Rosetta to the gathering. Petter Reinholdtsen asked Mark how to solve the problem of feeding translations done in Rosetta back upstream. Mark had no answer to this question. Not long after Rosetta version 1.0 was released. (And at that time accusations of the following kind already circulated: “Rosetta is evil and eats babies”.)
A year later I decided to try out Rosetta in some more detail, to try to see how it worked, and how it worked together with the Skolelinux upstream repository. So I did this little experiment:
4. August 2006 I translate 6 strings of K3B (of 40 untranslated) in Kubuntu 6.06, using Rosetta. I am invited to do the translation with this warning: “You are not an official translator for this file. You can still make suggestions, and your translations will be stored and reviewed for acceptance later by the designated translators”. Two months later I attend a Skolelinux gathering, and continue to translate k3b. This time I download the files from the SVN-repository of Skolelinux. The 40 untranslated strings present in Rosetta repository of Kubuntu Dapper Drake are still untranslated, including my six untranslated ones, but there are 42 untranslated strings in the Skolelinux repository10. At Rosetta my six translations are still awaiting an approval from a registered contributor. I translate the 42 untranslated stings, using Kbabel, an check the changes back into the repository. Three months later (8. January 2007) there are still 40 untranslated stings in Rosetta's repository of K3B (both in the 6.06 and the 6.10 release).
So, there was no communication between the repositories during this half-a-year, and my work in Rosetta was wasted. I was invited by Rosetta to do the translation, and I was not informed by any text or link that there existed another translation group and another repository – a repository, that is, that considers itself as “upstream” of this translation. I was invited to take part in the translation, and I wasted my time in the attempt.
Now, in the specific case of translating Ubuntu and Kubuntu into Norwegian the story is in practice less harmful than I have made it look like above. Norway is a small country, with only 4.5 million inhabitants. This means that the community of free software translators are also quite small, and that people tend to know each other. Among those who have started to translate Ubuntu into Norwegian there are several people who have also taken part in translating Skolelinux. Thus these two communities know about each other very well. (E.g.: The administrator of “Team Ubuntu Norwegian Translators”, Karianne Fog Heen, is married with Debian Developer Tollef Fog Heen, who took part in the early development of Skolelinux.) In an email exchange at the Email list of Skolelinux, Karianne Fog Heen agreed with people from Skolelinux to leave KDE to Skolelinux, to let the Ubuntu-team concentrate on GNOME, and to coordinate translations at common Email-lists.11 Of course, no-one wants to do “evil”, everyone knows that it is better for all if double work can be avoided, and the Ubuntu/GNOME and Skolelinux/KDE translators don't want anything but a set of consistent and effective translations of these free software desktops into Norwegian.12
Obviously, it would not take long before a Norwegian newbie – someone who did like me – to run into the Norwegian “Ubuntu translation page”, probably before getting to Rosetta, and read about the translation effort that also takes place with Skolelinux. Thus, a set of social relations and web pages outside of Rosetta would most certainly prevent an unwanted fork of the kind that I provoked in my little experiment. The point, however, is this: The web, in the small community of Norwegian translators, that prevents this forking exists outside Rosetta and Launchpad. Rosetta itself does nothing to prevent a fork. There is no systematic feedback from Rosetta to the upstream translation. No system or systematic attempt of information that prevents double work. No system for merging work done at different places, and for resolving conflicts if there is double work that cannot be merged automatically. Rosetta acts and exists as if it is independent of upstream.
Some other cases of Rosetta trouble
I have found recent traces of how the relative independence of Rosetta may cause problems to other translations.
Matthew East is concerned about the Dutch translation of GNOME, and recently wrote to the ubuntu-translators list:
> An interesting discussion on the #launchpad irc channel yesterday has been making me think about the question of quality assurance for Ubuntu translation teams. To put the question into context, this is how the discussion arose:
An upstream GNOME translator for the Dutch language mentioned that often there are complaints on their mailing list about the quality of translations of the GNOME desktop environment for Ubuntu. He says that these flame wars are particularly irritating given that the translations complained of are not made by GNOME translators at all, but are introduced by the Ubuntu translation team, overwriting the upstream translations. One of the Ubuntu translation team joined the conversation, and it became clear that there was very little QA going on to ensure that the members of the Dutch team are (a) good translators, and (b) familiar with the GNOME and other upstream translation guidelines. (Quoted by Carlos Perelló Marín, 31 Oct 2006, at http://www.mail-archive.com/ubuntu-translators@lists.ubuntu.com/msg00236.html)
Marín, who is involved in developing Rosetta, confirms that the problems raised by the Dutch translators are exactly the same in the Spanish translation work of Ubuntu. A German translator, Sebastian Heinlein, raises a similar problem to the launchpad-users list:
Hi, I am a member of the German translator team.
In the last week before release there was some noise about KDE upstream string that have been overwritten by some translators in Rosetta. To avoid this situation in the future I would like to make the following feature request.
Upstream strings are of a quite high value:
Firstly they are often of a higher quality compared to our Rosetta translations - regarding level of review and consistency.
Secondly upstream feels disrespected if we change their work without any communication. Currently we don't even see how much was changed in Rosetta. The German team has got about 250 members, so quality assurance is quite a hard business.
So I would like to see a feature in Rosetta, that would allow us to easily select translations that have been changed in Rosetta. A corresponding option could be added to the show combobox of the editor. Furthermore it would be nice to see the percentage of changed upstream strings in the progress bar or in a statistical table. (June 2. 2006, at https://lists.ubuntu.com/archives/launchpad-users/2006-June/000391.html)
In these two cases the upstream translation is overwritten, “forked” one may say, by people who may not even know that there is such a thing as an “upstream” to fork off from. Moreover, when as much 250 people take part in the translation of the Ubuntu-version of GNOME we have an indication of another social complexity than in the neat small Norwegian community. We may also note that Heinlein's posting to the launchpad-users-list was called “Request: How we could pay more respect to upstream translation”. It remains unanswered today, half a year later.
I want to postpone to the postscript the question of whether upstream stings are “of better quality” than Rosetta-translated strings – strings that allegedly lack “quality assurance”. First, and more importantly, I want to address this issue: None of the replies to the emails above present any solution to the challenge of feeding Rosetta-translations back upstream. The only solution addressed is the other way around: to make sure that Rosetta is more frequently updated with the most recent upstream. Thus, my conclusion, based on both my experience with the Norwegian translation, and by the recent challenges with the Dutch, Spanish and German translations of Ubuntu, is this: Rosetta works institutionally – systemically if your like – to produce another authority, another tradition and another bureaucratic rationality. That it, it works institutionally to “fork” translations. Rosetta, as a machine by itself, encourage forks. The way they are avoided, at least in the Norwegian case, is by making local “gentleman agreements” outside of Rosetta. In the Norwegian case; translation of KDE has not forked in spite of the possibility of forking that Rosetta enables.
It does seem to me to be one way – perhaps only one way – to make sure that Rosetta translations will not fork from upstream, and that is, quite simply, by turning Rosetta into upstream. I do not know if this solution is intended by Canonical Ltd, but I find it hard to believe that they have not considered this possibility, and this is the simple reason for my vague worry that “there is something ... (fishy?) about Launchpad”.
– * –
It seems like I am confirming Debian Developer Joachim Breitner's worry that Launchpad is equally imperialist in its ambitions as Microsoft and Google. We are back to the unanswered question, then, if this is “evil” or if it is merely “Adding Value (tm)”. I don't know, but Rosetta (as part of Launchpad) seems to be founded on an imperialist ambition. Is Ubuntu becoming big by becoming powerful, and is it becoming powerful (perhaps even attempting so) by becoming big? Is this, as an ambition, a power that implies the loss of power elsewhere, for example in the other sites that now administer upstream repositories? Does this ambition include “taking control”, as Breitner worries, in the same way as Google is “taking control” and as Microsoft took control? Is this power “evil” or is it merely “Adding Value (tm)”? And is it a problem if Debian, in the future, becomes a derivative of Ubuntu, rather than the other way around?
Ps: Why Rosetta is neither evil nor Adding Value (tm)
This section presents a practical and social argument for why Rosetta will not replace SVN-kind-of repositories as an upstream site for translations. Thus this may also be read as an advice to how Rosetta may be made better (given that I am able to make an argument that Canonical have not yet thought of).
Several comments on Rosetta starts by praising the way Rosetta makes translation easy, while at the same time warns that it must not lead to bad translations. I do however not think you can praise the ease of the present version of Rosetta while at the same time ask for better quality. I think in some way it is the very easiness that leads to bad translations, yes perhaps even less translations. I think the Norwegian Skolelinux (Debian-Edu) has been able to produce good quality translations of KDE into two minor small languages because it is using a tool (KBabel) that demands a minimum of initial effort for someone to get started, at least when we look at this tool in its social context. So, let us have a second look at how Skolelinux have worked to translate KDE into Norwegian.
First, we note that a few devoted people have done a lot of work. Gaute Hvoslef Kvalnes did single handedly an almost complete translation of an early version of KDE into New Norwegian, and Axel Boyer have put a lot of effort into making the Bokmal (“Dano-Norwegian”) version. Then a group of between 2 and 8 people have attended the 35 gatherings held the last 5 years. This has not been a stable group. A few of the central translators have attended almost all the gatherings, but many have been doing translation for a year or two, then to be replaced by new people. I have counted all together 28 people that have taken part in the translation work during those five years.13
There is no formal criteria and no formal process to go through in order to become a Skolelinux translator, and to be given write access to the repository. People have just attended a gathering, often by bringing their sleeping bag to some Norwegian school to spend the night on some hard madras in a classroom. In the days they have been translating, chatting and orienting each other. In the evenings they have had a good time at some bar or restaurant. People who translate software may not be very skilled in computer science, so even if setting up KBabel and learning the basic commands of the SVN-repository is easy, it can still be a threshold for some potential translators. However, attending a gathering significantly lower the threshold level. We all know why: Asking the experienced guy next to you how a program work, and having it demonstrated, is infinitely much easier than reading the handbook.
Thus the gatherings have worked as “initiation rituals” for new translators, and probably to new developers as well. Through such a weekend commitment and trustworthiness is both demonstrated and established. A sense of community and belonging is created, including a good reason to keep on translation when the weekend is over. The person – the new as well as the experienced translator, or at least many of them – who return home from such an event and keep on contributing, get a sense of making a contribution not only to an abstract “common good”, but also to a concrete group of people that he or she has come to know. That can be significant, and during the gatherings I have attended I have heard many testimonies of the usefulness of meetings in Real Life.
By comparison, the occasional and accidental user of Ubuntu who drop-in to Rosetta to translate a dozen or two of strings, is most likely to never see his or her translations again, and not to get the sense of belonging which is so important to produce commitment, and thus provide both quality and quantity in the translations.
In addition to this difference of commitment, working with SVN and KBabel – and often doing it at gatherings – enables another kind of quality assurance work than what Rosetta does, namely vertical coordination and quality insurance of strings. Here is an example: I started to translate KOrganizer during a gathering in 2005. By that time earlier versions of if had been partly translated by 9 different people, since 1998,14 and I found a very inconsistent translation. Notably the terms “event” “to-do” and “item” (the last one generic of the two first), as well as derivatives of them, where both mixed and variously translated. This was serious. These are the most central terms in KOrganizer, and using them inconsistently (for example on a function button and its help text) will create confusion, and most certainly anger, with new users. I decided to sort out the mess. That took the weekend. And it required me to search vertically through all the .pot-strings, for the English original terms (“vertically”, as opposed to “horizontally” within each string). There where 1193 strings in that version of KOrganizer. Paging manually through these strings, ten by ten, as in Rosetta, would have made the job impossible.
When a new version of KOrganizer is released, and some of the strings containing “event”, “to-do” and “item” needs re-translation, the translation may again start to loose consistency. If Rosetta is then used as intended by its technical design (that is, also by “drop-in”-translators), such inconsistency is almost unavoidable. KBabel is certainly not a guarantee for quality, but it does enable work on vertical consistency, and the fact that it takes a minimum of effort to learn how to use it need not be a problem. It can be part of an “initiation rite” that produce both community and commitment, and thus both quality and quantity in the translation work.
At the moment, then, Rosetta seems not to be Adding Value (tm). It is just adding mess. Neither is it evil. It is just bad.
Rosetta may of course improve technically, perhaps to match KBabel in functionality. And people may add social institutions to it, to produce the same kind of community and commitment as that of Skolelinux. (The Italian translation theme of Ubuntu has added such institutions, more akin to Debian-kind of formal commitment procedures than to the sociable gatherings of Skolelinux, see, again, this email:15) Thus the quality that Rosetta delivers may greatly improve. And I am in no doubt that it will improve. As I write this (January 25. 2007) there is a email-tread called “Ubuntu vs. Debian translations” going on , at the Ubuntu-translator list, and Canonical employee Carlos Perelló Marín just replied to someone:
I agree that coordination from Ubuntu with upstream not using Launchpad directly is not perfect, but as Sebastian already pointed, we are working hard to improve it every day. (Carlos Perelló Marín soon to be found at http://www.mail-archive.com/ubuntu-translators@lists.ubuntu.com/)
So, we may assume that Rosetta/Launchpad will really start to “Add Value (tm)” not only to Ubuntu. Will it, then, also become “evil”? Well, that question brings me back to my initial discussion, and to my indeterminate conclusion that “there is something ... about Launchpad”.
Does Launchpad in general and Rosetta in particular embody an ambition of becoming not only useful, but also powerful to its owner – by becoming upstream of more than just Ubuntu? “coordination from Ubuntu with upstream not using Launchpad directly is not perfect”, Marín write. So we better all start to use Launchpad as upstream? And will this potential power be a democratic problem? That is, it is easy to see that such an upstream position may become commercially powerful. But in a market that includes actors such as IBM, Novell, Sun and Red Hat one can hardly be worried about the commercial growth of Canonical. Debian Developer Gunnar Wolf blogs on Ubuntu:
“I'm not [...] blaming them for selling their principles – Of all the commercially-oriented Linux distributions, Ubuntu is clearly the one that stays closer to what I'd like. And it's not by mere chance that it derives and keeps in constant sync (at least until now) with Debian. ...” (See Are Debian people real Free Software zealots)16
So, I guess, we cannot worry about the potential commercial power of Canonical/Ubuntu. But can we worry about undemocratic power?
What do you think?
3He has also made some very unnecessary reductions of Free/Libre/Open-Source Software into socio-biological naivety, but that need not concerns here.
4A convention of truthfulness and trust does not assume that everything said has to be true. Rather, it is a condition for lies.
5Lewis, David 1983 [1975]: ‘Languages and Language’, in Lewis 1983, pp. 163–88 Philosophical Papers, volume I. Oxford: Oxford University Press
6The tread continues in June, see http://lists.debian.org/debian-devel/2005/06/.
10Apparently someone has translated two strings using Rosetta. I did not investigate which one.
11See the exchange that starts with this posting (in Norwegian): https://lister.ping.uio.no/pipermail/i18n-no/2005-May/003735.html
12Thus, the Ubuntu-translators use and recommend the language-guidelines of Skolelinux to avoid that similar technical terms get different translations in GNOME and KDE, something that would harm both. (See http://ubuntu.no/Oversettelse)
13The number is based on the list of people who have signed in to attend the gatherings, see http://developer.skolelinux.no/info/prosjektet/delprosjekt/
