Home opinion-and-analysis Open Sauce A conversation with Bdale Garbee

It's difficult not to notice Bdale Garbee, the chief technologist for open source and Linux at Hewlett-Packard, when he attends the Australian national Linux conference.

You can't miss the tall figure with the well-maintained beard, holding, like a plaything in one hand, a little laptop that has a prominent Debian sticker on it.

Despite his height, he always manages to quietly enter a room when he attends a presentation. And when he does choose to ask a question during a presentation, it is well thought out and adds to the learning of all present. He isn't inclined to be frivolous - though, as he amply demonstrated this time, he has a great sense of humour.

Garbee was prominent at this year's conference, all due to events not exactly to do with Linux. His picture even appeared in the local Tasmanian tabloid. These events have been reported elsewhere, hence one does not intend to dwell on them.

When I spoke to him, early on the Tuesday of conference week, he still had his beard. We talked at length about the Debian GNU/Linux project - he has been a part of it since 1994, is chairman of the technical committee, and, at the time we spoke, was acting secretary.

Edited extracts:

iTWire: Recently there was a long debate over the question of free vs non-free in the Debian project. Do you think it is possible to settle this once and for all?

Bdale Garbee: I think so. But I don't know that we're quite ready for the ultimate solution. One of the messages that I posted late in the thread of discussion was to the effect that I would much rather see us resolve some of the related bugs in question than spend much more time talking about them.

In that regard, I picked a couple of them myself and over the last couple of weeks I have successfully got to the point where we're now ready to close the two bugs in the Debian bug-tracking system related to glx. SGI took an action, back in September I think it was, to relicense the code in question and what needed to happen after that was to contact all of the individual developers who had made contributions on top of their original work to confirm that they all agreed to the licence change and we got the last confirmation on Thursday (January 15).

As soon as I have a chance to catch my breath a little bit, we'll process all of that and close those bugs. This is the kind of thing that has to happen, we have to be willing to just do the grunt work of stepping through and resolving these things.

The longer term question of what the role of the non-free side of the distribution should be in Debian is, I think, a more difficult question. There have been a lot of ideas posted recently that I find myself agreeing with, suggesting that always having a place where we explicitly put software that doesn't meet the Debian Free Software Guidelines (DFSG) that indicates that it doesn't meet our guidelines and yet is of interest to our users, seems like a valuable thing.

CONTINUED


iTWire: This debate has recurred twice before, once before Sarge and...

BG: Well, the last two major stable releases we've had (this debate), both prior to the releases, and always the question is, is it okay for us to release the distribution as it is today, with some known issues?

We have always accepted that there may be some technical bugs in a stable release that weren't worth holding the entire release for. The difficult question is whether known issues with regard to our own free software guidelines are things that it's okay for us to ignore. And I think this most recent bug made it very clear that no-one wants to ignore these issues.

My reading of the result (of the vote) says that people very strongly support the DFSG and related elements of the social contract but they also understand that if the software that we have ready to release today is both technically better and better from the perspective of freedom that what we've previously released, that we're doing our users a service by releasing it even if it's not perfect yet.

iTWire: So i take it that it is possible to put in your contract that if issue X rears its head, then this is how we settle it?

BG: I think we've established a pattern now that when we reach the point where we believe that we're ready to make, or we're coming very close to being ready to make a stable release, that if there are outstanding issues that fall into this category of questionable or definitely not complying with the DFSG, that a reasonable approach is for us to hold a GR vote and get an explicit sense from the Debian development community about whether they are prepared to release under the existing situation or not.

The recent vote was somewhat flawed in that the people who proposed the original motion and the related variations had many different ideas that they were trying to capture and so we didn't get a very clean yes or no threshold decision on various issues.

We got an answer that said it's okay to ship with the remaining firmware components of the kernel that are being shipped as binary blobs for this release. but that said nothing, one way or the other, about some of these other licensing questions reflected in bugs.

Hence, we've had to read the raw results of the vote which we can do in a Condorcet style election; we can see the preference between individual pairs of choices and we've had to try to extract from that an understanding of the other opinions that the developers have beyond which of the seven options they chose as their preferred choice.

