Why Launchpad isn’t taking off just yet

Lars Risan, a Norwegian anthropologist leading a group of researchers at the university of Oslo studying “The Political Economy of Free/Open Software” recently put up an interesting blog post about the Launchpad technical infrastructure’s effects on the relationship between Ubuntu and various upstreams, both with regards to Debian, but also with regards to the translation work done through Rosetta as opposed to directly in the upstream.

Risan raises some relevant issues that have received much discussion within the Free Software communities around Ubuntu, namely: What is Canonical’s intended purpose with Launchpad, and why isn’t it Free Software?

He finds that the main lines of argument revolves around the fact that Launchpad is Canonical’s flagship investment, and that the promises of freeing the Launchpad source code will only be kept once Canonical has secured the market for Open Source infrastructure, and that Canonical much like Google seeks to trade in free web services to profit from the unhindered access to the data – the translations, source code, bug reports, specifications and support tickets handled by the system.

While Mark Shuttleworth’s reply to these claims emphasizes that he has no problem if people prefer to use something like Pootle instead. And he concludes:

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.

And that’s fine. Like Google, Launchpad is intended to provide a service which you can choose to use or not. But as Risan points out, the service still isn’t very good. In his case study of how Rosetta works, he concludes:

At the moment, then, Rosetta seems not to be Adding Value ™. It is just adding mess. Neither is it evil. It is just bad.

As Risan does well to show in his paper, it is not a matter of whether Rosetta technically offers the necessary capabilities, but rather whether the infrastructure can work with the various upstreams – in Risan’s case the Norwegian translators of KDE – to make sure the latest translations are available in distributions like Ubuntu which depend on Launchpad for its translations.

The problem is that with Risan’s translations, Rosetta has simply supplanted the Norwegian KDE translators as the translation upstream, thus actually segregating the community rather than uniting it. And the reason for this may exactly be the Norwegian KDE translators’ hesitancy to drop Kbabel and other tools for Launchpad and Rosetta – a platform which many Free Software developers still do not entirely trust, nor will be willing to use until it becomes Free Software itself, or at least until it becomes so good that it would be too much work to build an alternative – like Google.

In this way, the adoption of Launchpad continues to be slow, not because of any bad intent from its architects or lack of interest from its potential users, but because it has been built without consideration for the social connections within and between Free Software projects.

Indeed, Launchpad is often described as seeking to “automate social connections between projects” so that patches and data can be exchanged as smoothly as possible with a minimum inter-community flame-wars (this fits quite well with Ubuntu’s relationship to Debian, where a number of developers continue – rightly or wrongly – to be unhappy with the patches that Ubuntu send back upstream).

When the project started, the Launchpad developers mapped out all the software repositories of the Free Software world and linked them together, but they did not map out the flow of information between these repositories or how its active inhabitants collaborate. Thus Launchpad does not reflect how the upstreams work, limiting their willingness to adopt it, and since they can’t customize it to fit their needs as they would otherwise do – the source code is still unavailable, after all – they simply stay away.

Unlike Google – whose services generally are so easy to use that they require little or no customization, Canonical’s Launchpad is a intricate behemoth of details. Even core Ubuntu developers who use it everyday do get lost in the system from time to time. It cannot be optimized for a single use case, since Free Software projects, though they appear much alike, have subtly and vastly different ways of collaborating – both due to community structures and dynamics, but mostly because of the many different tools they use.

Having the data is not enough. Understanding and incorporating the work flow of the upstreams is also necessary. And nobody will be able to do that better than the upstreams themselves.

This constant negotiation between the technical and the social is the main theme of my thesis, and though I can’t delve into the entirety of Launchpad, I do hope to elaborate further on some of these ideas about the role of technical infrastructure in Free Software projects.


Add Yours →

You know, I also do not agree with the way LP is handled…

It is being more and more hard linked to Ubuntu, which makes it impossible for users to use free alternatives.

Furthermore, it really really shoots the good upstream translations and nothing seems to be done yet. For example, Rosetta still does not have a search.

I think that the best for LP would be to OpenSource it and to make it possible to Debian & Co to set up their own LP installations..

