The 2016 Debian Project Leader election

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

The Debian Project Leader (DPL) is the project's democratically elected leader; each year, the Debian Developers vote, and whichever of the candidates comes out on top is deemed the winner. At least, that is the way it usually works; this year, the process is a bit different, due to the fact that there is only one candidate. Unless something peculiar happens, then, candidate Mehdi Dogguy will take over as DPL on April 17. It may sound a tad unusual from the outside but, apart from the actual vote, the election process has proceeded as normal, with Dogguy publishing a candidate platform and taking questions from project members on the election mailing list. Some are beginning to worry that the paucity of candidates indicates that the burden of serving as DPL has become too burdensome, however, which is a problem that Debian will need to address in the long term.

Debian project secretary Kurt Roeckx sent out the call for nominations on March 5, six weeks before current DPL Neil McGovern's term ends. As usual, the election was open to all Debian developers, who must nominate themselves as candidates. McGovern declined to run for a second term, and Dogguy was the only candidate who stepped forward prior to the March 12 deadline. The DPL election method can be complicated when there are many candidates, but unless the majority of the voters select "none of the above" (which is a ballot option), Dogguy will almost certainly become the new DPL.

Platforming

According to the election rules, March 13 through April 2 is reserved for the "campaign," during which project members can examine each candidate's platform and ask questions on the debian-vote mailing list.

Dogguy's platform centers on his vision for the project. He began by noting that the project has grown to the point where it complicates collaboration:

Debian has grown so much that it has become a federation of team-sized, smaller projects. As a consequence, we are having a hard time making solutions that scale up to the size of the bigger project. This becomes an even more challenging problem when the number of packages grows more rapidly than we’re able to onboard new contributors.

He proposed a review of processes and tools to identify bottlenecks and points of friction between teams, and said he will "work on collecting and compiling a repository of Debian use cases that can be used by contributors to find their way more easily into the project." In a related point, Dogguy highlighted the recruitment of new contributors as a task he will work on. Debian has successfully participated in third-party internship programs like Outreachy and Google Summer of Code, he said, "but we should also think about sponsoring such programs or make our own." Unlike outside efforts, such a program could emphasize Debian-specific goals:

We lack a program that focuses on (simply) getting more people familiar with the project, its philosophy, its community, its processes and its work-flow. I would like to encourage initiatives like Debian Women Mentoring Program and Mentoring of the Month (MoM) by the DebianMed team and generalize it to not focus purely on packaging tasks. I see this as an opportunity to join efforts and create a more generalized and project-wide mentoring program.

Dogguy also proposed two initiatives that would alter how Debian operates with respect to the outside world. The first is writing and publishing a project roadmap (which Debian does not currently do). Publishing a roadmap would help the various teams within Debian publicize their work, and enable the project as a whole to shine more light on its original work, beyond simply packaging and delivering upstream code. As DPL, he would describe each roadmap item in S.M.A.R.T. criteria, (that is, "Specific, Measurable, Assignable, Realistic, and Time-related") and make sure that progress is made.

The second initiative is pushing Debian to innovate and embrace new challenges. As an example, he cited installation media:

While our biggest sponsors in the past were manufacturers and hosters, today cloud actors joined us and usage of virtualized systems became very common. Still, we are only shipping installer images, but not pre-built system images (in various formats) or virtual system images. Aurélien Jarno has been providing QEMU images for quite some time now but I think that such initiatives could be more official and advertized. The status of system images for various Cloud providers is also not so clear and would deserve some attention. We got used to what we have. We should work on innovating and making sure the way we do Debian is still relevant to the world. We have to make sure that the way we install and deploy Debian is relevant to our users, because they are our priority. We should make sure that our users’ concerns are fulfilled!

Among the other new challenges, he listed improving security, making upgrades "unbreakable," and improving usability.

Debate

So far, there have been no questions about Dogguy's platform on the debian-vote list. This is not too surprising; the platform does not advocate for what one would call radical change, so it might not have generated debate in a year with multiple candidates, either.

But the scarcity of DPL candidates was raised in a question to Dogguy from Paul Wise. Wise noted that the only prior occasion when a candidate ran unopposed was in 2011, when then DPL Stefano Zacchiroli ran for a second term, and asked whether "this situation reflects on the health of the Debian project."

In his reply, Dogguy countered that while single-candidate elections are rare (he himself was surprised no one else volunteered, he said), most DPL elections have a small slate. He also said that he would "not generalize this as a symptom of an unhealthy situation" for Debian as a whole, seeing it instead as a sign that the role of DPL is difficult.

Wise also asked Dogguy if he thought voters should collectively choose the "none of the above" option, in hopes of triggering a new election that would attract more candidates. Dogguy replied that such a tactic would make the situation worse.

IMHO, standing up for a DPL election requires preparation and serious thinking. You don't usually decide within the nomination week, but start preparing it a while before. I am not convinced that waiting for another week will help us to magically find another candidate. If people didn't want to nominate themselves for DPL, then we should not force them to do so. Having "fake" candidates is not doing the project any favor. No one wants an inactive DPL. No one wants a DPL that is unprepared for the job.

Dogguy also noted that he had run for DPL in 2015 (coming close to winning) and said that "I don't think my candidacy would be more serious if [there] were two candidates." Nevertheless, he concluded, if project members do not want him as DPL, they are free to choose "none of the above."

Non-candidates

The question of whether or not this year's slim ballot indicates a problem within the Debian project drew replies from several others on the mailing list. Daniel Pocock responded that perhaps the public self-nomination process is to blame, and that nominations should be secret.

But Pocock and others also expressed concern that the role of DPL is simply too time-consuming, and that the level of commitment it demands is scaring off potential candidates. Ian Jackson raised the idea of replacing the lone DPL position with a board, although he worried that "decision making would be too slow if everything had to be done by committee."

Martin Krafft was skeptical, asking what sorts of powers such a board would have. Jackson listed budgetary issues and working with Debian's legal advisors, but pointed out that:

The DPL's very broad powers and strong legitimacy mean that they are often called on to give an informal opinion in circumstances where a board member who needed approval of other board members to do anything would have less authority.

The board idea did not gain much traction, but everyone seemed to agree that DPLs would do well to delegate tasks to other project members—which can be difficult to do in practice. Debian, like many free-software projects, is driven by volunteers, and volunteers are notoriously short on time. Dogguy noted in his platform that his employer will permit him to spend a small portion of each week working on DPL-related jobs. Such leeway with employers is not unusual (even just among prior DPLs), but at best these arrangements increase pressure on the DPL to take on tasks that the volunteer community may be slow at completing.

In the long term, Debian's growth as a project may mean that the DPL role becomes more and more of a time commitment. Whether that will mean redefining it or supplementing it with other leadership roles remains to be seen. At present, however, the lack of DPL candidates has only brought the issue to the forefront as a topic of potential concern. As Dogguy pointed out on the mailing list, there has rarely been a long line of volunteers willing to take on the task.

In spite of the larger concerns raised about the process itself, however, Dogguy seems to be regarded as a good candidate. There are no signs that there is a movement to reset the election process. This means that Debian, barring some unforeseen turn of events, already knows who its next project leader will be—and that new DPL has a solid understanding of the task ahead.

