My platform posting from last year's DPL campaign [ http://lists.debian.org/debian-vote/2001/debian-vote-200102/msg00038.html ] is full of biographical information about me. One significant thing has changed since then...
In May of 2001 I accepted an offer to re-join Hewlett-Packard, this time as an Engineer/Scientist in the Linux Systems Operation (LSO). HP supports multiple Linux distributions on multiple processor architectures in a wide variety of product forms. That translates into lots of interesting work, and I'm enjoying the challenges.
Debian is our development platform in LSO for the kernel and related work required to enable Linux support on HP's hardware. That means I get to spend part of my time working on Debian, particularly the IA-64 port. But my job also includes:
One neat consequence of this job change is that I am now more able to attend and speak at Linux and related technical conferences than before. I attended ALS for the first time in Oakland last autumn, and recently returned from Brisbane where I spoke at Linux Conference Australia 2002 and in the Debian mini-conference that preceded it.
The Debian community is full of interesting people, and I really enjoy meeting many of you in person, putting faces to names, and gaining some personal context to improve the quality and effectiveness of our online discussions.
Effective leadership requires several things. The group must have shared values, must agree on a vision of what the future might hold if all goes well, and must develop and follow plans for moving from the current state towards the vision state. The primary role of the leader is facilitation, which comes in many forms.
As I have talked to other groups about Debian in recent months, our strongly held core values come up over and over again as a key reason for the success Debian has enjoyed. Other groups envy our ability to attract attention, motivate so many developers, maintain so many packages across so many architectures, and remain viable despite major organization and infrastructure changes over the years.
These key values are in no immediate danger. They are strongly held, and rightfully so. But nurturing them, acting in adherence with them, and continuing to communicate them as key elements of what is special about Debian are clearly things we should expect of our DPL.
Unfortunately, I think it has been a long time since Debian had a clearly articulated vision. It's time to fix that.
Back before we selected the swirl logo for Debian, our web pages sported a graphic composed of colored puzzle pieces, and the text "Debian: The Universal Operating System". Whenever I think about Debian, that idea is what comes first to my mind.
Every once in a while, someone on our mailing lists tries to assert that Debian can't or shouldn't be everything to everybody. It usually doesn't take long for someone else to reply "why not?". Why not, indeed? The Debian community is now large enough and diverse enough to support as many sub-projects catering to different user communities as we can imagine. There is no reason that we can't eventually be a truly universal operating system! I can't imagine a more compelling vision for our future.
But, if we are going to make Debian a truly universal operating system, we face a number of continuing challenges.
I believe the biggest improvements we've made in code quality over the years have come as a result of our porting efforts, and as a result of regularizing tools and processes for building quality into our packages. Achieving our vision will mean continuing those efforts, and finding ways to do more.
Our packaging policies recommend the use of -Wall when compiling, and most of our packages comply. What many maintainers may not realize, however, is that what is "just a warning" on one platform may be a fatal error on another. Now that the logs from our package auto-builders are available online, anyone can audit packages for potential problems, and we should encourage more people to help!
I'm a big fan of helper packages like debhelper, but not as a way for maintainers to avoid having to learn how to build correct packages... any more than calculators are an excuse for children to not learn how to add and subtract. Rather, I think reasonable use of helper packages does a lot to improve consistency of packaging and avoid silly mistakes.
I'm also a big fan of tools like lintian, which help us catch more silly mistakes that otherwise would reduce our archive quality. The tools we have today are not a panacea. I've done my share of ranting about checks in lintian that are just plain wrong, or overly simplistic. But I still run a lintian check on every one of my packages before I upload it, and I wish everyone else would too.
Recent efforts to start measuring quality in our archive by asking questions like "how many of our packages can be built from source today?" are commendable. I hope to see those activities continue and expand. At the conference I attended in Australia recently, I was approached by a graduate student interested in the prospect of using Debian's package pool as input for various software quality efforts. That's pretty neat, and I did my best to encourage the idea, in the hope that eventually something useful to Debian might come of it.
If we want to be a universal operating system, we need to be more predictable about releases.
The work done since potato released to rework our archive is really important. Implementing package pools, and the work Anthony Towns put into implementing the logic for promoting packages into our testing distribution, are key to getting control over our release process in the future. We have all been frustrated by the amount of time it has taken to make the transition. It hasn't helped that we've had parallel projects to do things like allow crypto into US main that have taken much longer to implement than any of us initially hoped. However, I'm pretty confident that the tools and processes now in place give us the opportunity to be much more predictable about our release schedules in the future.
I completely agree with the assertion that we need to remember that Debian is a mostly-volunteer project and that volunteers really can't be coerced into doing things they don't want to do. However, my experience is that volunteers rally behind clear statements of vision and purpose... and in many cases will work harder when they're excited about being part of something good than they would ever work when being coerced. So, I don't see a conflict. We should be able to establish tentative release schedules and have some idea what new features will be available when those release times come. Doing so will give us all goals to aspire to, and the real sense of accomplishment that comes from a successful release on a regular basis.
As part of my new job, I've spent time loading and studying various commercial Linux distributions. There are some things Debian's current installation tool set does amazingly well, but there are also things about it that are really confusing and frustrating for newcomers to Debian, much less to Linux. We can and should do better if we want to be a universal operating system.
The consensus among those working on it appears to be that boot-floppies as we know it today should end with woody, and be replaced by something better for our next major release. We have many of the components of the proposed next-generation Debian installer already in the works.
At the same time, other interesting things have happened. Without much fanfare, the graphical installation tools developed by Progeny for their Debian-derived distribution have been enhanced, packaged, and are now part of Debian main. Others have pointed out that commercial Linux distribution installers have some excellent features, and most are Open Source so we can borrow from them at will.
We have also seen in recent months an increase in the diversity of installation media, including the installer-only CD images made available for the PARISC and IA-64 ports, and in various flavors for i386 systems. Several groups are working on tools to support unattended installs, with at least two tool suites I know of already packaged and in our archive. And I and others are working on ways for users to avoid much of the complexity of our current installation process by delivering mostly-configured OS images that prompt the user for final configuration choices on first power up.
I almost feel that we have an embarrassment of riches available to us for our installation tool set(s) beyond woody. We just need to figure out which pieces to apply in various combinations to optimally meet the needs of our different user communities.
We are fortunate that the value we deliver, and our strong reputation, have led to so many donations of various resources to meet these needs.
As the person who put the first master.debian.org together oh so long ago, I've been thinking about and paying attention to Debian's infrastructure issues for a long time. I chat fairly frequently with the people who do much of the work of maintaining our archive and mirror network, and I hear about many of the problems they encounter. Talking with our Australian counterparts recently in Brisbane, where bandwidth cost is much higher than in the US, helped me to remember that we need to be pro-active about managing the cost and complexity of the infrastructure supporting our operations.
We should talk up the benefits of implementing caching proxy servers instead of mirrors for many users, and provide either packages or cookbook instructions on how to implement resource-efficient solutions. We should continue to look at ways to reduce the bandwidth requirements both for our mirror network, and for individual users updating over the network... and be willing to implement good solutions when we find them.
I think we could also do a better job of helping our users be secure in the things they do with Debian, by enabling crypto support in more of the applications we ship. Having to build and support both crypto and non-crypto versions of some of our key applications has taken a lot of energy that could have gone to better use. That's why I'm such a strong supporter of the effort to move Open Source crypto into US main, and thrilled that we're on the verge of implementing the change as I write this text.
Enterprise customers want to be able to buy big third-party, binary-only application suites with support contracts, and run them on our operating system. It would be easy to dismiss these folks as peripheral to our primary goals, since we share such a strong value on Free Software. However, these folks often really want to run Debian on their systems, but can't because the application vendor only certifies their application on some other distribution. If we can manage to meet enterprise needs and thereby help out our friends in industry without compromising our system or our values, we should do it.
The LSB is the solution to this problem. If successful, the interfaces defined by the LSB will become the target platform for big application developers to deliver to. It won't matter whether the system is Debian, RedHat, SuSE, or something completely different... as long as the system is LSB compliant. This will remove a substantial barrier to the acceptance of Debian in corporate computing environments that currently exists, taking us one step closer to being a universal operating system.
A lot of fear and confusion surrounds the LSB. It doesn't require that we abandon our package format, or make onerous changes in our system to be compliant. The LSB as it stands today is not perfect. Early versions of the specification have serious issues that need to be resolved before the LSB becomes truly viable. These are all solvable problems.
Many major commercial distributions are now on record as supporting the LSB, and I think it's important that Debian does too. We have no vested interest in maintaining the status quo, and could reap strong benefits from being the best LSB-compliant distribution available. We shouldn't be at all passive about this. We should be willing to do the work, and fight the fights that are required to ensure that the LSB specification evolves into a truly useful standard that we can support with enthusiasm.
Working on Debian is my way of expressing my most strongly held beliefs about freedom, choice, quality, and utility. I have a vision for what Debian can be, and the skills and experience as a leader to nurture and communicate that vision. I ask you to elect me as your project leader so that together, we can make our vision a reality.
Thank you for your time, and your vote!
However, I see nothing in their platforms that inspires us to greatness.
Raphael has a long list of projects he wants us to work on, many of which I agree are things it would be good for Debian to do. But his long-term vision for Debian's future completely eludes me. Raphael talks about organization and communication as the key roles for the DPL. I agree that they are important components, but they have more to do with management than leadership. We need something more.
I find myself in strong agreement with the last two paragraphs of Branden's introduction, in which he talks about Debian's constitutional basis and the role of the DPL. I also find much to agree with in his list of issues. But I find it little easier to discern his long-term vision for Debian than Raphael's. I also worry that Branden is overly concerned about procedural issues, and I'm not sure that his emphasis on holding maintainers, delegates, and the technical committee to higher standards is what our DPL should be most worried about.
I respect both Branden and Raphael for their obvious strong interest in Debian, their intelligence, and for their good ideas as presented during this campaign. However, as someone pointed out recently on one of our mailing lists, a good hacker doesn't always make a good leader. I think I'm both, and I think my track record proves it.
Therefore, while I have great respect for both of them, I do not believe either Branden or Raphael is better equipped to serve as Debian's leader than I am. While we need projects to continuously improve our infrastructure and results, and good processes to ensure that we can all work together effectively... what we really need most in the next year is "real leadership".
We need a "dramatic destination" to aim for. And once we have that destination in mind, we need a leader who will remind us of what we are trying to achieve when things bog down, and who can effectively help guide our short-term actions into alignment with our long-term vision.
My platform articulates my vision of Debian as a Universal Operating System, and I think I am the candidate with the greatest ability and experience as a leader to help us get there.
What I think it all comes down to is who among us you think will provide the greatest inspiration and motivation to our project. I believe I am that person. I have been quietly but consistently making things happen for Debian since 1995. I have brought many people and other resources to the project, and I'd like to take my advocacy to the next level. I hope you want to join me in making our vision of Debian as a Universal Operating System a reality!
Thank you again for your time, and your vote!
Last Modified: Thu, Mar 14 00:26:46 UTC 2002
Copyright 2002