Platform for Branden Robinson

Introduction

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 2001, 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 in the United States. Late last year 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'm often found on other Debian mailing lists as well. I am 28 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 either of my DPL Platforms from the past two years. Since I have run twice before, unsuccessfully, this year I questioned the utility of running again, and wondered whether my perceptions of where this Project's problems and opportunities lie were widely shared. Rather than attempting to guess at the answer, or engaging with people in informal conversation in effort to gauge the degree of common ground, I decided earlier this month to circulate a questionnaire among Debian Developers via the debian-vote mailing list. This, I felt, would give me some more concrete, if not strictly scientific, data to work with. The experiment paid off. I received 73 replies, of which about 60 were from Debian Developers (the remainder were from Debian users, most of whom are in the New Maintainer queue).

While I have done no rigorous quantitative analysis of the questionnaire results, I actively solicited free-form commentary within the questionnaire, and most respondents were apparently happy to oblige, and were very free with their opinions. Moreover, there were some recurring themes in the replies -- themes which include points of concern that I share. Therefore, I have concluded that there is a significant number of Debian Developers who would like to see the next Project Leader attempt to tackle some specific issues. Consequently, I am standing as a candidate again this year, and I pledge to do what I can to address those concerns.

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. A Project Leader will need to be flexible enough to cope with problems and opportunities as they arise, and as he or she learns more about them. A Project Leader needs strategies, but not necessarily a generic recipe that is applied to all issues. 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.

Some of the respondents to my survey are a bit disenchanted with Debian's constitutional system of governance. I still feel as I did last year: Debian's democratic, constitutional foundation is a sound one. Our Constitution is, however, not directly applicable to how everyday decisions get made in the Project. Neither is it, I feel, an instrument of last resort. Instead, it is a tool that is well-suited to solving certain kinds of problems, and making certain kinds of decisions. It is less well-suited to others. In my opinion, the Constitution is good for three things: distributing power and responsibility within the Project, resolving important issues that are contentious, and soliciting the input of every Developer where appropriate (as in Project Leader elections).

The role of Project Leader is an important one. The DPL is the Project's primary representative and spokesman, both internally and externally. 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 strive to maintain an environment that encourages experimentation, novel problem-solving, and reinforcement and reward for the volunteer spirit that is the backbone of our Project. Finally, the Project Leader must be able to present Debian's "best face" to the press and other people and organizations.

Delegation and Accountability

The central -- and overriding -- issue to my mind about the role of DPL is the process of delegation under the Constitution. I feel as I did last year -- delegation is potentially a great mechanism, whose potential has not yet been realized as I think it could be.

First and foremost, I think we need more visible delegates from the Project Leader. For the most part, Debian Developers have very narrow bounds within which they can exercise their personal discretion. 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, or because there is a single point of a failure, and only one person is doing a particular task.

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. The DPL need not necessarily assume personal and direct responsibility for the problems of the day, but rather he or she should delegate responsibility for these duties, and set clear and reasonable expectations for their fulfillment. 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. The DPL must also follow up with the delegates, and ensure that they understand their responsibilities; not just so that they know what is required of them, but so that they know what is not required of them. Because this is a volunteer project, it makes no sense to heap more upon a delegate than can reasonably be borne. It is primarily the Project Leader's responsibility to recognize the situation and act when a delegate is overwhelmed. Any task that can benefit from parallelization and a team approach should receive one, as long as qualified delegates can be found to do the job.

