Platforms for Branden Robinson
Introduction and Biography
Greetings, fellow Debian developers.
The purpose of this message is to outline the reasons I am running for Debian Project Leader (DPL), and to present an idea of some specific things I would like to accomplish during my term, if elected.
First, a brief biographical introduction is in order. 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. Since August of last year, I have also been the Treasurer of Software in the Public Interest, Inc., Debian's legal parent organization and manager of the Debian Project's assets. I am 27 years old, employed as a free software developer, married, and have no children.
Some of this platform may be familiar to you if you have read from my DPL Platform from last year. This is because some of the issues I was concerned about have not been addressed in ways that I'm completely happy with.
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 priorities, not to draw a roadmap which I will follow in excruciating detail. Since I feel that a diagnosis of problems is less valuable without proposed solutions, I'm suggesting possible solutions. I look forward to interested people stepping forward and participating in the process of solving these problems. To me, leadership means listening, and then taking action on an informed basis. If you feel that some of my proposals suffer from a lack of information, I urge you to waste no time in bringing me up to speed.
Unlike some, I firmly believe that Debian's democratic, constitutional basis is a sound one. I do not believe it retards our growth or viability as a software project. On the contrary, I think that by distributing the lion's share of power among the Developers, rather than vesting it in the Project Leader, the Debian Constitution ensures our Project's long-term prosperity. It protects our Project's identity and goals from being excessively over-identified with a single individual. In the Debian Project, you shouldn't ever have to worry about what happens if developer X "gets hit by a bus", or -- more likely -- resigns (whether formally or by simply vanishing without a trace).
That said, the role of Project Leader is still an important one. The DPL must have an awareness of the challenges that face our Project which are too large for any one Developer to surmount, and attempt to allocate resources towards overcoming those challenges. At the same time, the Project Leader must maintain Debian as an environment that encourages experimentation, novel problem-solving, and reinforcement and reward for the volunteer spirit that is the backbone of our Project. Debian is an organization where one can simply leave if one is unhappy, so a Project Leader must do more than simply give lip service to consensus-building. The Debian Project does not have a captive membership; poor leadership will lead to loss of people, loss of vitality, and loss of relevance.
Major Issues
The following is a list of items that will be high on my priority list.
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 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 how 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 perimeter 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 and directly act upon the problems of the day, 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 am confident that we don't presently have enough delegates, since there are many things that need to be managed that presently are not, and which are not properly within the decision-making authority of any individual developer as such.
I would like to see greater formalization of the delegate status. As a first approximation, I believe there should be a webpage on the Debian site that not only enumerates them, but describes 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. It either should be formalized in some official document, or a set of sound traditions should be established.
Furthermore, I think that each delegate must be held to some standard of responsibility. The delegate must fulfill the role to which he was appointed, or be prepared to step down. The Constitution is clear that a delegate can be dismissed by the DPL for anything except a particular decision. It does not say that the DPL cannot dismiss a delegate if that delegate isn't making decisions at all. Of course, if the Developers disagree, they can bring a General Resolution under the Constitution to put a stop to it (or recall the DPL himself). As DPL, I would publicly put delegates on notice that their inactivity is causing problems before withdrawing their status.
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 responsibilities, and thus
we end up with 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 our users 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. As we've seen over the past
year, when critical packages go unmaintained in this way, our release
process gets bogged down.
Not to be ignored is the fact that inactive Developers on the rolls swamp
our Constitution's Standard Resolution Procedure by artificially inflating
the value of Q, making it difficult for quorum to be met, and
action to be taken. This has the effect of falsely amplifying the
influence of people who prefer the status quo. Not being around to even be
aware of an issue under discussion is not the same thing as preferring that
a General Resolution not come to a vote. See our Constitution for more
background on this problem.
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. Idle developers should be moved into an "Emeritus" state, lose their Developer status under the Constitution, and have their packages distributed into the WNPP system. 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.
Finally, I think implementing the above will go a long way towards addressing the "stigma" of Non-Maintainer Uploads (NMUs.) Right now, we have a great many packages in our archives that claim to have maintainers, but in actual fact, they don't. The maintainer may be otherwise active but neglecting a particular package, or the maintainer may simply not be participating in the Debian Project anymore. If we have ways of recognizing these facts, I think the fundamentals of our NMU procedures can remain unchanged.
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.)
This is one area where we've made some progress since last year; however, problems struck again anyway at LinuxWorld in New York and at the Annual Linux Showcase.
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.
One role that Event Coordinators can fill is that of handling complaints about exhibition controllers. USENIX was quite militant and almost extortionate in the way it treated non-profit booths at the Annual Linux Showcase last year. Even when we run our booth admirably, efforts by exhibition administration or sponsors to restrict access by non-profit groups -- especially with insidious methods like banning "outside" equipment and charging $130 for a table -- put a huge damper on Debian's ability to make itself visible to new users. Cash donations at booths also must not be ignored when considering Debian's revenue streams. Debian is funded entirely by donations; if exhibitions keep us off the show floor, they strangle us financially.
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 happy to speak before an audience of any size.
IV. DEBIAN'S RELATIONSHIP WITH SPI
Here is another issue where substantial progress has been made since last year. However, in my opinion, this progress has been insufficient. SPI is in much better shape than it was one year ago, but there is still much to be done.
As Debian Project Leader, it is my intention to recruit volunteers on behalf of SPI and attempt to grow the organization.
As SPI Treasurer I am aware that there is a risk of a perceived conflict of interest if I am also elected DPL. I will do whatever is necessary to ensure that any such perception is unfounded and refutable. I think the appointment of a "shadow treasurer" who also receives all mail sent to the SPI Treasurer and to whom I CC all correspondence as SPI Treasurer (as it happens, I already CC the entire SPI board on such correspondence when functioning as SPI Treasurer) would help to achieve this.
I am prepared to resign one of these two offices if the general consensus is that it is completely impossible for me function in both of these roles without jeopardizing either organization. However, I am confident that this is a problem that can be solved through accountability and visibility. It is my intent to resign as SPI Treasurer as soon as there are procedures in place to enable future Treasurers to do their jobs efficiently, rather than having to inherit headaches from previous Treasurers who may have neglected their duties.
V. REACTIVATION OF THE DEBIAN TECHNICAL COMMITTEE
The Technical Committee appears to have stagnated. There have been issues placed before the Committee and the Committee has failed to hold votes or otherwise reach conclusions on them. (Here is one example, and here is another).
This is a serious problem because the Debian Constitution vests a great deal of authority in the Technical Committee. This body must be active and functioning. As DPL, I will exercise all powers available to me to ensure that the Technical Committee is able to execute its functions in a manner that is both timely and consistent with our Constitution.
VI. THE RELEASE CYCLE
This is a question that is practically inescapable. What can we do to get Debian GNU/Linux to release more frequently? Hundreds of kilobytes of armchair analysis and thought have been given to the issue on our various mailing lists. I'll be frank and say that I don't know that I have a definitive answer. Changing our policy on point releases of the stable distribution to include more than just security fixes and corrections for completely broken packages sounds like one part of a larger solution. As DPL, I'd like to invite Release Managers past and present, and other interested parties, to help a structure a new approach to release management.
One thing I won't -- and don't want to -- do is yank the rug out from under the current Release Manager. Yes, the woody freeze has been taking a long time. However, it would, in my opinion, be folly to derail the process now, no matter how much some people are frustrated with it. Anthony Towns, the current Release Manager, needs your support. I'm very interested in hearing proposals for what we can do post-woody to make the release process less susceptible to friction, but right now the best thing anyone can do is to test fresh woody installs, test upgrades from potato, and find and fix release-critical bugs. If we hadn't made substantial progress on releasing I might feel differently, but we have. Anyone who feels that we haven't needs to review the facts.
Lesser Issues
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.
VII. APPOINTMENT OF A DEBIAN LEGAL TEAM
Just as Debian has a Technical Committee, I'd like to see a body of legally-minded people formed who are empowered to render official decisions regarding the interpretation and application of the Debian Free Software Guidelines. 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. GRs are a very weighty process, and where decisions of this nature can be made, it is good to have a mechanism for making them.
VIII. REVISION OF THE DEBIAN MACHINE USAGE POLICY
When I first read the DMUP 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 that better reflects the nature of the Debian Developer as a creator of content, not just a consumer of bandwidth and other resources. I believe it is possible to keep the donors of our Project's bandwidth and rackspace happy without addressing our Developers as if they are hooligans. In my opinion, the current DMUP veers a little too far to the latter, and is worded in an overbroad manner in some places.
IX. 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 to support and reinforce recent initiatives in Europe to adopt Free Software at the governmental level as an act of public policy.
As DPL, I would like to take steps to get Debian's voice heard in the halls of government if and 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).
X. MIGRATION AWAY FROM NON-FREE SOFTWARE SERVING OFFICIAL PROJECT FUNCTIONS
A quick review of our Social Contract reminds us
that our priorities are our users and Free Software. In my opinion, we do
the latter a little bit of a disservice by continuing to run the
non-DFSG-free program qmail on the machine that hosts our
mailing lists.
Our mailing lists are the lifeblood of our Project, and I think it's a shame that we might be slighting various fine -- and DFSG-free -- Mail Transport Agents (MTAs) through omission.
In my tenure as DPL, I'd like to do whatever is feasible to transition official Project infrastructure away from non-DFSG-free software. A question in the business world that I've heard from time to time is: "Do we eat our own dog food?" -- meaning, of course, do we trust our own operations to the tools that we claim are sufficient for use by the rest of the world? I think the answer is: yes, we can -- but in some places, we don't. Not because we doubt the quality of the Free Software we devote our labor to, but because at some point in the past, the best way we could serve the needs of our users was to place our trust in a non-free tool. For our mailing list server, I believe that time has passed. Transitioning our list server is no small job, and doing so without disrupting our development process is a serious business. As DPL, I'd like to recruit volunteers to handle this task and prepare a schedule for executing a transition.
As a Debian developer, I'm proud of the work that we do, and I see no
reason not to trumpet the virtues of Free Software -- including its quality
-- not just from the rooftops, but from our Received: headers
as well.
Conclusion
Thank you for your attention, and I hope this message has not been overlong. I welcome your feedback on my platform, and I strongly encourage you to vote in the forthcoming election.
Rebuttal (14 March 2002)
At the invitation of the Project Secretary, I'm taking this opportunity to
make some statements after having read my fellow candidates' platforms, and
followed various topics of discussion on the debian-vote
mailing list.
Neither Raphaël nor Bdale were ill-advised to run for Debian Project Leader. Both have clearly identified challenges facing our Project, and both have many merits. I honestly feel that we have a strong slate this year, which has not always been true in the past. I can easily imagine a Debian Developer being torn between all three candidates; I think we all have something to offer, and I doubt any of us would do serious harm to the Project if elected.
However, not doing serious harm is not the same thing as being the best of the potential candidates. The best candidate will move Debian forward without sacrificing the Project's identity, and without alienating developers or the community. The best candidate will not necessarily be the most popular or technically accomplished candidate, but the candidate who has the strongest grasp of what it will require to lead the Debian Project effectively. This is an important distinction. I have admiration for Raphaël's large-scale ideas on the technical front, and I have respect for Bdale's emphasis on vision, as well as his innumerable accomplishments.
While I think Raphaël is a strong candidate, I think he has a weakness in
that he is not as woven into the social fabric of Debian as I am. I
routinely communicate with the current Project Leader, and a great many of
the existing delegates. I am a known quantity to the people I will have to
deal with every day. I've also played a part in many technical and social
facets of the Debian Project. I'm an officer of SPI; I am a well-known
fixture on the #debian-devel IRC channel, where much
discussion and planning -- both short-range and long-range -- takes place.
I've been to four conferences, manning the Debian booth every time,
socialized extensively with many prominent and familiar developers, work a
day job with several, and I've even shared hotel rooms with other Debian
developers, and we all came out of the experience alive. :-)
On the technical front, I've participated extensively in discussions of
Debian's internal processes, tackled thorny issues like the SDL and static
X extension library debacle, negotiated license changes with upstream
authors, and participate regularly on debian-legal, where our
Free Software Guidelines and occasionally even our Social Contract are put
to fresh challenges on a regular basis. I have a strong barometer for
where we're at, and where we're going. In summary, I feel I am more
involved in and familiar with our Project and its people than Raphaël is.
I had the privilege of meeting Bdale last fall in Colorado. At the time, he expressed to me an opinion that Debian is more in need of "revolutionary" change than "evolutionary" change. This is a point he reiterated in his platform, where he said: Unfortunately, I think it has been a long time since Debian had a clearly articulated vision. It's time to fix that.
With the above sentiments I must disagree. I think revolution is only called for when things are so broken that violence (be it literal or metaphorical) becomes necessary to effect change. I don't think Debian is at that point. I think that, more than projecting visions onto the Project, the Leader needs to reflect what the Project is. And, with regards to the specific aspects of vision for which Bdale feels Debian needs corrective action, I think that we are on the whole doing quite well:
Take quality for instance. Bdale appears to acknowledge that
tools like debhelper and lintian, and resources
like the Build Daemon graphs and
statistics illustrate that Debian doesn't make empty promises about
improving the quality of the code in our distribution. I think that recent
trends on the Release-Critical bugs
graph also illustrate this point. Here, I think Debian's fundamentals
are sound, and we are in need only of evolutionary, not revolutionary,
change.
Similar things could be said for most of other Bdale's points. I'm
having difficulty reconciling his bold rhetoric with most of the issues
he's identified as problematic. I agree that all of the issues he's cited
are important; I also don't see any of them as being areas where Debian
isn't already improving, or where everybody knows we need to improve and
every candidate has already pledged himself to action (such as the release
cycle.) He mentioned usability; I've been trying to make XFree86 easier to
deal with since I first took over the package, and I've received a lot of
praise for my efforts. I'm hardly the only person who has effected such a
change in his package, or in the system. The importance of
debconf, which is a relatively recent innovation, can hardly
be overstated. Its pluggable backends (LDAP, text file) and frontends
(readline, dialog, GNOME) give us just about all the power we could want to
make Debian as user-friendly as any operating system, if not more. These
exciting features are attracting people's interest and labor, and lo and
behold, Debian's usability is improving.
I do not believe that Debian has stagnated. Only someone who conceives of the "potato" release as being all that Debian is could possibly think so. As I stated in my platform above, I conceive of Debian first and foremost as a group of people -- on the whole, talented, intelligent, imaginative, and without question dedicated people.
As Project Leader, I don't wish to subordinate the vision of other people
in Debian to my own. Some might consider that a weakness; I consider it a
strength. I believe the Debian Project Leader should lead only where
leadership is required; the rest of the time, he should make sure he isn't
getting in the way! I have complete confidence in the Debian Project to
find its own path to the future. Four different Project Leaders over the
past five years have done nothing to shake that confidence. We have shown
ourselves quite capable of thriving despite changes in leadership, and
without leaders who felt a strong desire to change Debian's vision.
It's possible Bruce Perens felt this way, but he left the Project and I
think the general consensus is that we're still around. :-)
Our sluggishness to release is certainly a problem, but it is one of which every developer is painfully aware. We are all already motivated to fix this problem, come hell or high water. I do not think we should become so obsessed with it that we permit it to eclipse the other things about our Project that are important, like giving Developers and the Project Leader's Delegates the freedom to do what they do best.
That's why I feel I am the best candidate for this job. By and large, I think we're doing things right. When we don't, we've proven that we have both the intelligence to identify that fact, and the will to act; sometimes, all we're missing is the machinery to get the job done. That's the reason delegation is my highest priority -- by and large, I trust my fellow developers to do the Right Thing. I hope that I have earned your trust as well.