CONTINUED


iTWire: Do you think this is unwieldy because everyone has a voice? Do you think it might be better if X number of senior people made the decisions?

BG: I don't think that we need to do that so much. I do think that we've had a healthy debate that's not been completed yet about what the role of the secretary should be in the process of creating the ballot.

There was a sense, this time around, that our former secretary may have overstepped his bounds a little bit in how he crafted the wording of some of the options. But I think it's actually very important for the person who's running the vote to help the people proposing the different options that they like to see voted on, to get the language structured in a way that helps us to clearly understand the minds of the developers in the aftermath of the vote. Otherwise the vote has less value.

I think there's a balance here between preserving the ability of individual developers who can get enough seconds to be able to propose a resolution, and an appropriate engagement by the project secretary to ensure that the ballot we're voting on is one the developers can comprehend and make intelligent choices at the end of the process.

I frankly find the process of trying to do that daunting. As a result I am very pleased that we will announce a new secretary and I won't have to do this anymore.

iTWire: What do you think about having a code of conduct for Debian?

BG: It's interesting. I'm one of those people who is always reticent to add additional rigid documented policy and process because I have a general belief in something that's actually been part of HP's core corporate values for a long time. Which is this notion that people want to do the right thing and, given the opportunity, will try to do the right thing.

And I think that even at Debian that's generally true. But, unfortunately, what we've learnt over the years as the project has gotten bigger and bigger is it's very easy to find yourself being held victim by a very vocal minority who, in effect, end up monopolising the discussion on mailing lists by so many posts which are so repetitive it drives other people away from the conversation because they get tired of reading the same stuff over and over again.

I think that as a consequence some of the ideas that are floating around, about ways that might try to guide more social behaviour in our interactions, seem like good ideas but I don't know yet whether any of the specific ideas floating around are things that I would be willing to support. I still need to think about this for a while.

CONTINUED


iTWire: What do you think about setting as firm release dates as possible?

BG: I think it's advantageous for the people who build dependencies downstream of Debian releases to have an understanding of the project's intent. It's valuable when we can figure out how to stick reasonably close to schedules that we have communicated.

However, in the end I've always been an advocate of the notion that we shouldn't release until we are ready to release. There has to be a balance here somewhere. I have seen other projects be reasonably successful at trying to stick to relatively firm schedules. On the other hand, I've seen lots of projects drive themselves to an incredible level of stress around release times because there are things they want to fix but they really want to release on a particular date.

There's always a balance - without deadlines, it's very easy to leave things and not have a sense of urgency about them. But, on the other hand, deadlines that are too rigid drive too much stress into the system, particular for volunteer activity. So we have to have a balance.

iTWire: Do you think it's a good idea to get moderately experienced users of Debian to use testing - tell them it's fine, you can use testing instead of always waiting for a stable release?

BG: Testing came about initially because I was having a conversation with some of the people who worked with me in the old HP many years ago about the system we had at that time, which was just stable and unstable. There were two problems - one, that many users didn't want to get stuck running something that was getting out of date, as stable always tends to be after it's released, and yet they didn't want to be subjected to all of the noisy breakages - some of which used to be really hideous, like /bin/shell not working after an upgrade - that would happen in unstable of that era.

People had this desire to have something that was in-between from an utility standpoint. But then there was this issue in the early days of Debian, the way we did a stable release was to take a snapshot of unstable and then work to try and close the gaps on it. The proposal that I made was that we think about the possibility of an intermediate step that would be subject to a set of mechanised rules to ensure that the worst breakages that showed up in unstable would not be there, and yet it would be as fresh as possible. It seemed to me that would give us a big step in the right direction towards being able to make a release.

Anthony Towns is actually the one who took up the idea and ran off and wrote a bunch of code and implemented it and his primary motivation was to implement the sort of rolling release candidate part of the proposal. I think he did an excellent job of it and that led to it being called testing and it led to the current situation where that is how we stage the future release.