My perception, and that of many of the respondents to my questionnaire, is that we don't presently have enough delegates, and we particularly don't have enough in some key areas of infrastructure.

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 specifically dedicated to DPL delegates: it should enumerate them, describe each one's responsibilities, state the date each one's term began, and provide a link to each delegate (or team's) webpage where they can post news and status information, where applicable. Delegates should be directly involved in establishing their own standards and responsibilities; this is not only more fair to volunteers, but this should also serve to get the DPL and the delegate off to a good start in having open channels of communication. The best goals are those we are free to set for ourselves. While the DPL cannot single-handedly ensure that everyone's goals are met, he or she can at least develop a strong knowledge of the Project's strong and weak points in the delegation structure, and solicit volunteers to reinforce the weak points.

Other Issues

There are some other things I'd like to accomplish during my term as DPL, but they all take a back seat to the above.

Refereeing internal disputes: if delegation and accountability is the DPL's primary focus, then this surely is the top-ranked task in the second tier. A great many survey respondents felt that the DPL must highly prioritize efforts to resolve disputes internal to the Project. While I largely agree, I do not feel that this should be priority number one, at least if the DPL is expected to be a sort of diplomat. No one (at least, not anyone who's actually getting any work done) has the time to try and quench every flamewar. I do think, however, that when an internal dispute rages for a long time and/or substantially impedes productive work within the Project, the DPL should strongly consider stepping in. If the DPL has a novel perspective or path to resolution to offer, he may consider presenting it. For the most part, however, I think that important internal disputes will in most cases devolve to delegation and accountability issues (see above); where they don't, the best thing for a debate that seemingly won't stop is probably a General Resolution.
Attending trade shows and doing press interviews: these tasks are important for maintaining Debian's visibility to the "outside world". They are important, but they are also highly delegable. As DPL, I will not feel a strong compunction to attend as many trade shows as possible, or handle every press contact myself. While I will want to attend the most important trade shows that are within my financial means, I am happy to delegate the honor in cases where I cannot. Bdale Garbee, for instance, is an engaging and effective spokesman, and he is an example of a person to whom I could delegate the mantle of "Debian representation" with complete confidence. In many cases, though, Debian is best represented simply by the number of dedicated, energetic, and friendly developers we muster. When it comes to press or other external contacts, I imagine that in many cases, the DPL is the person whom people contact simply because they don't know of anyone else. When I'm not the best person to whom to address an inquiry, I am more than happy to forward it along to more appropriate personnel.
Establishment of a "developer emeritus" status for inactive developers is very widely regarded as a good idea; the only real hurdle appears to be simply finding someone for the task of implementing the technology and working with the Debian Account Management (DAM) team to ensure that it's used. As DPL, I'll definitely want to look into this.
Finally, I would be interested, if response is positive and if the Project Secretary is amenable to the idea, of using our voting machinery to periodically circulate surveys about issues of the day. These would not, of course, by anywhere near as comprehensive as the questionnaire I posted earlier this month; I am thinking instead of possibly circulating a survey listing several options about the possible disposition of the non-free section of the archive (since it is one of those flamewars that flares up occasionally with great violence, never truly dying). By using the Condorcet method, we can learn without a binding vote how the Developers really feel about the issue, and this data might be very useful in deciding whether to try and move forward on some sort of General Resolution, and if so, what sort of ballot options appeal to people.

Conclusion

Thank you for your attention. I welcome your feedback on my platform, and I strongly encourage you to vote in the forthcoming election.

Rebuttal

The Project Secretary has afforded the candidates and opportunity to rebut the platforms of the other candidates. My thoughts on each follow.

