[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ?


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.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

 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

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,

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

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.


 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

 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

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

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: