Distributions

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.

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.

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.

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.

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.