I disagree with Moshe Zadka's philosophy of leadership ("I promise to do as little as possible"), at least when there are known, significant problems within the organization being governed. It is perhaps easy to mock Mr. Zadka's approach, but anyone who does so is probably ignorant one important aspect of leadership: knowing when to keep one's hands off. A leader who tries to do it all himself will likely succeed at accomplishing nothing, or making things worse. That's why I have placed so much emphasis on delegation. As DPL, I will be conscious of the need to empower others, ensure the presence of good communication channels between delegates and the Project, and do my best to let both succeed. With regard to Mr. Zadka's specific campaign planks, I cannot say that I perceive much in the way of problems that need solving: I do not think there has been a problem with SPI misusing Debian funds; I am not cognizant of a movement within Debian to make it an explicitly political organization; I do not perceive much remaining of the past hostility between the Freenode and OFTC IRC networks; and I am not aware of any efforts to undermine English as the lingua franca of the Debian Project, nor any efforts to freeze out translation efforts to other languages. It is possible that Mr. Zadka shares these impressions to some degree, which may explain why he feels a passive DPL is a good idea. My diagnosis of the Project's ills, however, is different.
I find Martin Michlmayr's platform more difficult to critique because it reminds me a lot of my own from last year. I think Mr. Michlmayr has many good ideas but, as he recognizes, many of them can be done without the benefit of the DPL's mantle of power. Mr. Michlmayr places too little emphasis, I think on systematizing and structuring the delegation process; he recognizes that the main aim of the DPL should be to "lead, motivate, and coordinate", but he does not present concrete proposals for fulfilling that mission, as I have. If elected, I would hope that Mr. Michlmayr would be interested in a delegate's position to tackle one or more of the problems he has identified.
Finally, we have the incumbent's platform, that of Bdale Garbee. I am not certain that Bdale even needs a platform, given that we advantage of his past year of service to reflect upon. Bdale has been, by all accounts, an outstanding spokesman for the Project to the outside world, a dedicated participant in the IA-64 porting effort, and a solid package maintainer. However, I -- and many of the respondents to my questionnaire -- am not certain that Bdale's tenure as leader has turned out as he projected in the platform upon which he was elected. This is not to say that Bdale's accomplishments haven't been worthy of credit and recognition -- far from it. It is my feeling, however, that the Project could do with more shoring up from the inside, to ensure that we operate more smoothly (one might say that this is my personal take on Bdale's concept of facilitation). In his 2002 platform, Bdale spoke of several issues: values, vision, quality, release predictability, user first impression, (technological) infrastructure, security, and the Linux Standards Base. All of these are indeed important, but we've seen little direct followup on most of these issues by Bdale himself. We did in fact release Debian 3.0 ("woody") during Bdale's term, but that release was pretty far along when he took office, and more to the point, we don't seem to me tumbling headlong towards another release at present, which doesn't do very much for the plank of "release predictability". I think the Release Manager has most of the responsibility for making releases, and any credit or blame to be assigned lies first and foremost with that position, and secondarily with the Developers as a whole -- I think it is difficult for a leader to command a release to happen. The security team has been doing a bang-up job, but I gather they managed this largely under their own power, as the term does not appear in Bdale's 2003 platform. Quality, user first impression, and the Linux Standards Base are all other items from Bdale's 2002 platform that have received little followup in his platform for re-election. Of course it is not necessary for Bdale to recapitulate, point by point, his platform from 2002 when running for re-election, but when I checked for a "bits from the DPL" message to find other follow-up data on the points, the most recent one I could find was from 17 September. Perhaps all this means is that Bdale was too ambitious in his earlier platform; we could certainly do worse than to have Bdale as a Project Leader. Still, there are some internal problems that existed in April 2002 that have gone largely unresolved in the past year -- if you share my thoughts about what they are, you may feel that I'm a better candidate this year. Bdale has drawn his focus more narrowly for this year's platform, and that's a good thing: his major planks are release flavors, internationalization, and the Project's communication with its userbase. These are all noble goals, but I'm not sure one needs to be Project Leader to make headway on them. Bdale appears to have a talent for the latter in particular, and I applaud him for that. I'd be delighted if he'd share his thoughts with me on how to further each of these goals if I am elected this year.

I am not going to conclude with a rhetorical prophesy of doom or irrelevance for the Project if any other candidate is elected, since I don't feel that's the case. I am also not going to imply that no one else is capable of providing "clear and effective leadership", to quote a platform from years past. I will instead rest on my analysis of Debian's strengths and weaknesses, my stated priorities, my record, and my experience. I urge each voter to take these factors into account for all candidates, consider carefully, and make the best possible decision you can make. It is my hope that if you share my perspective and goals, that I have inspired your confidence, and that you feel the Debian Project would be better served with me as your representative for the next year.

Thanks again for your attention, and for your part in making the Debian Project such an exciting place to be.