But, somehow in that process, I think the idea that 'this is something that maybe the majority of our desktop end-users might want to run as their choice of distribution', that kind of got lost in the definition. I've always thought that the thing we now call testing is the thing that most end-users would probably like to run. But it does require extra work from people like the security teams and so forth in order to make its something with which everybody's comfortable.

At any given moment in time I've had different feelings about it. I certainly have arranged that most of the machines in my house that aren't mine end up running testing. My wife and kids are currently running Lenny (and have been) for a while. They'll probably keep running it for a while after Lenny releases stable but at some point there'll be some new application or feature they want that makes them roll forward to whatever the next testing distribution is.

CONTINUED


iTWire: I'm not a very technical user, yet I've been running testing on my desktop for four or five years now.

BG: I think it is important that, when you put systems into a business mission-critical kind of situation, you think very carefully about how you're going to get security updates and all those things. For the average desktop user, testing is a really good choice. It stays reasonably fresh and you certainly are insulated from the worst of the brown-paper kinds of bugs that show up in unstable.

I personally run a mixture of unstable and experimental partly because of an attitude that, as a developer in the project, and sitting in the position I do on the technical committee and so forth, if I can't make it work why would I expect anybody else to be able to?

iTWire: Given your level of technical expertise you could run unstable all the time - you would know how to fix any breakages.

BG: On the other hand, I will admit that my main file server at home only recently switched from running stable to running testing. I'm running testing only because I need to update a few things that the system relies on and as we are getting close to the Lenny release, this would be a good time to get an idea of how close Lenny was getting to be ready to go.

I'm pleased. I've had a 100 percent positive experience with rolling my main server over to Lenny and I think the majority of Debian users are going to be very pleased with this release.

iTWire: Every time there is a delay in a Debian release, people come along and start prophesying that the project is doomed to failure.

BG: The interesting thing to me is that this time I think we're much closer to releasing on schedule than we have been for many releases in the past. I don't really understand why people are so hyper-sensitive to these release schedule issues. I can understand why, for example, teams in HP server division who want to provide official support for Lenny once it's released, have a strong motivation to know when that's going to happen and when they should schedule the engineering time to do the integration and testing work and so forth.

For average users, I honestly don't know why people make such a big deal about release schedules. There's always this question of 'oh, is there some newer shinier release from some other distribution that we're going to get excited about'. I know that there are users who love to bounce around and try the new releases of everything when it comes out.

But I also know a really significant number of people who are wildly enthusiastic about having robust, stable, well-functioning systems and are happy to wait another week, another month, another year or whatever it takes until we're comfortable with the next release.

CONTINUED


iTWire: There are often snide references made to a Debian cabal. What is this cabal and does it exist?

BG: I'm always bothered by the term cabal because it's always had negative connotations associated with it. On the other hand, on any given day, there are certainly people in key roles in the project who spend more time on average working on behalf of the project than the average developer among our 1000-plus registered developers.

Hence, it should not be surprising to anyone that the people who put more energy into doing real things and, as a result end up communicating with people a lot, might somehow from the outside be perceived as having a slightly different level of involvement with the project or a different relationship to some decision-making processes. I don't see anything negative about that. I certainly don't see anything sinister about it which is the implication that you see sometimes.

I know that there are people who get bothered sometimes, when they think someone else whom they perceive as having some position of authority in the project disagrees with their opinion or isn't as quick to respond to a request that they make or something like that. There's always a tendency to kind of fall back, sometimes jokingly, sometimes not, on the "oh, you've offended the cabal" line.

It's interesting, though, that as long as I've been involved in the project and as close as I have felt in my ability to have conversations with key people at various times, I've certainly never sensed anything that was kind of secretive or sinister about what's going on in the project. Over the years, going back all the way to when Ian Murdock was head, I think every Debian project leader over the years has felt free to come and have conversations with me or other people who have been around the project a long time, to ask our opinions, to get input to help them make decisions.

And so I wouldn't be surprised if there are people who think that I and other people like me, who have been around a long time and have questions like that asked of us, maybe have more opportunity to influence the thinking of the project leader and other people than others might. I wouldn't be surprised if there's the perception that we have some kind of a different relationship.

