DPL Platform

Neil McGovern

Introduction

Hi there,

For those who don't know me, after a long history of Debian in a number of different teams and roles, I've now decided to run for Debian Project Leader.

Debian activities

Having done a lot of stuff in Debian, it's a bit hard to remember and list them all, but below is a brief overview of the wide-ranging areas I've been involved with.

I first started getting involved with Debian in 2003, by packaging a blogging client called 'Drivel'. At that point I applied for DD status, and after going through 3 AMs, finally got my account in 2005. Since then, I have been involved in a wide range of areas in Debian:

Release team / Release Manager: I suspect most people will know me from my time in the release team, and later as Release Manager for three releases in a row: Lenny, Squeeze and Wheezy.
Press officer: I'm currently one of the Debian Press Officers, dealing with the press enquiries that occasionally reach us, rather than going straight to the DPL.
Assistant secretary: Since 2008, I've served as an assistant to the then Secretary, Manoj, Bdale as acting secretary, and later to Kurt, helping set up GRs and providing views on the interpretation of the Constitution for their advice.
DebConf: I first became involved with the DebConf organisation team in 2006 in Mexico, setting up the main DebConf Website, and then co-organising DebConf 7 in Edinburgh, UK. I stayed involved for DebConf 8 with the sponsorship team.
SPI board member, and secretary: I was first elected to the Software in the Public Interest board in 2006, and continued until 2009. SPI is the legal umbrella that Debian sits in within the United States, and holds the majority of Debian's assets.
Webapps-common policy group: I was one of the authors behind the attempt to get a common policy for packaging webapps in Debian. The draft was fairly complete at the time, but highlighted the differing needs of upstreams and Debian when it comes to packaging webapps, an issue that still continues today.
Google Summer of Code admin: For two seasons, I was an admin of the GSoC project in Debian, helping students be assigned mentors.
Application manager: Possibly due to the length of time it took me to get through NM, I was motivated to become an AM myself, so did so with a couple of applicants. At the time though, the workload was huge for an AM, and I'm glad to see it's improved massively.
Secure testing team: The secure testing team was set up to help provide some level of security support for Debian's testing suite. This involved tracking things through unstable, and the set up of the security tracker, as well as review of packages and issuing advisories for unembargoed issues.
Debian UK clothing: Finally, I designed a number of t-shirt designs which may be recognised by a number of people reading this, or just me in the Debian kilt!

Other activities

In my day job, I work for Collabora who are an open source software consultancy, based all around the world. I'm the Engineering Manager, making sure our great team of consultants are happy and working on projects they enjoy - contributing to open source software.

Dabbling in politics, I've been a city councillor for Cambridge City Council from 2008-2012, and I've also been on the board of the Open Rights Group, a UK-based organisation that works to preserve digital rights and freedoms by campaigning on digital rights issues. I'm also a member of the Network Operators Committee on OFTC, and a regular irc op on #debian related channels.

Debian - Our shared vision

Where we came from

The Debian project has been around for a long time. Early in our history, we found a simple concept: "the universal operating system". Over the last 20 years have shifted somewhat to what we are today. Some of our earliest traditions remain core to the project, and some have moved to better align ourselves with the wider free software community. This is not a bad thing - when we were first founded, the wider ecosystem didn't exist - Debian has help found and create that ecosystem. However, some key characteristics remain fundamental to the project:

A dedication to technical excellence: No matter what, Debian takes the technically correct decisions. We don't shirk away from this - we embrace it.
We are a community distribution: Debian is not, and shall never be controlled by a central figure or power. Our power comes from the very people who work on the project - those who dedicate the time and their skill to making Debian the best it can be.
We integrate: Through Debian Policy, our software works together. Through our diligence, we have upgrades rather than reinstalls. Through our expertise, Debian just works.
We care about software freedom: The Debian Free Software Guidelines are core to what we believe. They empower us to make the world a better place.
We care about our users: Without people using Debian, we have no purpose. There is no point in producing an academic operating system that cannot be used by real people, every day.

These core concepts have existed for many years. After all, there's a reason why Mike likes Debian.

Where we are now

37500 packages. 12 architectures. 3000 contributors. 144 derived distributions. Debian has never before been more important. But one must wonder - are we still serving our core aims? I answer with an emphatic yes.

We've had arguments and unrest over the init system debate, and even though there is a large strength of feeling over the right path to take, it's much calmer than in the past. It may not seem like it at the time, but there's been no expulsions, no DPL recall votes, no fundamental forks of Debian. I believe it's our technical excellence that helps us continue to work together.

As a community, we seek to work with each other. There remain issues on how exactly we can do this - the disparate needs of packagers and trying to ensure we move towards a common system that works for everyone is sometimes in conflict. One thing that we need to remember is that Debian is a volunteer project. People can't be forced to work on a particular aspect, and we rely on others to do the bits of producing a distribution that we ourselves don't like doing, or can't do alone.

Our releases are well tested, and integrate with each other. However, as Debian expands, this goal is becoming harder and harder to achieve. A lot of good work comes from those who take a broad view of Debian, and don't look at just their packages.

