Interview: Branden Robinson

Branden Robinson has won the 2005 Debian Project Leader (DPL) election. Robinson, who has run each year since 2001, was chosen from a field of six candidates. His term begins on April 17. Before Robinson assumes the role of Project Leader, we asked if he'd answer a few questions about his plans for the next year, and his thoughts on some of the issues facing the Debian Project. LM: You've run for DPL several times, how does it feel now that you've won? It was initially a bit of a surprise. As you may be aware, it took a "Draft Branden" campaign to even get me to run for the position this year. While I did nothing to discourage that campaign, I was feeling pretty battle-weary from the previous contests.

Now that I’ve had a few days to wrap my head around the reality of attaining something to which I’ve aspired for years, I feel deeply humbled by the authority with which I have been entrusted. While it’s tempting in some ways for me to look at my election as the culmination of a long process, I know that a better way to approach this office is too look at it as a beginning. I’ve been exercising my leadership skills to a lesser degree for years, but now I feel like a piece of code that’s been through QA but is now in production. The real-world tests of my character and talent begin now, and the past is merely prelude.

LM: Now that you’ve been elected, what’s your roadmap for the next year? What do you plan to do?

My top priority is to ensure that I don’t frustrate or slow the Sarge release process in any way. People who aren’t familiar with the details can easily write off our recent claims of our being “almost ready” as more glibness, but it truly does feel like we’re close. The Release Critical bug count remains under control, the Debian-Installer developers and users are now finding the code so stable and acceptance worthy that they’re beginning to get restless for new development, and we seem to have our big painful subsystem upgrades (such as GNOME and KDE) and ABI transitions shaken out.

The remaining sticking point is getting the wanna-build (binary package autobuilder) system properly on line for what we call “testing-proposed-updates”, which is an upload target like “unstable” or “experimental”, but whose purpose is to allow us to provide security and bugfix updates to Sarge. We need to have that working and tested before we can release Sarge; if we do not, the perversity of the universe will see to it that the day after we release Sarge, a remote root hole will be discovered in the Linux kernel, OpenSSH, or some other critical piece of software, and our infrastructure for moving updated packages through our system for all of our supported architectures won’t be ready.

Over the longer term, I want to make progress on several fronts: first, I want to put some tender loving care into some other areas of Project infrastructure that are often complained about. This means cultivating an understanding of why things are the way they are, and how they can be improved. I expect the leadership team of which I am a part to be invaluable in this area, and several of the members possess more intimate knowledge than I do.

Secondly, I want to capitalize on Debian’s continuing position as the most significant GNU/Linux distribution to be unfettered by corporate entanglements. That position enables us in many ways to serve as a conscience for the community, and I’d like to put that into stronger relief during my tenure. To take just one example, for years we have been lamenting the proliferation of free software licences, or clumsy approximations thereof. It’s heartening to see other organizations like OSI and HP join us in that assessment. I think there are other areas where we can help raise awareness of the value of software freedom, if only we will use our voice to communicate our understanding.

Last but certainly not least, I plan to represent the Debian Project at conferences, to user groups, and to the press, and reflect our members and our work in the most enthusiastic and positive light that I can. I don’t expect that to be difficult — there is as much as ever to be excited about in Debian, and I think people will remember that once they have Sarge in their hands.

Throughout all of this, I will make regular reports to the Debian developers, as I pledged in my platform, so that the people who elected me know what I’m working on and where I’m having trouble making headway. There will be challenges; that’s inevitable. I think Debian’s developers are willing to tolerate something less than utter, jaw-dropping success on every conceivable front, if they’re simply kept in the loop. A recurring theme in recent DPL elections has been a lack of visibility on the part of the Project Leader, not necessarily to the general public, but to the developers themselves. I take this linchpin of accountability very seriously.

LM: Out of more than 900 eligible Debian Developers, only 504 valid votes were recieved – is this a sign of apathy on the part of the Debian Project, or do you think this is a healthy turnout?

