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.
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.