One Master (which can be replaced; best in hands of a foundation) manages the communication of the LP installations.

Isn’t the businnes model of Canonical offering commercial support sufficient? I mean, there are lots of companies making money like that, the way LP is does not make Canonical symphatic to me.

Hi Andreas,

Thanks for your interesting comment. This sentence struck me and made me think further:

When the project started, the Launchpad developers mapped out all the software repositories of the Free Software world and linked them together, but they did not map out the flow of information between these repositories or how its active inhabitants collaborate. Thus Launchpad does not reflect how the upstreams work …

This makes me think that perhaps Ubuntu is suffering from the same kind of grandiose techno-optimism as Debian. Debian is a great collective and collaborative project, to the best of many people, to the best of liberty. And I like it for that. But it also has an ambition of being a “universal operating system”, that is to be running on virtually every platform, and to cover all kind of uses and users. In various ways Debian-people strive to make it possible to split Debian into “derivatives” that are locally adapted. This sound good, but may also be turned around: We might say that Debian attempts to make various local systems conform to one grand master, one Grand plan, one “FTP-master”. Thus, Debian has the potential of becoming “totalitarian”. I guess we may say that this Grand Plan failed when Debian strove too long to release Sarge. Ubuntu forked off from Debian during the period of “waiting for Sarge”. And it forked off the Grand plan, and into a more modest plan. To make Debian-technology available to the more narrowly imagined and average “end user”.

But then it seems like Ubuntu has its own Grand Plan (Launchpad and Rosetta), suffering from the same techno-optimism and lack of social sensibility. It, indeed, if is the case that the ambitions of Launchpad/Rosetta are as Grand as they might seem to be …


Hi Lars,

While I find your point on techno-optimism quite valid, since that is surely one of the driving factors behind Launchpad, I do not find that Debian and Launchpad cannot be compared quite as easily. Debian’s success grounded exactly in the width of ambition that have allowed so many developers to rally around a single cause. The question is whether Debian would have achieved so much as a project without exactly this scope.

Launchpad on the other hand is a proprietary project the success of which so far has been closely linked to Ubuntu. While Ubuntu succeeds by narrowing the focus of Debian, Launchpad fails by not allowing everybody participate in its construction.

The ambition of Launchpad does not match the number of developers allowed to work on it. Surely, Launchpad would meet a different set of issues if it was to be opened up, such as the lack of direction that haunts Debian, but at least the number of developers with their cumulative itches to be scratched would have better chance of making it achieve that techno-optimistic dream.