While lower than previous turnouts, it’s not markedly so. I do think there is a bit of ennui, and I suspect that is largely due to frustration with the continuing lack of a Sarge release. I have elsewhere used a metaphor of pregnancy — Debian’s been carrying the child called Sarge for a long time, and it’s well-past term. Collectively, we have a bit more crankiness, a bit more moodiness, and the occasional fit of apathy. We’ll feel much better once we’ve delivered a healthy infant.

LM: Aside from the obvious (getting Sarge out the door) what are the big issues facing Debian over the next year? What can be done to confront those issues?

The Debian Free Software Guidelines, written in 1997, are starting to show their age a bit, and happily this is not because they were ill-thought out — quite the contrary — but because the concept of computing freedom has spread farther and wider than ever before. A review of the debian-legal list will show that the areas most vigorously argued about over the past couple of years are areas in which people have traditionally resigned themselves to servitude, rather than mastery over, the computing experience. It wasn’t so long ago that you could obtain, use, modify, and redistribute great software free of charge and without fear of prosecution, but to learn how to use that software to its full advantage, you had to buy (or otherwise obtain) a proprietary manual. Similarly, at the same time people are getting more and more comfortable with the notion of their computer’s CPU executing Free Software a significant part of the time, or even exlusively, hardware manufacturers are learning from the Cathedral and Bazaar principle of “release early, release often”. Instead of shipping hardware with working firmware mask-programmed into it, they’re relying on the user to load it dynamically, often because those users need to download fixes from the manufacturer’s website just to get a device to work.

This has raised the profile of those devices and the code which runs on them, and people annoyed with the buggy hardware and the tedium of vendor-provided driver and firmware updates are logically turning the same thinking to the issue that RMS did back in the early 1980s when confronted with a Xerox printer that he was not permitted to fix without signing his away his liberty to write code as he pleased. Twenty years hence, more and more people are struggling with the same choice RMS had to make. On top of what they pay out of pocket, what are people willing to give up just to be able to get their devices working as desired without frustration?

Another big issue facing Debian is now to better take advantage of and work collaboratively with the many Debian derivatives that exist. In most cases there is no sustained relationship, and no flow of patches back to the Debian Project reflecting the itches that a Debian derivative has scratched. We could do more to recognize the needs of these stakeholders, without, I suspect, having to sacrifice our independence.

LM: The relationship between Debian and Software in the Public Interest was brought up for the DPL debates – what needs to happen to make better use of SPI as a resource for Debian?

Simply put, more people need to care about it, and manifest that care by contributing something, just as they would for a software project. SPI is all-volunteer just as Debian is. Sadly, the types of work required to make SPI run smoothly are not exciting and stimulative of creativity in most people, or at least not the same sorts of people that enjoy hacking software, by and large. On the upside, the absolute number of people required to make SPI work well is not large — it doesn’t even approach the number of Debian developers. I think if we had two dozen people contributing measurable amounts of time to SPI on a consistent basis, the organization would be in great shape, not just to sustain itself, but to grow and to fulfill more of its original vision. What we also need are people willing to give props to SPI and the people within it when it does do something good. Some of the criticism of SPI has been harsh in the extreme, and while this criticism is often factually grounded (at least in part), I don’t think it’s reasonable to expect people to put their shoulders to the wheel when most of the feedback they get on their efforts is either stony apathy or apoplectic rage. While software hacking often has intrinsic rewards, the nuts-and-bolts of managing a not-for-profit doesn’t seem to.

To succeed, SPI will have to either have to attract a core team of martyrs for whom the slings and arrows don’t really cause pain, or it will have to have enough people paying attention to it that they notice when requirements are being met and progress made, and can weigh the occasional storm of invective against the facts they’ve collected themselves. A third possibility is to do enough fund-raising that we can afford to retain an Executive Director on an ongoing basis. Unfortunately, even that is no guarantee against internal dysfunction — I gather that OSI recently had to weather a substantial internal storm resulting from inattention by the Board members and other factors, and they’ve had an XD for years.

LM: The Debian Project, as a group, seems to have mixed opinions about Ubuntu. What are your opinions on Ubuntu – is it good or bad (or a little of both) for Debian? What could the Ubuntu team do (if anything) to be better for Debian?

