NB This post should never have showed up in the blog feed; I never published it because my comment actually did make it onto the OA blog. A bug made it appear in the feed. Sorry for the confusion.

Slight digression from the usual photography-related content of this blog. Anyone not interested in Launchpad or my work as a developer should look away nowish. We’ll resume our usual programming shortly.

For those interested, please take a look below the fold.

The Oxford Archaeology blog has a post today ranting (their words) about Launchpad’s lack of integration with Open Street Map. I’ve tried to reply in a comment on their blog, but since my response is quite long, it has been classified as spam and will need to be dug out of their moderation queue. In the interests of open discussion, I’m posting my response here, too:

Disclosure: I am a Canonical-employed Launchpad developer, working primarily on the bug tracker.

Disclosure the second: I’m aware that you’re ranting a bit here, but I’m going to say this anyway.

One thing that you don’t mention here is where you think the resources to tackle this change should come from. Now, I don’t know the ins-and-outs of Launchpad’s Google Maps integration. What I do know was that developing it was a complex process; at the time it was written Google Maps was the only provider of the requisite mapping data that provided the features we needed.

The paid Launchpad development team is very, very busy. The part of that team that works on the areas that mapping touches is small and very, very, very busy. As Curtis Hovey of the LP Registry Team points out in a comment on the aforementioned bug:

The Registry team had a list of prioritised work, something must be dropped to undertake this issue. The Google Maps code was handed to us under the assumption it would be simple to integrate. It was not. We dedicated a developer to this issue for 1.5 releases. The cost was that team and project pages were not updated to the Launchpad 2.0 layout, nor have they been, because more urgent work was undertaken. There are new features and broken features that are more urgent then this issue–one of changing the implementation without adding for fixing Launchpad behaviour.

If someone from the community provided a drop-in replacement, I will review the code on my own time and work to get it merged into the tree. The behaviour is largely on the page, some deft updates to launchpad.js to support OSM/OpenLayer and GMap is the principle effort. Note that Launchpad is switching to YUI, and the script must be compatible. I will have to provide the code that toggle between GMap and the alternate maps code.

Now, yes, that comment was written over a year ago, but the amount of work that the registry team has to do hasn’t diminished, and nor has the cost of switching from one mapping provider to another got cheaper.

On a final note, if you look at the bug you’ll notice that it isn’t closed and hasn’t been for over a year. It’s has a status of Triaged and a priority of Low, which accurately reflects where this bug ranks on the registry team’s list of things to do at the moment.

I appreciate that it’s vexing to see proprietary solutions being used in open source software, but I’d ask that you appreciate that the decision to use those solutions in the first place was motivated by pragmatic principles. If the cost of switching over to OSM were cheaper I’ve no doubt that we’d have either done it by now or would have reviewed a set of community-submitted branches that made the switch. Either way, the Launchpad team is not being nearly as stubborn on this as you make out in your post.