Our core teams are generally working well, but can attract criticism for attempts to do their job. They also lack volunteers, but finding people who are interested and have experience in those roles is difficult.

We have managed to successfully release approximately every 2 years for the past 4 releases, providing a platform for our users. For some, this is too slow. For others, it's just right. We've managed to set a timeline in place to give some visibility for when we're releasing next, and to enable contributors to know what's going on and what to expect, but there remains an issue about the time it takes in the freeze.

Where we are going

I'm terrible at future predictions, but one thing I'm willing to predict is that Debian will remain relevant to the community. We've moved from people using Debian directly to some of our derived distributions, but I'm not convinced that the raw numbers show a mass exodus away from Debian, instead it shows an influx of other people who have not used a free operating system before. This is something we now seem to have come to peace with, but that doesn't mean we should simply be a base distribution others can build off, and not be useful in our own right.

We need to ensure that we cater to our users, and there's millions of them. From those running the latest software in unstable, to people who simply want a rock solid core release we can put on our servers, receive security updates, and leave alone. The size of Debian is increasing, and will reach a point where we're unable to guarantee basic compatibility with other packages, or the length of time it takes to do so becomes exponentially longer, unless something changes.

Yet this is not something that is insurmountable, we have some of the brightest people in the world working with the project. We are the global experts at making sure our software integrates. We need to ensure we stay that way.

How I will help get us there

I will support and enable those who do the work to get what they need, when they need it. Compared with a number of years ago, our core teams are working well. I believe it is the DPL's job to remove the blockers and let our colleagues get on with their jobs. That's not to say they shouldn't get the support they need. I will listen to our contributors and users, and be guided by those who want Debian to go from strength to strength.

I will push for implementation of "PPA" archives, and modernising our build and infrastructure system by working with the FTP Masters, wanna-build team, and DSA. It should be much easier for us to produce a working system with the correct tools, and some of our core infrastructure has not been keeping up with what we need to make such a large system.

I will promote and encourage engagement in non-packaging aspects of Debian contribution. We need to reach out more to people who aren't involved with these teams, and encourage them as an important part of producing the distribution. One method to help achieve this is via a mechanism we've had for a while - mentoring, but applying it to non-packaging work. I'd like to see this embedded into all of our processes.

I will continue to communicate with the project - the daily DPL log as set up by Stefano is a great tool, and monthly bits mails are helpful to show the project what the DPL is up to. As far as possible, I will engage with teams and the project on public lists, as this is one of our fundamental priorities.

What else?

There are many more areas that the DPL could get involved with, and many more promises I could make. I think that doing so would be foolhardy, the job of the DPL is a tough one that requires a lot of work, and I don't want to bite off more than I can chew immediately.

The DPL has a unique role. If there's an issue which only the DPL can solve, I'll do whatever I can to ease the issue and find a resolution. Be it authorising new expenditure so that we get buildds that are reliable, or speaking to the press and industry about the benefits of Debian, or even simply encouraging all who want to help us in the project, as DPL I will ensure we let our colleagues get on with the work they love.

Rebuttal

Lucas' platform seems to me to be a strange one. It mentions very little of the current challenges facing Debian, instead saying that focus is moving away from Debian. It also seems to lack a vision for where Debian belongs in the wider community - our strengths, the things we bring to free software are not evident.

Instead, Lucas focuses on two specific proposals.

Auditing our finances

Debian has at least 100,000USD available to us, and the rate of donations exceeds the rate we spend it. This problem has been known for some time, and we have constantly looked to improve ways of spending the money that is donated to us. A lot of good work has gone on in the past, starting with Steve McIntyre and continued by Stefano to bring this down. Notably, sprints are an excellent use of they money - bringing groups together to improve real time communications.

My main concern over Lucas' focus here isn't in the concept of knowing exactly how much we have, or the creation of a potentially restrictive budget could stifle spending that happens to be in the wrong budget line, but that the focus is here rather than anywhere more useful for developers. It seems to be a exercise in bureaucracy, where I believe that having a ballpark figure of our assets is good enough, especially when we're not spending our donations. We already have an auditor team - is there an major issue here which requires a large chunk of the DPL's energy?

The DPL board

My concerns about the concept of a DPL board remain as they were in 2005, and the concept of Project SCUD.

It's slightly unclear how this board would be comprised. We've spent many years in Debian to try and get rid of any cabals, and I believe that there's a real risk in creating another one here. Lucas mentions that he'd be committed to transparency, but then tries to justify a closed group with the excuse that some core teams have private IRC channels.

I shut down the Debian release private channel when I took over as RM. We should be making things more open, not creating areas for private discussion, unless absolutely necessary. The problems with private communication mediums are fairly evident, an example can be seen in the recent delegations which were discussed in private. We will not hide problems.

However, I think there is a more fundamental concept here, one of democratic accountability. The DPL's role is one that contains a mandate from the project to lead. This mandate is the one that allows the DPL to speak for the project, to guide the project and to make decisions. This mandate will not apply to a board. What happens if a member of the board goes slightly mad, and spends a chunk of money on banana plantations. Currently, the DPL can be removed by a GR, but who does the buck stop with in a board?