Ubuntu is a mixed blessing, but one with a net positive. It has helped raise Debian’s profile in a mostly positive way (that it has thrown the unpredictability of Debian’s release cycle into stark relief is not their fault); it has served to excite people and attract them to the GNU/Linux system, winning over some adherents from proprietary OSes; it has attracted some of Debian’s more impatient users without losing them to Fedora, which keeps them in the Debian family while also satisfying them while we work to get our release taken care of; and it has provided gainful, rewarding employment to many Debian developers — it has helped give people jobs where they get paid to pursue their passions.

The downside is that Ubuntu has prompted some people to come to doubt Debian’s “relevance”. As a consumer of Debian’s OS with a derivative product, I think Canonical could do more to emphasize just how much of a service Debian does provide. If Debian were to vanish tomorrow, Canonical would be in a bit of a bind. They would have a great foundation to work from, but even with their relatively high staffing levels for a going Debian-based concern (I refer here to engineers and QA folks directly working on the Ubuntu distribution), but I have doubts that they could sustain it in the long term without Debian continuing to serve as this massive engine. Those who complain about the stagnation of Debian’s stable release in contrast to Ubuntu’s would do well to remember that Debian’s *unstable* distribution is the wellspring of Ubuntu’s stable one.

Finally, while I hope I’m misinterpreting this, I have seen comments from some Canonical employees that seem to regard Debian as more of an obstacle than a partner. If that’s accurate, I don’t think it’s a healthy attitude — a significant part of what makes Debian the success that it is, is its independence from corporate direction. Asking Debian developers to eat whatever Canonical feeds them is wrongheaded; as Canonical enjoys the freedom to deviate from stock Debian package where and as necessary, so too must Debian developers retain their independence.

To Canonical, and to Ubuntu’s volunteers, I say, “thank you for helping keep Debian great!” From them, as from any Debian derivative, I ask that they work as our partners. Be an advocate for your ideas — please don’t simply throw them over a wall and expect Debian to treat them as Mosaic tablets. Each organization must start from the premise that the other team consists of fundamentally ration people — and rational people tend to eschew appeals to authority, preferring logical premises instead.

I reiterate that this is a relatively minor problem. For the most part, I see high levels of cooperation, much friendliness and mutual respect, and good code flowing both ways. I think there are few challenges posed by Ubuntu that Debian can’t meet a with a Sarge release and a refactored release process.

LM: The concept of timed release cycles has been brought up a few times, how do you feel about this – is it viable for Debian?

I’d like to believe that it is. Working as I do for a company that makes distributions, I’m keenly aware of the high value that people place on predictability. It’s tough to plan for the unexpected, and easy to plan around regular periodic events, especially once they’re proven to be reliable. In speaking with various business interests that want to deploy Debian, Progeny has consistently observed in discussions with its customers and prospects that how frequent the Debian distribution revs is less a concern than that it be predictable at all. The success of Knoppix, Mepis, Ubuntu, and other Debian derivatives targeted at the consumer market tells me that predictability is not a value unique to the corporate world.

LM: There are those who feel that the process to become a Debian Developer is a bit too involved – do you think that it should be easier to become a DD, or is the process just about right?

My perception of the frustrations people have with the new maintainer process is not so much that it’s too difficult or Byzantine, but that it requires nearly superhuman levels of patience in some cases. People’s applications sometimes get stalled for reasons that aren’t clear to them.

I think part of the problem is simply that the new-maintainer team which handles the influx of applications is understaffed. This is an area I intend to educate myself better about shortly, and I hope to be able to make some helpful suggestions and improve resource allocation. I think we’d all like the obviously talented and astute applications to be able to join our ranks as quickly as possible, without giving up the objective measures that the current process provides us.

LM: Any final thoughts?

I am honored, humbled, and excited to be elected DPL, and I look forward to being not just the kind of leader I want to be, but the leader that the Debian Project needs. While I can judge the former, I must leave the latter assessment to my peers. With dedication, integrity, the support of my fellows, and a little bit of luck, I hope to serve as steward while Debian becomes an even greater force to be reckoned with in the software industry.

Comments are closed.