Nussbaum (pictured above), an assistant professor of computer science from Universite de Lorraine, was elected as leader in April, defeating two other candidates. He has been involved with Debian since 2005.

"Generally, I have the impression that Debian has been categorized as the very solid foundation on which to build derivative distributions," he told iTWire in an interview.

"Many very cool things happen in the Debian ecosystem, but very often outside the Debian project itself, through derivatives. Being a solid basis for many innovative derivative distributions is great, but there's no reason why innovation shouldn't happen in Debian directly, and benefit everybody."

Nussbaum has had a busy time since being elected; the project made its stable release of version 7.0 on May 4 and he has had to cope with a number of other things, both personal and professional, as well

Despite this, he was gracious enough to consent to what has become a regular feature in iTWire - a detailed interview with a new Debian leader. His detailed responses to iTWire's questions follow:

Congratulations on being elected DPL. You seem to have taken a long time to stand for election, given that you have been quite prominent in the community for some time. Why?

It is of course a great honour to have been elected and to serve as Debian Project Leader. But it is also a huge amount of work. Stefano Zacchiroli did a fantastic job for the last three years (I can assure you that you only really realise how fantastic it was when you have to be next DPL :P). So the motivation to stand against him was obviously quite low for me.

However, I have been interested in DPL-ish tasks for a long time, and volunteered when Stefano started the "DPL helpers" initiative, whose goal is to create a team able to share the workload generally associated with the DPL. The hope of getting the DPL's own workload down to a more reasonable level by sharing it with a team was also a key factor for running!

On a more personal level, I was also reaching a point when I was starting to feel bored with the things I was doing inside Debian, and needed to change focus to regain motivation. That's one great thing with Debian (and other very large free software projects, probably): there are many, very different interesting things to do, so it's possible to change roles when you feel bored with your current tasks, but still stay in the same community.

You have stated that you see Debian as losing momentum, positive energy and slowing down. What has led you to these conclusions?

Ah, that's a very good question. I don't think that we have scientific evidence of that (though it would be interesting to have sufficient data to be able to produce such evidence - there's a GSOC project that aims at building a Debian metrics portal).

Generally, I have the impression that Debian has been categorised as the very solid foundation on which to build derivative distributions. Many very cool things happen in the Debian ecosystem, but very often outside the Debian project itself, through derivatives. Being a solid basis for many innovative derivative distributions is great, but there's no reason why innovation shouldn't happen in Debian directly, and benefit everybody.

You describe Debian as being a packages supermarket for others. How can this image be reversed?

There are two great ways to use Debian, and we should get better at communicating this.

First, we provide rock-solid stable releases every ~24 months.

But we also provide "Debian testing", which is badly under-advertised. This development branch is used by many people (including myself) as a very nice and reliable "rolling" distribution. Of course, it might not be suitable for your mission-critical server, but it's just perfect if you like to follow new upstream releases on your laptop. Using Debian testing is also a way to contribute to Free Software, as testing software and reporting bugs improves the quality of free software in general (and of the next Debian stable release specifically).

Two days after you were elected (April 19 in Australia) one could see that people were still obsessed with the Debian release date. Would you agree that this date has little meaning for regular Debian users when such a fine stream of development as testing already exists?

I think that stable releases and Debian "testing" are both very useful, for different use cases. As Free Software developers, we tend to be obsessed with using recent versions of software, but it's important to remember that there are a lot of people who rely on our stable releases. We should also explore how we could extend the length of time we support our stable releases (Debian stable releases are currently supported for about three years). A stable, well-supported release is essential for the smooth running of thousands of mission critical systems.

You have highlighted the point that there is little publicity about the testing stream which is perfectly fine for everyday users. Why do you think that this happened? Is it just apathy? Or is there something deeper than this?

Debian is great at making technical changes. However, in this case, no technical change is needed: Debian testing is already very good for everyday users.

Unfortunately, there are two widespread myths about Debian testing:

"It breaks often." I cannot remember the last time my use of testing had a significant impact on my ability to work, and the only precaution I take is that I don't upgrade my system a few minutes before giving an important presentation. Sure, there are occasional problems, but they are very easy to fix in general (by going back to the previous version of packages, using your local apt cache or http://snapshot.debian.org/, that provides all old  versions of packages). And fixing those problems are also a great opportunity to learn more about Debian.

- "There's no security support." As a member of our security team described during the election discussions, we have an active security team that watches over the security of all our releases, from old stable to unstable.

One often discussed issue about Debian testing is that its original and main purpose is still to prepare Debian stable releases, and as such, it needs to be frozen before releases. But long freezes create other problems, and that's something that we should try to address instead of adding work-arounds. Also, it should be noted that many maintainers provide new upstream releases during the freeze using the "experimental" branch.

Debian has some of the best internal procedures and approaches to its users - for example, it is one of the few FOSS projects that makes a clean breast of things when anything goes wrong. Yet few people know of these things. Do you agree that Debian does a pretty poor job when it comes to self-promotion?

I don't really agree. Things can always be improved, but I think that we are doing pretty well, with e.g. the weekly Debian Project News, and the new official Debian blog.

You mention transparency. That is indeed a great feature of Debian, codified in our Social Contract as "We will not hide problems". This "no-bullshit" approach is something that is very important for us. While it can be seen in the way issues are discussed, it is also interesting to observe how technology reviews and design of technical solutions happen on Debian mailing lists. For example, the debian-devel@ list is often perceived as being very high traffic, which is true, but it is also a place where a lot of experts share their knowledge in high-quality discussions.

You've mentioned that important values that the Debian project fights for are often neglected by its derivatives. Can you cite some examples?  

I see Debian as a two-sided project. On one side, there's a technical project aiming at building an Operating System, and doing that rather successfully. And one the other side, there's a political project, that puts Free Software very high on its priority list. This duality is quite unique: there are many successful technical projects that tend to not care very much about the political aspects, as well as some political projects that prefer to ignore the reality checks that we do on a regular basis.

You've talked about establishing a project observatory to detect problems before they become full-blown crises. How would this work?

Some problems that happen in Debian are definitely recurring ones, or at least follow a similar pattern. For example, many of our internal process rely on queues, and it's easy to detect when queues start to grow past a certain point.

A recurring cause of problems in a volunteer project like Debian is a sudden lack of time for people who hold key roles in the project. It's therefore important to make sure that all teams are sufficiently staffed to cope with one or two members being temporarily too busy.

Finally, I think that the DPL helpers team could also contribute to helping detect problems earlier, by providing more eyes to look at various parts of the project.

Obviously, the plans you have outlined would not be implementable within a year. Does this mean that you will be standing again in 2014?

I have not decided yet (and I still have plenty of time!).