Mere Code

Diverse Topics of General Interest to the Practicing Programmer

And then what?

By now, you know where Launchpad is at. You know what our top priorities are, you know the other important stuff that we’re still working on, you know the other bits and pieces we’ve got going. You might even know why.

What you might not know, and what this post hopes to tell you, is what we are thinking about right now. Humans are plan-making creatures, and product strategists perhaps more so than most. What follows is a brief description of the half-formed thoughts and plans that I have for Launchpad. (Also, have I mentioned the roadmap yet?)

Strategically speaking, there are two major approaches we can take to our work on Launchpad. The first is working on things that bring new users and new projects to us. This would mean finding something that we can provide that alternatives don’t and potential users want, or assuming that we already have such a thing, find the blockers that stop people from using Launchpad and remove them (the blockers, not the people).

For example, if we thought that open source developers wanted their hosting site, say, to be part of the semantic web, we could go and do that and be relatively confident that no one else will. That would be finding a competitive advantage.

Or, to take another example, we could say that our awesome bug tracker, our translation support and daily builds are heaps plenty good advantages, but people don’t use Launchpad because we only have full support for one VCS and we provide no place to host a project shop-front web site. That would mean adding Git, Subversion and Mercurial support, and adding some kind of wiki / webhosting. Personally, I find this much more appealing than semantic web shenanigans.

All of that’s one strategic approach: attract new users. There’s another major approach that we could take: make things better for our current users. All things considered, I think I want to take the second approach.

There’s so much we could do here, partly because Launchpad itself is so broad. Some key things stand out though.

First, there is a cluster of problems related to the way that people approach the website. Although we tout cross-project collaboration as one of our big things, we don’t make it particularly easy. We need to provide each user and each team with a view that shows them all of the things that are interesting to them across all of Launchpad. In fact, we probably need to give them two views: one that’s historical and chronological, and another that’s forward looking and more dashboard-like. In my head, I’ve been thinking of this as walls (ala Facebook) and dashboards.

If we dig into this, there’ll be other changes: better, fairer karma; more social interaction; better person, project and team pages; a “waiting for” section in the dashboard so you can see who to hassle; a better experience for new users; and probably death to the home page for users who’ve got accounts. Lots of goodness here.

Second, it’s becoming increasingly clear that blueprints are a good idea with a sub-standard implementation. Persuaded largely by Matthew Paul Thomas, I think that we should merge the blueprint tracker with the bug tracker to make a combined issue tracker. A lot of people get worried when I say this, because they really like blueprints and they understand that bugs and blueprints are actually two different things. Please don’t worry. There will almost certainly always be something in Launchpad like a blueprint or specification that is visibly different from a bug. However, I think we ought to change what lists they appear in, what statuses they have and many other things. The loss of distinctiveness will be more than made up for with an increase in capability.

Third, the way we search and the way we display results of searches needs to be revamped to be faster and more flexible. I want to see easy forms, a good search string mini-language, sexy URLs, searches that can be saved and shared.

There’s so much more that we could do, that we ought to do: make mailing lists rock; inline commenting on merge proposals; eliminate all of the silly “refresh this page” business that we still have; go to series and milestones with a sharp axe and a clear conscience; provide top-notch tools for QA teams; show way more cool stuff based on our data; make filing bugs upstream a complete no-brainer; clean up the terminology we use for naming things; provide an event sending interface for launchpadlib so that people don’t have to poll. I could go on for a very long time.

I call out the three things above – cross-project views, merging bugs and blueprints and better search – because I think they are things that will make Launchpad better for absolutely everyone who uses it. In particular, done right, good cross-project views turns a weakness into a strength. It takes the vast, daunting size of Launchpad and instead turns it into a huge realm of opportunity.

Now, none of this is fixed in concrete. There’s still plenty of time to discuss, plan out, change our minds and what not. But it’s what’s in my head right now.

That’s it. Right now, we’re working on privacy, performance, derived archives and desktop integration as our top priorities. We’re still plugging away at daily builds and making links between distributions and upstreams, and we’re working on a host of useful, important things. In the future, if my plans go as … planned, then we’ll have dashboards, activity walls, a combined issue tracker and excellent search.

What do you think?


sourcefrog on 2010-11-19 00:39
Great post!

I'd love to see a dashboard/notifications/wall type feature.
jml on 2010-11-16 17:52
Sense, it'll be a long time before the Canonical team works on proper Semantic stuff for Launchpad, but we'd be open to contributions. If you're interested, you might want to talk to the FusionForge guys about it.

