Debian Project Leader election draws near

Stefano Zacchiroli has served as Debian Project Leader (DPL) since April 2010, and has announced that he will not stand for another term. The election for his replacement will take place between March 31 and April 13. In the meantime, much of the campaigning is taking place on the debian-vote mailing list, where project members have posed questions to the candidates and gotten detailed responses in reply (not to mention, in some cases, lengthy discussion threads).When his term ends in April, Zacchiroli will have been DPL for three years, the longest stretch since project founder Ian Murdock's in Debian's early days, so the 2013 election is attracting more attention than in previous years.

Candidates and platforms

The candidates are Gergely Nagy, Moray Allan, and Lucas Nussbaum. Each one volunteered (or, technically speaking, nominated himself) during the official nomination period in early March. The three have written their own "platform" documents, which are hosted at the 2013 election page. Each sets out the general reasons the candidate is running for DPL and the issues he hopes to address if elected.

Nagy ran for DPL in 2012 as well, and his platform begins by revisiting the issues he raised back then, and how the intervening 12 months have shifted his positions. In 2012, his platform focused on recruiting new project members, and on building a more "passionate" community in addition to one that excels technically. His current platform expands on that idea, with more specifics—such as increasing the opportunities for face-to-face events, publicly highlighting the contributions of experienced Debian Developers, and recruiting more non-packaging contributors.

Allan's platform focuses on the role of the DPL itself; he says that the DPL can help overcome the occasional conflicts between the many loosely-organized teams in the project. The DPL can mediate in conflicts, he says, but can also encourage more turnover in team leadership (and rotating members between teams), and can facilitate more organized discussions between teams. He would provide guidelines for more transparency and openness in communication within the project, and build more active relationships with outsiders for the teams that handle press, publicity, and corporate relations. He, too, advocates bringing a Debian presence to more local events and user group meetings, and actively recruiting new contributors. He also proposes forming fundraising teams to seek out donations for the project's various expenses.

Nussbaum begins his platform statement expressing concern that the core project is losing momentum; "very cool things" happen in the ecosystem, but outside Debian itself—which, if not careful, can lapse into contenting itself as a "package supermarket". He advocates reinforcing Debian in central position in the free software ecosystem, by fostering innovative products within the project itself (such as rolling releases and live images), reducing barriers to contribution, and improving communication with upstream projects. He also says he plans to continue Zacchiroli's DPL helpers initiative, but with the long term hope of evolving it into a driving team of Debian Developers who act as decision makers, with the DPL as chairperson.

Position papers like the aforementioned platforms are nice, but in the modern world a campaign thrives on debate in order to get the candidates to explain themselves. In lieu of a stage, podium, and moderator, the DPL candidates have at least been offered the chance to respond to questions from project members via the debian-vote mailing list.

Several of the questions were directed to all three candidates and asked for elaboration on specific points raised in one of more of the platforms. For instance, Timo Juhani Lindfors asked how each candidate would attract new people to the project, and Paul Tagliamonte asked how the candidates would represent Debian to the outside world. In both instances, the replies were on the safe side, although the question of attracting new participants did shift to address the "graying" of the project, and how to attract more youthful participants.

The big freeze

Where the discussion got more interesting, however, were the threads in which a list member posed an original question. Many of these dealt with the daily grind of keeping Debian development moving forward, or on the long-term organization of the project. For example, Lars Wirzenius observed that Debian has been in feature freeze for eight months, which is significantly longer than most distributions, and asked what the candidates would do to fix the long and painful release process and other development process problems.

Nussbaum responded with a number of ideas, including prioritizing the QA process and improving support tools like bug trackers. But he also suggested "more exploration of gradual freezes", perhaps in stages:

Allan said he does not think the DPL should "try to impose policies on teams like the Release Team", but provided a few ideas, including removing buggy packages much earlier in the freeze, and more actively flagging buggy packages. He also said that some form of Constantly Usable Testing (CUT) would be helpful, since many desktop users would prefer it:

