home of the madduck/ blog/
How launchpad got it wrong

A common rant against Launchpad is that it's closed: the code is proprietary, and Canonical doesn't give raw access to the data they collect via the interface. Anyway, other people have taken up this issue, and it's not the point of this post to do so.

I've heard two argument why Launchpad is closed: first, it's a test bed for a product, which Canonical hopes to market to commercial entities to manage their own release cycles. And second: it's purposely cross-project and tries to integrate and link between them. Thus, lots of instances of Launchpad would defeat the point.

I'll address these points in turn, starting from the back:

While I won't deny a "pre-trend" towards (back to) "mainframe-like" computing, with Google, Amazon, and others providing rent-a-computer-cycle services. In addition, environmental concerns cast clouds over the 400W heating appliance under your desk, which happens to run your word processor and browser when it doesn't lose track of its countless spare cycles. Yet, I maintain that centralised services, such as Launchpad are a thing of the past.

If you ask me, Launchpad got it wrong, even though it's light years further than its predecessors. It features pleasant graphics and obviously has had lots of smart thinking and experience shoved into it, but it's still centralised. It might be a business case, but it's not what the world needs.

We've seen massive growth of decentralised approaches to classic services, from file sharing to version control, from number crunching to simple web browsing, and yet, there's Launchpad, single point of entry (and failure) to the world of data surrounding Free software (at least if you follow their vision).

What we need is something as slick as Launchpad, and thousands of instances thereof, which all peer with each other, automatically. The information would automatically be mirrored wherever it's referenced, so the entire cloud would be highly-available and failure-proof.

Obviously, this wouldn't render itself well to the (traditional) software business model Canonical seems to strive for, so they're unlikely to go down this route.

But we could. It would be a non-competitor.

Update: thanks for the copious feedback I've received. Among them was a comment by Elliot Murphy, who speaks of "us" and thus leads me to believe that he's part of the Launchpad team:

We're definitely listening, and we still have lots more improvements we want to make. Our goal is collaboration, not centralization: thats why we build bazaar, are working busily on doing two-way integration with other bug tracker systems, and are building the best API we can. Our goal in the team is to make it trivially easy for you to get all the data that you put into launchpad back out through the API, data portability is very important. There is no big evil business model, but it would be socially irresponsible if we did not work toward making launchpad self-sustaining. It has been a long road, but the launchpad team is steadily working toward a distributed model, one step at a time.

While it's definitely nice to hear that data portability is a concern to them, I don't see Debian using Launchpad without the ability to run it on our own servers. I'm definitely curious to hear more about the distributed model the team is pursuing.

I certainly don't have a problem with self-sustainability, but in the Free software world, I do wonder what that is supposed to achieve. Release early, release often, anyone?

Update: Philip Newborough took up the issue and has received a number of noteworthy replies. It made me very happy that he sees my post as "a rant about Launchpad which is not lambasting Canonical for their proprietary Launchpad software;" I wasn't aiming for any lambasting.

NP: Nine Inch Nails: Further Down the Spiral