If we do the issue tracker work, we'll definitely consider those cases. Some folk want to merge Answers in too. There are a lot of traps here, so we're going to have to be careful.

Better project roles is a longstanding issue and I agree it should be fixed. Thanks for the reminder.

We've been thinking a little bit recently about how to group projects together better on Launchpad, but I don't think we had put Ubuntu into the mix. (I'm reminded of mdz's product, platform, project post).

Alex, glad you like it :)
alexlauni on 2010-11-16 16:19
Am I dreaming? I agree 100% with the other comments with respect to vcs support. Bzr is pretty fast on top of git and svn already. Maybe a git-bzr bridge for users of git to talk to bzr repos, but keeping launchpad standardized on bzr is a good choice.

The dashboard and issue tracker things sound like a dream come true. Please steal me from DX to work on this ;)
Sense Hofstede on 2010-11-16 16:15
The first thing I think after reading this post is: great work, Launchpad Team! You've been doing an awesome job and if you look at where Launchpad came from, so much has been improved.

I have to admit that I am a bit of a semantic web fan, and I would love to see more semantics coming to Launchpad, but I understand there are more important things.

The things you mention in your post look great, and I agree with your plans to (somewhat) merge Blueprints and Bugs. Changing the name of the bug tracker to Issue Tracker would already be an improvement, because it would be more inclusive and describe better the possible uses of the tracker.

Because bug tracking is being used for more things than just plain software bugs. There is a Launchpad project that contains bug reports concerning community issues. Many LoCos, including mine, use Launchpad to manage tasks in the bug tracker. The most notable example, though, would be the One Hundred Paper Cuts project. It is used for reporting bugs that are in fact mostly usability issues. They require a bit more discussion and are not (always) exactly bugs. (More information about what constitutes a paper cut can be found at .)
It would be great if these other uses of the bug/issue tracker would be considered during the design of the (partial?) merge of the blueprint and bug trackers.

Another issue we see is the fact that the Ubuntu community and Canonical created several different projects on Launchpad to manage subprojects of the Ubuntu project. It is not possible to make a link between the 'ubuntu' distribution type project on Launchpad and its subprojects, like 'ubuntu-community', 'hundredpapercuts' and others. This has the consequence that the 'ubuntu' project on Launchpad only contains bugs and source and translations of the packages in the main repositories. But there is more to the project! It would be great if Launchpad could make the other aspects of the community more visible by allowing to link projects together.

I think that something else that would increase clarity and make the project pages on Launchpad more useful would be displaying roles on the front and section pages. Currently Launchpad already has some roles displayed (Driver, Maintainer, Bug Supervisor and such), but these are limited and do not cover the full community. Instead, or in addition to this, Launchpad could allow projects to create roles/functions (with a unique (per-project) slug for API authentication purposes) and assign teams or persons to it. This would give visitors (and, if the proper semantics would be used, also bots ;)) a way to find out who is responsible for what and contact them and. be an authoritative source for this kind of information.

Also, if you would do away with the set roles that give permissions, like Driver or Maintainer, you could create a much more flexible permission system by allowing project maintainers to assign capabilities to roles. Instead of the Bug Supervisor being shown at the bug tracker page, you would see the roles that have bug-related capabilities there. This would allow every project to complete customise its permissions.

Especially now Launchpad is used more and more as a provider for authentication and permissions such a system would increase Launchpad's value as a platform to offer this information.

These are some ideas that came up in me/I remembered. I hope you like them, or at least that they help you with getting (even more!) ideas for Launchpad's future.
jml on 2010-11-16 15:29
Hey Jelmer,

I fully agree. If Launchpad ever provided support for other VCS clients, it would have to be in such a way that you could still use Bazaar regardless of the project.

Supporting VCS-specific protocols on top of Bazaar repos seems like the ideal way of doing that. But you would certainly know better than I :)

jelmer on 2010-11-16 15:20
To me, Launchpad provides a structured view of the very diverse free software world, with a flat namespace. No matter what the upstream project uses Launchpad can provide me the source code, the bugs, the Ubuntu packages and the translations for that project and allow me to use the same tools I use for all other projects too. This is a unique thing about Launchpad, it's what makes it so great for people who hack on multiple projects (like packagers).

Support for other version control systems seems like a great thing to support. I'm biased here, but rather than allowing plain hosting of every possible DVCS as e.g. SourceForge provides it would be nice if Launchpad could maintain its tight integration. Perhaps I'm biased here, but I'd like to see Launchpad e.g. support Subversion's mod_dav protocol on top of Bazaar repositories, much like GitHub does on top of Git repositories (

Having a proper dashboard would be a really great addition I think.