Platform for Branden Robinson

Introduction

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 for almost six years, since March of 1998. From August 2001 to February of this year, I served as Treasurer of Software in the Public Interest, Inc., Debian's legal parent organization and manager of the Debian Project's assets in the United States. In 2002, I joined Debian's team of Policy Manual editors. I am a fixture on the debian-legal mailing list, and participate with other developers in the vetting and analysis of the terms and application of various software licenses, and how they mesh with the Debian Free Software Guidelines (DFSG). Of course, I am found on other Debian mailing lists as well. I am 29 years old, employed as a free software developer, married, and have no children.

Over the past year, the work I've been proudest of has been the transition of Debian XFree86 packaging effort from individual-based to team-based. In doing so, I have vastly increased the day-to-day visibility of the work that goes on in Debian's packages of XFree86, and the integration of changes large and small has picked up tremendously in pace. The public availability of a Subversion repository allows anyone to check out and build the forthcoming packages, submit clean patches, and review the changes that are made for errors. The transition was quite a bit of effort when pursued simultaneously with package maintenance, but the investment has already paid off in terms of greater openness and peer-review, and I think it will pay off even more in the future with greater delegation and task-sharing. I emphasize this work because many of these advantages to managing software development translate to project management as well, as I will show.

First I will explain my motivations for running, and then I will describe the actions I intend to take if elected.

Why I Am Running

We need improvements to our processes.

Most of Debian's worst internal conflicts (or "flamewars") over the past few years have revolved around three issues:

All too often, I see discussions of these matters devolve into yelling about two alternatives: "person X is holding us back from progress" vs. "things are working just fine, and your complaints don't do any good".

These types of arguments, in my opinion, and for all the time and pages of email text that is spent on them, miss the point. It is my belief that we have these disputes because relevant information is too difficult to acquire, and there are insufficiently-developed forums for resolving non-technical complaints or grievances.

More simply, it's too hard for those who are "clueless" to get clues, and in the absence of proper procedural remedies for dissatisfied people, arguments become personalized. That, in turn, puts people on the defensive (sometimes for themselves, sometimes on behalf of others), and recriminations spiral out of control.

In my opinion, and on balance, we do an adequate job on these points. If they were really terrible, the Debian Project would not be a going concern. Many people feel the release cycle is too slow; that may be, but one should attempt to recall some of the many Free Software projects (or even distributions) that are no longer around because they could never even reach version 1.0, or could not sustain their development. Our new-maintainer process also works too slowly (and sometimes too mysteriously) for some people, but we're doing a lot better than when we weren't allowing new maintainers into our project at all. It should also be obvious, that from system administration to the mailing lists, the build daemons, and the bug tracking system, things essentially work, and they essentially work smoothly. I think it is unwise to invest observable problems with a lot of drama; unfortunately, I suspect we may unwittingly encourage this sort of drama because it's the only alternative some people see to having their complaint completely ignored.

Good is good, but we can be better. Adequacy is adequate, but we should strive for excellence. I look forward to making us better at what we do.

We need more open and visible processes.

Improvements are less valuable, and less likely to be acknowledged or even noticed, if they happen invisibly. Similarly, it is hard to know what to fix if it's not clear what's wrong. We have seen people's suggestions for improvement dismissed because they didn't have the facts in their underlying complaint straight. While I certainly sympathize with the desire to see accuracy in the complaints people lodge against our project and the work we do, it is not always the case that a factual error in presentation renders a problem nonexistent. I have seen people spend tremendous amount of effort correcting and rebutting such errors, sometimes in a highly irritable tone.

Interactive communication can be very inefficient. In many areas, documentation of how our project works is nonexistent, inadequate, inaccessible, or simply too difficult to find. I suspect we can help to insulate our most trusted infrastructural managers from off-the-mark criticism if we both improve our presentation of factual information about how we work, and have a more structured method for elevating such complaints to the appropriate people. It would be nice to separate the wheat from the chaff -- the valid complaints from the mis-informed ones -- in an open and visible way, so people can see not just how it works, but that it works.

We need a leader who will champion our cause.