Allan also observed that many packages ship with bugs that are tagged -ignore, which sometimes means the packages in question are unusable for some users even if they do not adversely affect others. One solution might be to declare separate release dates for different uses cases; "we could badge the new release as ready for the desktop before we close it off as final and suggest that people upgrade their servers."

Nagy responded that the fundamental problem is that fixing bugs is not perceived as rewarding, and it is considerably harder in many cases because upstream developers cannot be relied on for assistance. The answer, he said, "is to make upstreams, downstreams and everyone else involved realise that if we work together, we'll release faster".

Decisions, decisions, decisions

Zacchiroli raised two questions about how Debian tackles distribution-wide changes. First, he asked how they would improve on the inertia that in the past has made Debian slow at planning and deploying large changes. Subsequently, he asked the candidates how they, as DPL, would approach the tricky problem of making such potentially far-reaching decisions—for example, which init system this distribution should use. As he put it,

No candidate advocated drastic changes (perhaps predictably; after all, it is hard to imagine any candidate answering with a response that does not make technical merit the top priority). But the replies do provide insight into the candidates' viewpoints on how the project should be managed—for instance, how big of a role the Technical Committee (TC) should play in making calls between competing proposals.

Nagy replied that big technical decisions like the init system should be addressed at in-person events like DebConf, where the stakeholders can sit down and discuss the topic:

Nussbaum said that the decision should be left up to developers and key package maintainers, with the TC only stepping in on rare occasions. The DPL can be helpful in facilitating discussions, he said, which usually result in a thorough review of the possible solutions—while the final decision will usually involve compromise:

Allan also said the DPL was not usually the best fit for making large-scale decisions, but instead could "encourage people to improve UIs, agree on best practice, and write better documents". He also cited his platform document, which suggests "that we might make distribution-wide changes quicker by more vocally authorising NMUs [Non-Maintainer Uploads] to help with changeovers."

To the polls

While the role of project leadership is an important one, and while Debian has long grappled with how to improve and streamline its release process, there are naturally plenty of other issues about which Debian project members have questions. Money came up several times; Raphael Hertzog inquired whether Debian should spend its money on anything other than hardware and travel reimbursement; various responses included code camps and underwriting individual developers. Martin Zobel-Helas asked specifically whether or not the project's planned hardware expenditures were justifiable. Here again, the candidates do not stake out drastically different positions, but their responses to the specific questions illuminate some distinctions, like how they connect budgeting for expenses to fundraising (both in terms of ongoing contributions and short-term campaigns).

The discussion on the debian-vote list is likely to continue until the voting period begins on March 31. The candidates are also posting material on their individual blogs (as are other Debian project members). There is a generally amiable tone to the campaign, as one would expect from a mature project staffed by volunteers. But the campaign itself is interesting to watch for a few reasons. For one, it has been three years since the last change of DPL; when Zacchiroli was running for re-election the campaigns largely turned into a referendum on his continued presence in the role (which, although certainly a valid question for the voters, is different than the question of setting new priorities for the project).

But another interesting facet of the election is the fact that it provides the public with an insight into the inner workings of the project management. Debian is not unique among Linux distributions for electing its leadership by a completely democratic process, but it is in the minority. The Fedora Project Leader is a full-time employee of Red Hat (who also appoints four of the remaining nine Fedora Board members); openSUSE is governed by a community-elected board but with a chairperson appointed by SUSE; Ubuntu sponsor Mark Shuttleworth serves as project leader until he decides to step down, though the distribution has an elected community council as well. In contrast, Debian's open leadership-selection process provides a window into the topics of debate that every distribution leadership team faces—at one time or another, anyway.

And Debian is different in that the DPL is its sole elected leadership position. Selecting four or five board members all at once allows the voting public to make compromises and put together a broad ticket; the DPL works alone. Then again, the DPL "works alone" solely in the sense that the project's bylaws set out, and the DPL's role differs significantly from the decision-making powers often wielded in other projects. In reality, the DPL does not dictate policy, but works to coordinate and communicate between developers and to represent the project to external projects and communities. Thus, in other ways, the DPL remains just one active participant in the Debian community, which has always stayed both active and vocal—and seems likely to continue doing so, regardless of who takes home the most votes.