Thierry Carrez: Getting more developers interested in Ubuntu

Answering Jono’s question on how to get more developers interested in participating to Ubuntu. I think the key issue is to lower the barrier of entry.

Let’s look at the process of bug fixing in the “current stable” release for example. Consider someone that knows how to fix the issue in the upstream code. That person still needs to:

1. Figure out if the fix should go upstream, in Debian or in Ubuntu (and potentially get flamed in the process)
2. Figure out that the SRU process applies in that specific scenario
3. Understand patchsystems enough to translate his fix into Debian packaging
4. Figure out our changelog and version numbers conventions
5. Submit a branch merge proposal or a debdiff and a SRU report
6. Wait to get sponsoring
7. Watch the fix climb the ladder of -proposed and -updates

That’s expecting a lot from someone that already knows how to fix the bug. Ideally, a drive-by contributor should just have to:

1. Propose the fix (as a patch to upstream code), which is automatically translated into the right package update proposal, and built
2. Wait to get review
3. Watch the fix climb the ladder of -proposed and -updates

We are not nearly there yet, but I think that’s what we should aim for. Abstract the complexity of Debian packaging and of our processes away from the developer. And evolve the tools so that the review is a fast and painless process. The reviewer should not have to build the package himself, the review process should prepare that for him. Only the proposals that build would be proposed for review. The reviewer would review the patch, and use the pre-built binary packages for quick testing.

You’ll tell me this is all the ultimate goal of the DistributedDevelopment initiative. Well, we need to move faster in that direction, affect more resources to it. Otherwise you can do all the DeveloperWeek sessions you want, you’ll always get less developers than you could.

I remember seeing a presentation from Simon Wilkinson at UKUUG Spring Conference 2010, about how moving to an integrated git+Gerrit workflow allowed OpenAFS to double its number of developers. I think if we successfully abstract the complexity of our historic processes out of the prospective contributor, and make the reviewer job easier, we can achieve the same.