Manifesto for the Debian Project leadership election - Ian Jackson
This manifesto comes in three parts:
1. Who am I ?
2. What will I do ?
3. What do I believe ?
1. WHO AM I
My main contributions to Debian have been that I wrote dpkg (Klee
Dienes is now maintaining it, but I'm still doing work on it) and the
bug tracking system (which I've now released as a general software
product suitable for use by other projects). I also wrote
debiandoc-sgml. I've been with the project almost since its
beginning, and over that time have maintained many different packages.
I've done a couple of other Linux-, UNIX- and net-related things; for
example, I used to maintain the Linux FAQ and I wrote a number of the
section 2 Linux manpages. I used to be a member of the UVV (USENET
votetakers). In my spare time I run a small noncommercial Unix site
which currently has nearly 100 users (chiark.greenend.org.uk).
In my professional life I'm a graduate of Cambridge University; I do
programming and development for a Cambridge crypto company. I
finished by PhD (in computer security) in May and hope to have it
approved shortly.
2. WHAT WILL I DO
2.1. Leadership role
I'd like to greatly reduce the current role of the project leader.
Historically the Project's leader has had very wide-ranging powers,
and broadly speaking when the leader has said jump everybody has
done.
I feel that this served us well when the Project was small and the
leader was able easily to determine the consensus of the developers
and give it the seal of their authority. Since then the Project has
grown enormously. We have many more developers; the core of highly
technical people has been supplemented by a large number of
additional volunteers. As a result it's harder for the right
technical decisions to be reached by consensus amongst the noise of
the large developers' mailing lists; this has resulted in a number of
decisions by fiat by the Project leader which have perhaps been taken
hastily and without consideration of all the issues. Likewise, for
political kinds of decision (for example, our stance on free
software, or the organisation of the Project) it's harder for the
leader to determine the will of the developers, and so they have had
to rely on their own decisions more.
I think that relying on the Project's leader in this way is unfair to
the leader and to the Project. The leader is put in an unenviable
position of responsibility for everything, and is required to make
every decision with nothing but their own say-so to back them up.
For the Project this decisionmaking mechanism makes it hard to ensure
that all the issues have been properly considered. In general, the
lack of a clear and defined role for the leader limits their
accountability and leaves them potentially responsible for everything
- not a tenable position in a volunteer project of this size.
I therefore propose to formalise the current organisational structure
to define (and thus limit) the power of the Project leader and create
other mechanisms for resolving problems that will allow that
responsibility to be shared. In particular, I'd like to put in place
formal decisionmaking processes for at least two kinds of decision,
as described in the next two sections. This will allow the best
decisions to be reached more quickly and surely, and provide a
mechanism for resolving disputes other than the 200-sided flamewars
now seen on the mailing lists.
Furthermore, as Project leader I would introduce a
`leader@debian.org' email address which the Project leader would be
required to use when acting in their leadership role. I explicitly
state now (and will lay down as a policy) that any other statements
by the leader are personal comments unless they clearly indicate
otherwise.
2.2. Technical committee
I plan that certain technical decisions will be taken by a technical
committee. The committee would have the power to resolve technical
disputes in the following circumstances:
- agreement of all the parties, or
- regarding what the technical policy on an issue should be
(contents of the policy documents), or
- in cases where a conflict between two package maintainers or other
responsible persons arises and some resolution is required to
avoid a bad technical outcome (eg two packages arguing over the
right to contain a certain file), or
- with a supermajority (two-thirds or three-quarters) it would have
the power to ask a package maintainer to follow a particular
technical path, and to override a package maintainer's decision on
whether to a bug report should be closed and what its severity is.
We need a committee for this because the number of developers has
grown too large for consensus decisionmaking to work for all of them,
and because such consensus decisionmaking requires a great deal of
to-and-fro and `me too' postings. The technical committee would not
be involved unless a dispute arose which someone asked it to deal
with, which would not be expected unless they'd failed to persuade
the relevant people (package maintainer, policy manual editor,
whatever) and felt that their arguments were still stronger.
The committee would probably be appointed by the leader (or perhaps
the board). Their mailing list would be publicly readable, but
representations would be made to an individual member of the
committee (who would forward it to the rest if they consider it
appropriate) and general posting access would not be allowed to keep
traffic down.
Formal rules will be laid down to protect the technical committee if
it should find itself at odds with the Project leader, and to allow
it some control over its own make-up.
2.3. Posts, appointments, rival subprojects and the suchlike
I plan to have a more informal mechanism for appointing people in
charge of areas. If several people wish to volunteer for a
particular job and can't decide between them who should do it then
the Project leader will have to decide, but I hope this will be rare.
The leader may of course have to intervene to terminate a `I'll do it
if noone else wants to' merry-go-round, of course.
I don't plan for the leader to have any formal control over the the
activities of other people in the project. For example, the I
wouldn't have insisted that the Deity team behave in any particular
way (though I wouldn't have hesitated to give my personal opinion).
Debian is a volunteer project, and standard management techniques
with line managers and supervisors and things are not appropriate,
IMO.
2.4. Political decisions
I'd like to have major political decisions (such as the Debian social
contract and free software guidelines) made either by direct polling
of the developers, or by a political committee elected directly by
the developers. I'd prefer the former if the technicalities of
voting can be properly organised.
This would hopefully ensure that these decisions were taken in
accordance with the wishes of the developers, and would also give
people something to point to if issues get rehashed uselessly.
Day-to-day decisions would remain in the hands of the people doing
the work, of course.
My plans for organisation of the project will be put to a vote of the
developers; when a procedure for passing such resolutions has been
developed I also plan to formally ratify the DFSG and social
contract.
2.5. External relations
Bruce has been doing an excellent job forging and maintaining links
with other free software and commercial organisations. If elected, I
would give him my full support to continue to do so. That includes
whatever job title he thinks is appropriate :-), and where I consider
it justified my support in any relevant internal discussions.
Incidentally, I wouldn't be unhappy for Bruce to win the leadership
election. I'm sure he'd do just as good a job as he has been doing
so far. I just think I can do it better, and have some particular
policies I want to implement - described above.
3. WHAT DO I BELIEVE
If elected I intend to continue to speak my mind on the mailing lists
as and when I feel it appropriate. I don't expect my robust words to
carry the weight of the project leader.
However, and with that in mind, there are some questions that
occasionally come up on which I think it would be good for me to make
my opinions known. If I were elected these would not necessarily be
reflected directly in my actions as leader; as I said above I feel
that the project leader's authority should be curtailed somewhat.
3.1. Software freedom
I'm a GPL-zealot. I think that the GPL was and continues to be the
most important factor behind the success of free software. Almost
all of the software I write in my own time is GPL'd.
I'm strongly opposed to the `not for commercial use' and
`modification prohibited' licenses. Indeed, I think that the DFSG
are too lax in that they allow software to be considered `free' when
the original authors reserve to themselves the right to distributed
modified versions (as opposed to shipping patches).
I'm strongly opposed to suggestions that non-DFSG software or
software which depends on non-DFSG software be allowed into the main
distribution. We should continue to encourage authors to make their
code DFSG-compliant using the means which are most effective in
promoting DFSG-free software in general.
If I do significant amounts of work on non-GPL'd (eg BSD-style
licensed) code I usually release my modified version under the GPL, if
the original licence permits this.
3.2. Future technical developments
Things that are high on my personal software worklist are (in no
particular order):
* Rationalisation of the dependency-handling code in dpkg into a
separate set of library calls. I have been working on this, but
it's a difficult and complex task. When completed this will make
the job of people like the Deity team easier.
* An automake-like replacement for debmake.
* A binary package integrity mechanism, based on digital signatures.
* Early configuration of packages, and isolation of configuration
questions in a way that allows them to be asked all at once, copied
from one system to another, etc. This will involve some internal
redesign to allow the same run of dpkg to do unpacking and
configuration in any order.
As the author of dpkg, I promise not to suggest that we drop dpkg in
favour of RPM :-). When the time comes for dpkg to be replaced we
should either rewrite dpkg or steal RPM or some other GPL'd or
GPL'able tool and fork it. We need to maintain control of our core
technology.
dselect is widely regarded as awful. It should be replaced or
enhanced - probably both. Any replacements for dselect should call
dpkg to do the actual work. Interfaces should be provided in dpkg to
facilitate this.
3.3. Commercial considerations - CDROM vendors, SPI, trademarks
I'm fully in favour of the existence of SPI - the Project needs a
legal entity for certain things (mainly to do with handling money and
other legal issues like trademarks). SPI exists for and is
controlled by the Project.
There have been conflicts in the past regarding CDROM vendors and
their requirements for the distribution, as opposed to the
requirements for a distribution available via the net (in particular
wrt version numbering). I'm quite happy for cosmetic changes to be
made that make CDROM vendors more happy. I'm not happy with certain
changes (particularly to our release strategy) that I feel have
impaired the ability of users to get up-to-date and working
software.
3.4. Release strategy
There have been considerable flamewars about our release strategy and
distribution layout. I don't think that all of the technical issues
have been resolved, and the policy for allowing uploads into stable
and the mechanisms for making such uploads available need review.
I intend to have a discussion on debian-policy where we will
determine what the requirements for our release strategy are, which
are more important and how we can trade them off, and what policy we
would like to follow. I hope that the archive maintainers will
participate in this discussion, and in any case would like them to
implement the consensus when it has been reached.
Two of my key personal goals for any Debian release strategy are to
preserve incremental upgradeability, and to make the most recent
software available to users as soon as it can be made stable enough.
I recognise that some users prefer to have more-fixed, known releases
and I'd like to discuss how we can achieve as many of these goals as
possible.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: