Interview with DPL Branden Robinson

No. In and of itself that is not a bad thing; it's better to have a surfeit of ideas than a paucity of them, but even so I found the position to be a subtly different kind of challenge than I expected.

Still, I learned a great deal about the inner workings of the Debian Project's infrastructure that I don't think I could really have come to understand any other way. I look forward to being a resource for the next Debian Project Leader.

The important work that Debian has to do will continue.

In ways, it has. The DPL team was valuable to me in my role in that I think it was essential in either keeping me informed about various behind-the-scenes happenings, or in offering differing perspectives on things I already knew about.

I think so, yes -- however, the DPL Team had a big problem with visibility to the Debian Project at large, and that was a significant liability. It felt to me like the DPL Team was constantly engaged with somewhat sensitive personnel issues that were difficult to air publicly in a way that was both constructive and fair to all the parties involved.

The level of harmony within the team, however, was very high, and it was a good working environment. We all exhibited respect for each other and were able to work constructively even where we had differences of opinion. I had been afraid that we wouldn't gel, and with the exception of one member who simply didn't (and doesn't) have the time to participate, I think we did.

Quite apart from who wins the DPL election, I value the stronger relationships I've forged with Debian developers over the past year, both within and apart from the DPL Team.

When it comes to the team approach being continued into the coming year, I think it's inevitable. Whether it's called "the DPL team" or "Project Scud" or doesn't have a name at all, but is instead "the guys the DPL drinks with at the pub", I feel certain the concept will continue to exist in some form, just as it predates its explicit identification last year.

The role of DPL is a multifaceted one, and it's just plain good leadership to share the responsibilities. Just as the DPL has the trust of the developers, so too must a DPL demonstrate trust in others. The best leaders find ways to trust new people, rather limiting their horizons.

I'm particularly happy that the day-to-day machinery of Debian, of package maintenance, quality assurance, release management, propagation of unstable packages to testing, and so on, continued to hum along as it should. Debian's technical processes are, for the most part, highly developed and mature, and not something the Project Leader needs to meddle with. That was deliberate in the design of the Debian Constitution, and I think that is a point of continuing success.

The Sarge release, and, critically, the maturity of the d-i (debian-installer) project are also achievements I'm enthusiastic about. I don't claim credit for them in my capacity as DPL, except insofar as I was smart enough to know not to meddle with something that was working. Our release management processes have started to seriously hum over the past year. I think we really have a handle on management of major transitions. The BTS has seen major improvements, the devscripts package has more useful tools, and more people are leveraging these new features to get their work done.

On the downside, I'm particularly unhappy that a few particularly thorny issues occupied virtually 100% of my time. I made a conscious decision even before I was elected to grapple with what the Project has identified as the most critical issues, not necessarily those where I could make a big splash for myself or grab headlines.

One consequence is that things I have achieved are difficult to measure; another is that I didn't have much time left over to work on even the somewhat strange things I consider "fun", like coming up with a new set of trademark usage guidelines. That's still being managed ad hoc, and it doesn't really need to be.

It pays to keep in mind, though, that the most visible thing Debian does is get free software to our users. That's the primary mission, and every time I dwell on my frustrations, I need to remind myself that Debian is fundamentally succeeding in that mission. The free software landscape is littered with the remains of projects that have failed in it. Consequently, it is invaluable to maintain one's sense of perspective.

There are factors on a few fronts. As you may gather from my previous answers, I have a bit of battle fatigue. More importantly, however, I have come to appreciate the wisdom that a few people in the Debian Project have already expressed. First, you don't necessarily have to be the DPL to get things accomplished. The DPL is not a strong executive under our constitution, and some of the DPL's constitutional powers, such as the dismissal of a delegate against his or her will, have never been exercised. Secondly, many developers don't seem to really appreciate the first point. It's often been remarked that the Debian Project only seems to seriously grapple with internal management issues once a year during the elections. In between, most people seem to just wait for the Project Leader to pull a rabbit out of a hat.

While it's certainly possible that a more talented leader than myself could do so (or simply be the straw the breaks the camel's back), it would be healthier if more developers were more involved with those issues.

What I'd like to do next is see if I can mold myself into an example of what I'm beginning to think of as the "good Debian citizen". I've had the benefit of an "insider's view" of what's right and wrong at the core of the Project -- what I think is critical now is to better uphold clause four of our Social Contract, in which we commit to openness with our users. That clause talks specifically about bug tracking, but many within the Project think we should apply it more generally.

Some Debian developers have an ambivalent relationship with the Project's "insiders" because, simultaneously, they are details of infrastructure management that most of them don't care to know about -- except when they're perceived as not working. In that case, they demand satisfaction. I don't particularly decry this so much as note it to be human nature.

Infrastructure reform, which seems to eat every DPL that dares to grapple with it, will threaten to do so with the next leader as well.

It has been a tremendous honor to serve my fellow Debian developers and users in this office. I've had a few opportunities to speak before audiences familiar with Debian during my term -- the Open Source World Conference in Màlaga, Spain, and at Free Software and Open Source Days in Istanbul, Turkey, are two recent examples.

Everywhere I go in my capacity as a Debian representative, I meet many people who have boundless enthusiasm for the Debian Project and the work that we do. In many cases these are people who are as young as I was when I started using Debian, ten years ago, or even younger. Many of them want to be involved but want advice on how to contribute -- they don't know if they have anything to offer the project. The advice I offer is simple: identify something you care about, where your natural interests tend to flow, and throw yourself into it. A GNU/Linux distribution is an infinitely improvable thing -- that is, we're never going to run out of ways to improve it. When there aren't features to be added or bugs to be fixed, there are translations to be made, documentation to be written, or licenses to be fixed. It seems basic to Debian old-timers, but it's a new insight to Debian's vigorous youth.

At the GPLv3 launch conference in Boston this past January, I troubled Eben Moglen for a recipe on how to grow the Free Software community. His advice was simple, as most good advice is: "Each one, teach one." Over the past year I've been able to impart just a little bit of my meager knowledge to a great many people. That has been the most rewarding part of this job.