Platform for Matthew Garrett
Introduction
My name is Matthew Garrett, and I am standing for the post of Debian Project Leader. I have been a Debian developer since 2002. Inside Debian, I have been involved in maintaining packages, working on porting Debian to non-Linux kernels and discussions regarding the technical and philosophical issues surrounding the project. This has involved negotiations with copyright holders in an attempt to obtain software under DFSG-free licenses, analysis of the freeness (or otherwise) of licenses and the defence of what I see as appropriate standards of freedom for Debian. I represent Debian on the Gnome advisory board, liaising with representatives from Sun, Novell, Red Hat, IBM and others. In the course of this, I have secured a commitment that Gnome will not depend on non-free Java functionality. Outside Debian, I have been lead developer on the Dasher project (an accessibility application), worked on improving the state of Linux suspend/resume support using ACPI and am a contributor to the Gnome project.
During everyday life, I am a PhD student in computational biology in the Genetics department at Cambridge University. I intend to use my skills for the forces of good.
The issues that face Debian
Communication
Debian's internal communication is currently poor. It is unclear what standards of communication are expected from the teams that are responsible for much of the project infrastructure. At the same time, information is sometimes requested in a way that does not encourage the teams to respond. The combination of these results in everyone feeling unhappy about communication.
You may recognise this issue from such classic debates as why packages haven't been built for some architecture yet, why packages that were uploaded have not yet made it into the archive, why someone hasn't been accepted as a maintainer and many, many more. These arguments rarely produce any useful discussion, consume time that could be better spent elsewhere and help encourage the perception that Debian has an aggressive atmosphere. The lack of communication also results in people having a poor idea about what stands between the current state of Debian and our release. Our poor communication is the single biggest issue to face the project at the moment. It must be fixed.
Consensus
Debian is a free software project. The argument over the general resolution that altered the social contract (and more discussions than you could possibly imagine on debian-legal) show that people have greatly differing standards of what "free" means in this case. I have repeatedly defended my beliefs about freedom against the more hardline definition that has developed over time, but it is not clear which of these definitions more closely matches that of most developers.
Basic disagreement of this sort results in yet more argument, but there is currently no way of determining which side is right. Since the social contract was written, the world has changed and the issues that we now fight over are ones that hadn't even been considered at the time. A consequence of this is that we are unable to agree on the acceptability (or otherwise) of licenses that seek to protect people against patent lawsuits. Perhaps worse, lack of agreement over what we believe are makes it harder to lobby for our beliefs. If elected, I will do my utmost to help Debian reach an agreement over what we believe.
Others
These are not the only problems that Debian faces and I believe that most other problems stem from these. We have failed to release because new issues keep arising. With adequate communication, a large amount of this delay may have been avoided. Debian's approach to licensing is often criticised, but we find it difficult to respond because we lack sufficient consensus within the project.
It may well be that there are other problems that are not a consequence of either of the two issues that I have raised - communication and consensus. However, I believe that these are fairly insignificant in comparison. We should concentrate on fixing the major failings before worrying about a multitude of minor ones.
What I will do about these
Enhance communication
After the election, I will contact each team to discuss the best way for them to communicate with the rest of the project. This information will be documented and made available publicly. Following this, if there are complaints about inadequate communication from a team, I will look into the issue and do what I can to make sure that the situation doesn't arise again. In cases where teams fail to maintain adequate communication with the rest of the project, I will do whatever is necessary to ensure that the problem is rectified. It is unacceptable for development to be slowed down because people are unsure about what is happening. However, it is equally unacceptable for team members to be abused by other developers. Developers who are unable to communicate in a reasonable way should not expect to obtain useful feedback, and this should be recognised by the community.
In the past, Debian was smaller and interpersonal communication was easier. Now we've grown to the extent that it's sometimes hard to recognise that everyone involved is an individual volunteer. This doesn't alter the importance of communication and it should be the job of the project leader to ensure that this vital communication exists.
Build consensus for the future
After the Sarge release, I will initiate a discussion about the social contract. This will be split into two stages:
A discussion regarding what standards Debian should hold
I will introduce new topics for discussion at regular intervals. Past threads on debian-project have shown that debate of issues such as the acceptability of patent licenses can take place with a reassuringly high signal to noise ratio. I am therefore confident that reasonable conclusions can be reached.
Determine if the existing social contract reflects what we want Debian to be and, if not, what should be changed
I expect this to follow naturally from the first step. In most cases, the meaning of the social contract is clear. If there is a clear indication that the consensus viewpoint is at odds with that meaning, any required changes should be fairly obvious.
Should it become clear that the current social contract does not reflect people's beliefs about Debian, then I will work to draft a general resolution to alter that. I will seek to ensure that the ramifications of any changes are well understood before proceeding to a vote, in order to help avoid controversy about the result afterwards. While this process will undoubtedly result in a great deal of heated debate, I believe that this will reduce the amount of disagreement about what Debian represents in future.
The release
At the time of writing, it has been 31 months since the last Debian release in July 2002. This is not acceptable. The release team has been hampered by communication issues between teams, resulting in release-blocking issues not becoming apparent until they are too late to avoid. I will work with the release team to ensure that potential concerns are stated clearly in advance and make sure that these problems are being actively worked on. Enhanced communication will not directly result in a faster release, but it will make it possible to see what progress needs to be made before the release can happen.
Note that faster releases bring other problems, increasing the number of releases that we must support at any one time. I will liaise with the security team and stable release manager to ensure that our users are not left needing to upgrade excessively or left running a distribution that no longer has official security support.
Why I wish to do these
I do not believe that the DPL should be responsible for the day-to-day managing of Debian. Nor do I believe that the DPL should determine which direction that the project should move in. I believe that these responsibilities fall to the project developers and to the teams who have authority over various sections of the distribution. The DPL's role should be to ensure that it is possible for everyone to perform their roles. I believe that this is best achieved by reducing the opportunity for conflict in the project, by enhancing communication, transparency and consensus. The goals I have outlined above are general, but I strongly believe that they are the most important issues that the project has to deal with and I believe that they are most easily accomplished with the powers that the DPL holds.
Why me?
Both inside and outside Debian, I have demonstrated the ability to engage in non-confrontational discussion. I have a good working relationship with members of the majority of delegated teams within Debian, which has allowed me to work on documentation providing information about their Debian roles and responsibilities. I have successfully represented Debian to industry figures, ensuring that our concerns have been understood.
In summary, I believe that reaching consensus and communicating are the biggest challenges currently facing Debian, and that as Debian Project Leader I will be able to help address them.
Rebuttal
Three of the other candidates have discussed how the DPL should delegate tasks effectively. Anthony Towns says:
It's my belief that Debian could be improved here simply by giving delegates clear authority to make decisions over their areas of expertise, and accepting that others are expected to persuade or convince delegates and maintainers that something should be done in some particular way.
And the Branden Robinson / Andreas Schuldei "Scud" proposals to appoint a team of delegates to perform many of the DPL's roles have been widely discussed.
It's true that delegates should be provided with the authority to make decisions, and to expect that the correct decision can be made without receiving undue criticism. However, delegates need to be accountable to the entire project, not just the DPL. It is entirely reasonable for developers to ask how delegates have come to make certain decisions, and it is entirely fair for them to expect reasonable answers. In cases where this would lead to unacceptable demands on the time of the delegates concerned, we should address the fundamental cause of the problem by ensuring that more resources are available to the delegates. Lack of time should not be an excuse for lack of accountability to the project as a whole.
Project Scud is a valiant attempt to resolve the historical communication issues between delegates, the DPL and the rest of the project by spreading the DPL position more widely. However, I have some concerns about the mechanisms involved. The DPL's role is to ensure that the right person is doing the right job, not to undertake those jobs themselves. Andreas says:
smaller tasks are micro-delegated to the team member that is most appropriate for it.
Instead, I would argue that tasks should be delegated to the project member that is most appropriate. Appointing delegates in advance in this way runs the risk of reducing the DPL's ability to choose the most appropriate person for the job by making it harder to justify appointing further delegates.
Rather than appoint a team in advance, I will appoint delegates on an as needed basis as described in the constitution. Restricting my choice in advance does not seem like the best way of tackling problems that arise.
As outlined in my platform, my priorities are improving communication and consensus within the project. I do not believe that providing more power to a small set of people is the best way of approaching these issues. Power should be distributed throughout the project, not concentrated within a small subset of it.