The whole cabal idea just kind of bothers me because everyone involved in the project is on some level volunteering their time and energy. Everyone that I know is trying to do what they think is the best thing for the project. We often passionately disagree about the details of how to implement what we all individually and collectively think is the best thing for the project but... I don't know.

CONTINUED


iTWire: How do you feel about ideas like the Dunc-Tank which Anthony Towns thought up - the idea of paying some people to work on things to keep to release schedules?

BG: It's really interesting because that was not the first time in the project's history that people had been paid to do work on behalf of the project. In fact, I've helped over the years, when I was DPL, in the years before that, arrangements have been made for various people to be paid to do work on behalf of the project that I thought was important, or that my employer thought was important.

What was interesting about the Dunc-Tank experiment was just how much noise it generated within the project. I have spent quite a bit of time trying to think about what it was that caused that to happen and why was it that that it generated so much noise - and why other successful instances of paying people to accelerate work in some parts of the project hasn't generated so much noise. I think it had to do with the degree of visibility.

It bothers me a little bit. I don't like the notion that its easier to pay people to work on the project when you don't talk about the fact that you're paying them and yet that seems to be the lesson that came out of the Dunc-Tank experiment. I haven't tried to draw any huge conclusions from that about what we ought to do about the future.

There continue to be a substantial number of key contributors in the Debian project who are allowed, if not directly supported, to do work for the project as part of their day jobs. I personally have a hard time figuring out where to draw the line between these different kinds of compensation. I'm thrilled that several times in the past, when there was some specific activity, whether it was achieving LSB compliance or getting past certain transition activity like when we trying to get the Itanium IA64 architecture well supported by Debian, HP paid quite a bit of money to several groups of people to get it done.

I was a little disappointed that what came out of that whole experience (Dunc-Tank) wasn't a crisp understanding of how we should do this in the future. What we got instead was a very clear example of "here's a way to not do it."

CONTINUED


iTWire: At the last LCA, two Debian developers gave a talk about trying to get more corporates interested in the project. Has there been any progress on this front?

BG: I have to be honest and say I don't really know. It's interesting to me how the nature of many of my conversations have changed over the years.  I used to get lots of questions from people asking me why is it that you and HP do so many things with the Debian project and i don't get that kind of question anymore.

The question I get instead is usually more specific - we'd like to see this particular thing in Debian, how should we go about it? That suggests to me that on some level either I'm just having fewer of those conversations with people or that people have moved beyond trying to understand why you would want to work with Debian and are instead trying to figure out how to work with Debian.

At the same time, there's probably on some level, I think, less attention of a certain sort being paid to Linux at this point per se. I was having a conversation with another delegate at the conference this morning about the fact that as recently as a few years ago, we were still getting lots of questions about what is Linux, why would I want to use it. We were talking about its use in consumer products as the embedded operating system. We really have got to the point where the question is not what is Linux and how would you use it; on the rare occasion when you come across a product where it would seem appropriate to use Linux and it's not being used, you wonder, why aren't they using it?

I think, on some level, all these things are shifting over time, the whole market and its attitude towards Linux is maturing. As this happens, the role played by projects like Debian and the other distributions, both commercial and non-commercial, will gradually shift over time. I'm not surprised to see these things change over time, I think it's a natural consequence of the evolution of the marketplace.

iTWire: The final question is a frivolous one - how do you maintain your beard so well?

BG: I have this 35-year-old electric trimmer that I absconded with from my father when I went off to college. It has one remaining intact plastic cone thingy for it and it happens to be the thing (I use).

HOW TOP MANAGERS MOTIVATE, ENERGISE EMPLOYEES

Download an in-depth guide to managing a healthy, motivated and energetic workforce without breaking the bank.

DOWNLOAD NOW!

Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.

 

 

 

 

Connect

Join the iTWire Community and be part of the latest news, invites to exclusive events, whitepapers and educational materials and oppertunities.
Why do I want to receive this daily update?
  • The latest features from iTWire
  • Free whitepaper downloads
  • Industry opportunities