The extent of debate and acrimony that broke out within the project last year over the decision to adopt systemd as the default init system for the next release, Jessie, would have taxed the patience of even the most suave diplomat.
Yet Nussbaum (seen above addressing the annual Debconf last year) has come through the whole thing unscathed and, as he gets set to vacate the post — the new leader, to be elected over the first fortnight of April, will take over on April 17 — can even see some positives in the whole process.
"In retrospect, I do not really think that this could have been handled much better; it is just the kind of decision that is hard to make for organisations like Debian that value making correct and well-informed technical decisions," Nussbaum told iTWire in an interview.
iTWire: When we spoke after you were elected in 2013, you were not willing to commit to a second term. You have now almost completed a two-year term. At what point of your first term did you decide to run for a second time? And why are you not running for a third time – does it mean that all you set out to do has been achieved?
Lucas Nussbaum: Doing a second term is a decision that must be carefully thought out. Being the DPL is an important position for Debian, and it's important to
respect it by making sure that one will be able to cope with all the stress before committing to a second term. I actually decided during FOSDEM 2014: seeing how great the Debian community is, and how much everybody cares about Debian and highly values Debian, was the decisive factor. Being the DPL also requires one to learn about a lot of things, and it sounded fair to do a second term so that what I learned during the first term could be applied to help Debian further during the second.
The biggest issue in the Debian community during the past two years has been the acrimony over the adoption of systemd. Now that things have settled down, what lessons have you drawn from this entire episode?
The init system debate has put a lot of pressure and stress on Debian, as the decision was not only technical, but also political: it was not only about choosing the best init system at a specific point of time, but also a question about how to move forward for the coming years. The fact that it was also a situation where no package maintainer was clearly responsible for making the decision was also quite unique in the history of Debian. In retrospect, I do not really think that this could have been handled much better: it is just the kind of decision that is hard to make for organisations like Debian that value making correct and well-informed technical decisions.
Have all the issues with regard to systemd been sorted out? If any remain, how are they going to be handled?
systemd is the default init system in Debian Jessie, and I'm quite sure that people who tried it are now convinced that we were able to handle that difficult transition successfully. But there is still a lot of work to do, in all distributions, to fully benefit from all the features that systemd brings (in terms of isolation, resources control, etc). systemd is also a moving target, with new features being added, and additional decisions will be needed about how Debian will make use of them.
Prior to being elected, you stated that you saw Debian as losing momentum, positive energy and slowing down. Have you done anything to reverse these things?
Well, one positive outcome of the init system debate is that it proved how much everyone cared about Debian. The fact that Canonical decided to drop upstart just days after the decision was made in Debian showed how much Debian's derivative distributions value Debian as a solid technical foundation for their own projects. So, in a rather strange move, this whole saga kind of put Debian back at the centre of the ecosystem.
What do you rate as the major achievement of your two years in office?
That's a difficult question. The DPL is often involved behind the curtain, as a facilitator, but is rarely on the front line. But there was two occasions where I am particularly happy to have played a major role.
The first one is the how-can-i-help package. Debian has long had problems recruiting new contributors: because Debian works very well as a distribution, people tend to think that we don't need their help, and don't know where to find opportunities to contribute. The how-can-ihelp package simply lists such opportunities for locally-installed packages. It proved quite efficient at making people discover that they could contribute to packages they rely on.
The second one is the key packages idea. Debian provides more than 20,000 packages. Some of them are central packages that are used on most systems, but there's also a number of niche packages that are only relevant for a few users. In the context of release management, it is important to understand which packages are the central ones, because those are the ones where the more energy should be focused. So the idea was to automatically generate such a list of "key" packages, using an objective metric (the number of installations according to Debian's popularity contest service). It was then easy to agree that severely-broken non-key packages could just be removed, rather than worked on. I am convinced that such semi-automated ways to address QA at large scale will become more and more important for Debian.
And what is the one thing that you wish you could have done something about, but couldn't?
A long-running problem in Debian is that several of our core teams are severely under-staffed. This is hard to fix, because several of those core teams require rather specific skills, and because joining those core teams is usually a step one makes after years of contribution to Debian: we need contributors to "grow" until they are ready to join one of those core teams (and they sometimes leave the project before that point). Still, I believe that the situation improved compared to a few years ago, with most core teams having gained sufficient new members to keep up with their workloads.
Are you happy with the rate at which new developers are coming onboard the Debian project?
Debian could always use more contributors, but I think that the situation has improved over the years. This is also probably due to a culture change, Debian being generally a more welcoming project for new contributors (improved documentation, mentoring programmes, etc.).
What about the number of women joining the project? Have you done anything about this or is there any ongoing initiative to attract more women into the project?
Debian is already a welcoming project for minorities, but it is very important to continue to work on increasing diversity among contributors. Debian has been involved in the Outreach Program for Women (now Outreachy) for a number of years now, using a mix of targeted fund-raising campaigns and Debian funds. We also have a number of other mentoring programs, some of them specifically focused on increasing diversity.
One of the other things you mentioned pre-election in 2013 was about establishing a project observatory to detect problems before they become full-blown crises. Did you make any headway on this during the last two years?
Developers tend to to complain to the DPL about problems they encounter, so the DPL is already made aware of most of the rising problems. I also have a collection of links to various status pages and graphs, that I review on a regular basis, though. But this is not formalised in a central place.
Do you already know what you are going to do after the end of your term?
There are two things I would like to work on.
The first one is a cross-distro dashboard in order to improve collaboration between distributions on packages maintenance. Debian is already quite successful at organising collaboration with its derivatives, but there's not much collaboration happening with those outside of the Debian world. So the idea would be to provide a unique place where package maintainers from various distros could learn about who is doing the same work in other distros, how specific problems are solved, what bugs and patches are there, etc.
The second one is automated packaging. The packaging landscape has changed quite a lot over the recent years, with the emergence of many language-specific packaging tools (rubygems, npm, pear, Pypi, etc.). Debian teams have developed a number of tools to create Debian packages from those third-party packaging formats, and I wonder how much further we could go with improving such tools. That could be a way to enable system administrators to install software from various sources (Debian, third-party repositories), and manage them all as Debian packages, rather than have a mix of Debian packages, gems, etc.
Anything else you would like to add?
Not really. I would like to thank you for following Debian over all those years, and I will be looking forward to your first interview with my successor!