In my job, I have the privilege of talking to people in industry (and not just in the U.S.) about what they need out of a GNU/Linux distribution. I seldom see cases where there isn't an opportunity for Debian adoption. (The exceptions are people who seek Red Hat or SuSE compatibility -- or the RPM package format -- for its own sake, and not because of what they're actually trying to accomplish with a computer.) I have seen interest in Debian grow tremendously over the past four or five years. Debian has spawned many subprojects and compatible forks, which helps us to live up the "universal OS" moniker.

Debian is making inroads, seemingly everywhere; I want to accelerate that process and evangelize Debian everywhere I can. I don't see the phenomenon of subprojects or compatible forks as a threat to us at all; instead, it is a beacon of our success. It's my opinion that it is within our power to make Debian a de facto industry standard; the company I work for achieved certified LSB compliance for a snapshot of Debian "sarge" in January. I was enthusiastic about Debian from the day I became a maintainer, and I'm still excited today. Furthermore, I can effectively communicate that enthusiasm and excitement to an audience.

We should take our Constitution more seriously.

I was disappointed to learn back in November that the current project leader doesn't feel that the delegation process in our Constitution is the way Debian really works. He characterized a refusal to make delegates of the archive administrators, system administrators, and so forth as "pragmatic". Whether that is true is something I'll let our developers and users decide for themselves, but I do know that this stance runs contrary to our Constitution as I understand it. Our website calls the Debian Constitution "the document of utmost importance to the organization". Given that, I think we should pay it a little more respect. The Debian Constitution recognizes six decision-making bodies or individuals: the Developers (acting as a group via a General Resolution), the Project Leader, the Technical Committee, the individual Developer working on a particular task, the Project Secretary, and delegates of the Project Leader.

We need to respect the delegate process, or amend it. I don't think every "particular task" in the Project is the same as maintaining a package. The roles of archive administrator, project keyring maintainer, and project system administrator are important. In practice, we distinguish these roles from that of package maintainer in many ways. They are of particular importance and merit special attention. I do not think they can reasonably be lumped into the same category as the individual package maintainer. They have special powers and should be treated specially. The concept of the delegate in the Constitution was drafted with such roles in mind. That no previous DPL has taken the obvious step is a disappointment to me.

The Debian Constitution describes the process for electing the Project Leader. This was done in the expectation that the role would be important. We should have a meaningful contest between candidates, because the process will help us understand who we are and where we're going. I wouldn't run if nobody could see any problems that the Debian Project Leader were empowered to solve.

I was asked to run.

I performed well last year in a very close three-way race, and I am running again to see to it that the needs of our developers and users are met. The process of campaigning is not the most enjoyable for me, nor do I expect having to address the problems I see as necessarily being a barrel of laughs. After I asked the opinion of our developers on the debian-project mailing list, however, many mailed me to urge me to run, and they had very consistent views on what is wrong with the Project and what I can do about it. These are responsibilities I am willing to accept, because I care too much for the Debian Project to not give it all the energy I can.

What I Will Do

Now that some of our challenges and opportunities have been spelled out, the solutions seem fairly straightforward.

I will establish mechanisms for making our processes more visible.

I am setting up an installation of Request Tracker (Debian package request-tracker3) on a machine I own to serve as an "ombudsman" (dispute resolution) site. The Debian Bug Tracking System is, in my opinion, not well-equipped to handle non-software problems, and mailing lists, as we've seen time and again, are frequently a poor alternative. I am experienced with Request Tracker usage in my job, and it is not difficult to learn. Should this experiment prove successful, I will work with the Debian System Administrators to move the installation to a Debian Project machine. Additionally (and with greater emphasis if this experiment fails), I will pursue other avenues for making our project's operation clear where it is presently opaque.

I will work with my delegates, with the developers, and with the users to identify specific areas that need improvement, including release management and the new-maintainer process.

I will take the obvious step described in the previous section, and formalize the delegate status of the many important people who do critical work for our project who do not already enjoy delegate status. In the event I cannot do so, or am persuaded that this is a bad idea, I will explain to the entire project why I cannot, and then, if necessary, propose a General Resolution amending our Constitution to reflect the facts of Debian's organization.

I will make regular reports to the developers describing my activities as Project Leader.