Yes, I do agree with you. The differences you point out are important. I don’t ever think that Debian will become ??totalitarian?. It is to messy, to heterogeneous, to much ruled and shaped by a multitude of voices for that to happen. But the slogan is still ??Debian — The Universal Operating (www.debian.org) System? It does of course not lead to totalitarianism, it may only lead to long discussions. When Ian Murdock (http://ianmurdock.com/?p=153) begs Mark Shuttleworth not to introduce ??RPM-hell? in the Debian world of packages, he is tremendously optimistic, a ??techno-optimist? if you like.

I share his hope, but I fear that the only way that we may avoid this ??hell? is by totalitarian control, something akin to the control that proprietary companies can enforce. Perhaps, and I am really speculating now, but perhaps the only way to avoid RPM-hell in the debian world is if Debian becomes a (??universal?) derivative of something like Ubuntu, because, perhaps, it takes something like a proprietary ??Launchpad? to achieve that kind of control. The kind of ??Launchpad? that must be in place to do that may just be feared by Breitner and other Debian people, and it might only be a ??wet dream? of Canonical, never to ??add global value ™? the way that Google does.

And I don’t want to be right about this. Perhaps Ian Murdock hope of leaving the space of Debian packages un-forked will come through as the hacking part of humanity (including Canonical) shows its ability to work for the common good. And that is just beautiful.

I think Debian is a tremendously interesting case when it comes to understand human cooperation. Because, not unlike what Eric Raymond pointed out long ago, there is the ??Bazaar? of Debian, the heterogeneity of the network. And there is the ??Cathedral? of it: The ability to structure the large amount of work to the degree that you can slip a Debian DVD into a Windows-computer, and turn it into a Debian computer in less than an hour. How far can you take this mix of ??cathedral? and ??bazaar?? How much bazaar can you have before it forks, and how much central control can or must you enforce upon the network? How can you build a system that enables the ??beauty of (hacking) mankind? to simply do good, and/or how much must you invoke something like the (partly fantasy figures) of the Ubuntu-Launchpad and the Debian-Cabal?

This question centralization against decentralization is good way to describe a central tension in the Free Software communities’ dream of “global domination.”

I see two ways to deal with it (off the top of my head):

One is, as Canonical proposes, to let companies define the supported Free Software that the end user might need, and guarantee that it is available and just work. Thus creating small pools of centralization being synchronized on a regular basis with the larger decentralized pool of shared knowledge within the bazaar.

The other is, taking a cue from an earlier comparison of the Free Software communities to the scientific communities, to work towards commonly agreed upon open standards of infrastructure so that at least the exchange of knowledge and code will be possible on equal terms. I think that Debian is quite well poised to become a sort of “research library of Free Software” – collecting the “monographs” and “articles” of code, cataloging and organizing them for easy and open access.

To some extent, I guess this is what Mark Shuttleworth means when he says that “Debian is the Tibetan Plateau of the free software landscape” upon which Ubuntu is built.

Which means that the two ways I suggested aren’t mutually exclusive – at least in theory.

Hi again,

It is really nice to keep this conversation going. I, at least learn something here.

So, yes, science is a nice model of what Debian might be, and Canonical might just be like some biotechnology-firm that skims the cream of some “basic” science.

Well, my gut feeling is this: the Mertonian or Popperian norms of an open ended, universal and critical science are important to hold on to, just as the norms of Free Software are important. But then, in practice, since might not be very unified and universal. Science seems to be fragmented in practice, at least that is what many people argue (like in the book “The disunity of science”). There is not one biology, but many. And sometimes some commercial interests may become hegemonic in some parts of the sciences, as when, in the 90ties, Craig Venter took a lead in the mapping of the human genome. Many biologists had very good arguments against the promises of that project.

Well, the beauty of that story is that the lack of immediate useful results from the mapping of the genome gave the critics right, leading large parts of the biological sciences into new directions, now governed by more basic questions …

I’m off topic, but I guess the point is this: Science is (also) extremely disunified (there are 22.000 different medical journals in the world. “Medicine” (in singular) is known by no-one). And ??science? can live with this relative disunity. Can Debian? There is at least one difference: ??Debian? as a whole must occasionally come together to produce a release. A release which is unified enough for a computer to work. Fuzziness is simulated by computers, because they work only by strictly separated ones and zeroes. The knowledge of Debian, packed together as a release is pretty much a unity. A unity of which a large degree of coherence is required. The knowledge of science may be unified in an encyclopaedia, but, metaphorically, the discrepancies and glitches of that body of knowledge is so enormous, so ??buggy?, that it would make any computer halt very early in the boot.

The rigidity of computers as digital machines then combines with two other factors: The plasticity of them, as programmable, and the connectivity of them,on the Internet. Taken together these factors , I think, point to the enormous potential for lock in effects and network externalities. Strict communication standards are needed, and have been won, for example when MS won the text editor format (Word.doc).

Well, its getting late, and i am about to write another paper. Debian people know more about lock in, and democratic struggles to gain control of the standards, than I do. But I think the world of communication standards will never become the same again, after the advent of Internet ?? the programmable Net. Because communication standards can be sent across the same lines as the content. So I fear that the democratic disunity of Science metaphorically transferred to the software world will mean the loss og communication standards, or ??RPM-hell?.

The RPM-hell has so far not proven to be as bad as feared. Mostly because Ubuntu merges with Debian every six months, thus resetting the difference.

The lack of binary compatibility between Debian and Ubuntu packages is of course a problem – especially for third party software vendors. But as yet that is more of a problem for Ubuntu than for Debian.

It is interesting to see that these infrastructural problems are sought solved not through politics, but rather through technical innovation such as the SMART package manager.

Thanks for the discussion. I look forward to hearing more about your ideas on where Free Software is headed. 🙂

Leave a Reply