[please follow-up to debian-project@lists.debian.org]
Greetings, fellow Debian developers.
The purpose of this message is to outline the reasons I running for Debian
Project Leader, and to present an idea of some specific things I would like
to accomplish during my term, if elected.
First, a brief biographical introduction: my name is Branden Robinson; I
have been a Debian Developer since approximately January of 1998. My most
prominent work in Debian has been as maintainer of the XFree86 packages,
which I have done since March of 1998. I am 26 years old, employed as a
free software developer, engaged to be married, and have no children.
I apologize for the length of this document, but it represents a lot of the
views I have developed over the past few years as a developer; if I did not
have this many concerns, and a desire to personally take part in rectifying
them, I would not be standing for Debian Project Leader.
I will also note that there are few specific courses of action in this
document to which I am wedded. The purpose of this document is to identify
my guiding principles, and my priorities. It serves as a preview of the
problems I will attempt to tackle, if elected. I believe in Debian's
democratic process, and I believe in building consensus. Unlike most
national governments, Debian is an organization where one can simply leave
if one is unhappy. Thus, a Project Leader must do more than simply give
lip service to consensus-building, and utter sound bites like "I'm a
uniter, not a divider". The Debian Project does not have a captive
membership; poor leadership will lead to loss of people, loss of vitality,
and loss of relevance.
I. THE DEBIAN PROJECT LEADER'S DELEGATES
The central -- and overriding -- issue to my mind about the role of DPL is
the process of delegation under the Constitution. I think this is a great
mechanism (potentially) that has been greatly underutilized to date.
First and foremost, I think we need more delegates from the Project Leader.
For the most part, Debian Developers have very narrow bounds within which
they can exercise their personal discretion. This is, largely, the right
way to do things. Since we are such a large body, and since we invariably
have such a large pool of varied opinions about which any particular thing
(technical or otherwise) should be done, this helps to keep Debian
harmonious. In other words, we may argue, but there is a fairly clear
perimeter within which any individual developer can act with a legitimacy
recognized by the rest of the Project. This is pretty much confined to the
details of maintaining packages.
However, the larger issues of administration and coordination are often
neglected; sometimes because there is no one to do them, and/or because
no one has a clear mandate to act upon them.
This is where I think the Debian Project Leader is required to act; indeed,
I consider this to be perhaps *the* central duty of the DPL. And,
moreover, not to personally act, but to delegate responsibility for these
duties. The days are long gone when the Project Leader could fulfill many
administrative tasks himself; instead, the DPL must identify knowledgeable,
dedicated, and willing people already within the Project to handle the
jobs.
I cannot at present find a canonical list of current delegates. However, I
am confident that we don't presently have enough of them, since there are
many things that need to be managed that presently are not, and which are
not properly within the authority of any individual developer as such.
I would like to see some formalization of the delegate status. As a first
approximation, I believe there should be a webpage on the Debian site
enumerating them, describing each one's duties, and stating the date each
one began. Delegates should serve for a term of one year, or until the
next DPL begins his term. I would like to think that in many cases, a
delegate could continue to serve out his or her year-long term even across
a DPL transition, but I also believe that delegates must derive their
status from the sitting Debian Project Leader, since this only makes sense.
It does not make sense to me for one DPL to be able to name a delegate, who
then holds that position until resignation. Very little of the above is
formalized in the Constitution, and I believe it should formalized in some
official document.
Furthermore, I think that each delegate must be held to some standard of
responsibility. What I really mean by this is that we must be able to
recognize in some attempt at an objective way when a delegate is no longer
performing his or her duties, and thus be able to replace him. The
Constitution is clear that a delegate can be dismissed by the DPL for
anything except any given specific decision. It does not say how exactly
one is to determine the DPL's true motivations in such a case, but I
presume that if the DPL were suspected of a Nixon-fires-Cox style of
misconduct[1], the developers could bring a General Resolution under the
Constitution to put a stop to it (or recall the DPL himself).
At the very least, I believe the current DPL delegates of Project
Secretary, Release Manager, Debian Account Manager, and Debian System
Administrators should be completely formalized under this process. I also
believe that it should be made explicit that delegates have the authority
to sub-delegate, or nominate stand-ins for themselves to handle any duties
already delegated to them if they are personally overwhelmed or otherwise
busy.
I believe that all existing DPL delegates, and the majority of Debian
Developers, have the best of intentions, but are sometimes not good at
recognizing when they no longer have sufficient time to dedicate to the
tasks for which they have volunteered. Implementing policies and
mechanisms for correcting this deficiency -- in a way that minimizes stress
and conflict between developers -- is my top priority as DPL.
II. KEEPING THE DEVELOPER BASE ACTIVE
Anyone who's been a regular in the #debian-devel IRC channel over the past
few years will know that I've long complained that the Debian membership
needs to be "reaped"; that is, we need to identify developers who are on
our rolls but no longer really contributing. This is important because the
core of our work -- our packages -- can end up in the hands of people who
no longer have time for their Debian work, and this we have parts of our
distribution that are effectively unmaintained. This is even worse than
having some critical piece of software unpackaged (consider, theoretically,
the case if we didn't have a "bind" package), because by advertising the
*presence* of a package, we are implicitly telling people that we support
it. Support means keeping it up-to-date, fixing bugs, coordinating with
other developers to make sure it fits into the rest of the package
structure in a clean and elegant way, and communicating with the users of
that package. When a package is left unmaintained, none of these things
happen.
I am sympathetic to all kinds of reasons a package maintainer may be unable
to contribute to the level required by the package, and the expectations of
reasonable users. However, we must nevertheless be able to identify
unmaintained packages and idle developers, and take appropriate steps to
recognize their status as such.
I propose that we experiment with, and ultimately apply, automated tools
for tracking package and developer activity, and act accordingly.
Unmaintained packages should be automatically placed into WNPP[2], and idle
developers should be moved into an "Emeritus" status, and their packages
distributed among active developers. There are already some tools in
existence to handle the identification of idle maintainers, but I am less
concerned with the specifics than with an effective result.
III. DEBIAN'S REPRESENTATION AT FUNCTIONS
(By "functions" I mean any gathering (typically, but not always, a
"real-world" event like a trade show) at which it would be worthwhile for
Debian to have a recognizable presence.)
My recent experience with LinuxWorld Conference & Expo, New York, 2001,
gave me a few ideas about we can better handle this issue. In a nutshell,
we had no one representing Debian with the coordinators of this event until
less than two weeks before it occurred; as a result, Debian very nearly
went without a booth at a major trade show. I do not consider this a good
thing, since we had Debian developers in attendance and willing to
represent us at the booth, answer users' questions, and otherwise put a
face on the Project.
Therefore, unless there is strong opposition, one of the first things I
would like to do if elected Debian Project Leader would be to delegate, on
a regional basis, Event Coordinators for Debian. These people would be
responsible for keeping track of trade shows, major Linux User Group
events, etc., at which Debian should have a presence. For each specific
event, they would either handle contact with the coordinating entity
directly, or delegate a person (preferably one who will be in attendance)
to do so.
As Debian Project Leader, I am willing to attend conferences and expositions,
make presentations and speeches, and otherwise be a representative of
the Project. I have public speaking experience and am not easily
intimidated by circumstances[3].
IV. DEBIAN'S RELATIONSHIP WITH SPI
I have not made it a secret that am very concerned about Software in the
Public Interest, Inc. It does not appear to be a very active organization,
and it needs to be if it is to retain its status as a non-profit
organization in the state of New York.
For instance, the SPI treasurer, who handles all of Debian's money, has
not produced a report on our assets and expenditures in at least a year.[4]
This concerns me greatly. Debian neither has nor needs much in the way of
raw cash, but we do occasionally have expenses, and we need to know both
what we can afford, and we need a person at SPI who is responsive.
As Debian Project Leader, I intend to get into personal contact with as
many board members of SPI as possible and attempt to persuade them to
populate their board with people who are able to give some attention to
their duties.
If such efforts are not successful, I am willing to spearhead an effort to
create a *new* non-profit organization to serve as a legal umbrella for
Debian, but this is a lot of trouble, could lead to legal wrangles or a
schism of some sort, could cause Debian to lose access to the money SPI
already has earmarked for the Project[5], and is something I would consider
a last resort.
The bottom line, is, however, that Debian needs an active legal umbrella
over it.
The following are issues that I consider of secondary importance to the
ones listed above. Nevertheless, they are ideas I have and I thought I
would take this opportunity to enumerate them.
V. REVISION OF THE DEBIAN MACHINE USAGE POLICY
When I first read the DMUP[6] I felt it was a poor fit in places for
Debian. I was told that many of its terms were lifted verbatim from an
ISP's Acceptable Use Policy (AUP). As DPL, I'd like to appoint a team,
including at least one representative from the Debian System Administrators,
to draft a new one.
VI. DEBIAN PROJECT CONSTITUTIONAL COURT
We have learned over the past couple of years that there are some very
interesting subtleties with the Debian Constitution. For instance, there a
few corner cases that its voting method does not cover[7].
Also, there are occasionally ambiguities that crop up with interpretation
of the Debian Free Software Guidelines (DFSG).
Just as Debian has a Technical Committee, I'd like to see a body of
legally-minded people formed who are prepared to give this issues the kind
of scrutiny they deserve. As with the Technical Committee, of course,
their decisions could be overridden by a General Resolution of the
developers. The point is to get a formal structure in place for handing
issues like this that don't require General Resolutions in and of
themselves. GR's are a very weighty process, and where decisions of this
nature can be made, it is good to have a mechanism for making them.
VII. THE #DEBIAN-DEVEL IRC CHANNEL
The very existence of the #debian-devel channel has been an open secret for
years. At this point the secret is so open that it practically isn't one
anymore (and this document will serve to make it even less so.)
I have agitated at various points in the past for a specific policy of who
is and is not allowed in the channel, and whether or not subjects from the
debian-private mailing list can be discussed there (the answer to the
latter is probably determinative of the former). I have a personal opinion
on the answers to these questions, but more important than my opinions is
the lack of an official policy for this channel. It may surprise some
people to think that actual work gets done on an IRC channel, but this is
in fact the case from time to time, since Debian developers often have few
opportunities to speak with each other in real time.
As DPL, I'd like to see this channel's status officially recognized, and a
position on the two subjects above formally stated. If #debian-devel is
not to be substantively different from #debian, that is fine; a new channel
can be created to serve the needs that (in my opinion) #debian-devel
currently does, and with some access controls in place.
VIII. THE DEBIAN PROJECT'S VOICE IN THE LARGER POLITICAL SCENE
Debian is a heterogeneous project, as such it affords a wide spectrum of
political and philosophical beliefs among its membership.
However, there are a few cases, especially with respect to intellectual
property law, where a general consensus of opinion among Debian developers
can be expected. Debian's profile is growing, both within the Linux
community (as we continue to survive and thrive even as some other
distributions reduce their scope or vanish altogether), and outside it, as
the phenomena of Linux, GNU, and free software (or Open Source) appear with
increasing frequency in international media.
I think it would be a shame if Debian did not make an effort to lend its
weight, however great or small, to specific political issues where it is
important to do so. For instance, I imagine that Debian developers would
be fairly united behind repeal of export controls on cryptography in the
United States, and even more so behind rationalization of recent tax
proposals in Poland and Italy that threaten to make free software unviable.
As Debian Project Leader, I will not undertake to write some screed and
mail it off to some government (those who know me know that I am pretty
free with my opinions, as are many of my fellow developers), but I think
organizing some efforts of this kind would be a good idea. Regarding U.S.
crypto policy, I would like to be personally involved, and I would
delegate such a task to a citizen of the appropriate country in cases
mentioned above such as Italy or Poland. After being written, such
messages should probably put through some sort of ratification process
(possibly the same as a General Resolution), to ensure that they are truly
representative of the developers.
The bottom line is that I would like to take steps to get Debian's voice
heard in the halls of government where appropriate, so that our ideals --
and our means of achieving them -- are not legislated out of existence by
governments hostile to them (or, more likely, governments that have sold
sections of their lawbooks to large corporations comfortable with past
models of intellectual property and its distribution).
WHY I AM RUNNING
I was asked recently on IRC whether I was running for Debian Project Leader
because I wanted to be DPL, or because I had an agenda I wanted to see
achieved.
To be honest, the question somewhat confused me. I don't find them to be
mutually exclusive goals. Certainly, as I have outlined above, I have
specific ideas about weaknesses within the Project, and I would like do
what I can to rectify them. However, first and foremost, the Debian
Project Leader must be representative of those who elected him or her.
The DPL is not particularly empowered to stand against the will of the
developers generally, since they can overrule anything he or she does with
a General Resolution. However, as I noted before, a GR is a weighty
process and a DPL who consistently acts in discord with the will of the
developers can do damage simply by wasting the Project's time, forcing the
developers to take time away from improving Debian and put it towards
cleaning up his messes.
Therefore, I invite my fellow developers to read what I have written above,
place it in the context of my past work for Debian, and decide -- each
person for him- or herself -- whether I can be representative of the
Project as a whole. I am running because I feel my goals and ideals are
consonant with those of most of the other developers. If I did not feel
that way, I would not run. If I turn out to be wrong, or if I am not
elected for some other reason, I will not resign from the Project. I will
continue to carry on as I have before, though I will certainly urge the
next Project Leader to adopt my first four points as goals. I'd very much
like to see those problems solved no matter what, and I am willing to work
within my limited authority as a package developer to see them solved.
MY STRENGTHS AND MY WEAKNESSES
I will have to trust my fellow developers to have formed their own opinions
of my strengths and weaknesses, and how they may affect my performance as
DPL for good or ill. However, in an effort at frankness, I will attempt to
offer my own perspective on these issues.
Strengths:
* I have a fair degree of facility with Bourne Shell, C, and Python, and
have written programs or projects in all of these languages.
* I have been with the Project for a fairly long time (3 years), during
which I have been an active participant in several areas -- aside from
just maintaining my packages -- and have been a Debian user for five.
* I enjoy a good working relationship with many well-known Debian
developers and am very far from an unknown quantity to most
developers.
Weaknesses:
* I do not have a degree in Computer Science, therefore my skills are
perhaps not as well rounded as they could be. I have never written an
LALR parser, let alone a compiler.
* I am not an unfailingly conciliatory person. I have, do, and probably
will continue to flame people within the Project from time, and I don't
doubt that this will cost me some votes; that's all right. In my
opinion, a DPL whose hot buttons you don't know about is worse than one
whose you do. :) At any rate, I can only recall writing one really
big flame of someone outside the Project since I have been a developer,
and that was Eric Raymond. ESR is a big boy and could probably handle
it (if he ever saw it, which I don't know -- I was ranting about
breakage in fetchmail). Nevertheless, if elected DPL, I realize that I
turn the temperature down on my occasional email flame of a fellow
developer. That's a sacrifice I'm willing to make.
People who have met me at conventions say I come across much friendlier
in person. I don't think my online persona is all that different; I
just may have an unfortunate talent for writing flames that are more
memorable than most of the other things I say. :)
Other people can feel free to add to the above lists; those are issues that
I feel have the most relevance to my candidacy for Debian Project Leader.
Thanks for your attention, and I hope this message has not been overlong.
FOOTNOTES
[1] President Nixon fired the U.S. Attorney General Archibald Cox in an
effort to put a stop to the Watergate investigation (1974).
[2] Work-Needing and Prospective Packages; this used to be a simple
textfile list, but is now managed via the Debian Bug Tracking System; see
<http://bugs.debian.org/wnpp>.
[3] An oft-quoted statistic is that people are in general more phobic about
public speaking than death. While I have difficulty believing this myself,
I thought I'd reassure people that I believe myself able and willing to
handle public appearances as a representative of Debian.
[4] Wichert Akkerman told me this at LinuxWorld New York this year.
[5] I'd hate to think that would happen, but it very well could. Not
necessarily due to spite or malice on the part of SPI board members, but
due to simple inactivity.
[6] http://www.debian.org/devel/dmup
[7] These have been discussed at very great length on the debian-vote
mailing list.
--
G. Branden Robinson | One man's "magic" is another man's
Debian GNU/Linux | engineering. "Supernatural" is a
branden@debian.org | null word.
http://www.debian.org/~branden/ | -- Robert Heinlein
Attachment:
pgpaSPIw9817b.pgp
Description: PGP signature