I have been disappointed with the frequency and content of reports by the Project Leader to the developers over the past couple of years. As Project Leader, I will make a report at least once a month to the developers about my activities in my elected role. These reports will not be limited to descriptions of conferences I have or will be attending, or high-level overviews of the state of the Project; in addition, I will describe specific tasks that I am working on and problems that I have been asked to resolve.

I will respect and reinforce our constitutional system of government.

I will do everything I can to ensure that our real organization reflects our Constitution, and vice versa. A project that pays no heed to its foundational documents and principles is a project in trouble, and can harm the impression we make to those aren't familiar with the way Debian really works, expecting to find out by reading information on our Web site that purports to tell them.

I will reactivate the Technical Committee -- which has fallen dormant again -- or amend the Constitution to replace it with a body that works better. That almost a year has gone by with no mail to the list (apart from a test message by Wichert Akkerman), let alone a dispute to resolve, makes me suspect that this body has lost the confidence of the developers. I'd like to work with the members of the Committee that are still interested in serving to see how this body can be improved and revitalized.

I will respect the value and contributions of each of our developers.

The Debian Project, according to our Social Contract, exists to serve our users and Free Software. To do this effectively, the Debian organization must serve the needs of all of its developers as a group. This is sometimes a challenge, as we are a diverse body, and our members are spread all over the world. This challenge may sometimes tempt us to deal preferentially with our friends in the project, or with those in close geographical proximity to us. Yielding to such temptations, however, creates unfairness and inequality among the developers. Debian should be a meritocracy, and merit should be measured by one's contributions to the Project, not by a developer's nationality or non-electronic social relationships. Debian was born on the Internet and could not have existed without it. The ease of electronic communication is our greatest asset, and the most effective leveller of inequities that we possess. We must not abandon this essential attribute in favor of provincialism of any variety. Developers who cannot attend our annual conferences, or other physical gatherings, must not be treated as less valuable. We would do well to remember the tremendous contributions of Joel Klecker, whose contributions were not dimmed by the near-impossibility of his joining a physical gathering of developers.

As Project Leader, I will strive to ensure that no special privilege system is established or maintained on my watch. I am certain that our most valuable contributors need no special advantages conferred upon them, and likewise we need not dim the potential of future contributors through practices that are in practice exclusionary, even if they seem innocent and expedient.

The more important a decision is, the more critical it is that it be made in an open and public manner with no procedural biases for or against any developer. This is a high standard, but an essential, and I promise to do everything within my power to hold us to it.

I will build relationships with other Free (Libre) Software and Open Source companies and organizations.

I will call for volunteers to serve as official delegates to other organizations where necessary. The current DPL appointed a couple of people to communicate with the Free Software Foundation regarding some of our developers' concerns with the GNU Free Documentation License and how that license interacts with the Debian Free Software Guidelines. The previous year, Bdale Garbee appointed Mark Johnson to serve as our representative to OASIS. I think those were great examples, and they're a phenomenon I'd like to build on. I do not see why we should not have an "ambassador" to the FSF, if you will, a person who understands the needs and interests of both organizations, and can help avoid unnecessary friction. The same could be done for Red Hat Software, Novell, FFII, FSF Europe, and so forth.

I will do everything I can to make the Debian Project a compelling example to follow.

Recently, a person mailed the debian-project list asking for advice on how he could use Debian as an organizational example for his not-for-profit software community. I was flattered, as I think we all can be, when I read that message, but as you can see above, we could be a better example than we are. In too many cases, an organization who wanted to follow our example would come to a disappointing realization that our implementation doesn't match our specification -- that we don't practice what we preach. Every project is unique, and that's why we should do a better job accurately explaining to the rest of the world what we do -- because that way, we can also take the time to explain why. In the process, we may come to re-examine the assumptions we have made, and through such a process we cannot help but improve.

As Debian Project Leader, I will be committed to making the Debian Project the type of organization where things are done right. We already have practically universal buy-in on this point when it comes to technical issues. Why should we settle for less when it comes to our organization?

I have been up to the challenges I have faced in the work I have done for the Debian Project in the past, and I am up to the challenge of being Debian Project Leader.

Thank you for your support, and for your participation in the project I believe in.

Valid XHTML 1.0! Valid CSS!

Validate this page's XHTML.
Validate this page's CSS.

$Id$