Ian Murdock - interview

From LXF Wiki

Dial M for Murdock

These days he works on bringing order to what he describes as the "chaos" of Linux. But what does Ian Murdock think about how Debian, the project that he created, is being run?

Ian Murdock first made an impact in Linux when he put together the Debian manifesto and created the Debian Linux distribution, back in 1993. He went on to found Progeny, the Linux IT company, in 1999. He now serves as the chief technology officer of the newly formed Linux Foundation (merged from the OSDL and the Free Standards Group), where his role is no less than to bring consistency and standards to the Linux OS. Nick Veitch met Ian in New York, armed with questions from Linux Format's Debian-fearing followers.

Linux Format: Are you happy with the way that Debian has turned out?

Ian Murdock: I'm generally pretty happy. Clearly, Debian has done a lot of good things and had a major impact. Certainly, it has exceeded all my expectations going into it. I'm a little dismayed by certain aspects of it.

I think in some respects Debian is blowing a pretty big opportunity. If you look at the way Linux is used in big enterprise all the way down to the other end of the spectrum, Debian is one of the three big distributions worldwide ­Red Hat and SUSE are the other two. There are just a few little things that hold it back. One big one is the fact that it has never had a predictable release schedule. When is the next version going to come out? "Whenever it's done" isn't a very compelling answer for a broad swathe of the market, right?

I said a year and a half ago that Debian had a big opportunity in front of it and that the most important thing they needed to do was to get Etch released on time. So to see not only how that has slipped but also the manner in which it has slipped ­ namely that there is almost a prediction among certain developers that it's never going to work because you've introduced money into the equation with the Dunc-Tank project and that it's doomed to fail, and the passive aggressive actions by those same developers to make sure that their prediction comes true ­ that sort of exposes the worst part of the open source development process. Not to mention that they [Debian] are missing a big opportunity.

LXF: None of the other distributions seems to have so much internal strife.

IM: To a certain extent it's pretty typical. You see the same kind of internal strife at any company ­ the question is, how publicly does that kind of information get shared? Most of the time you never hear about it because this kind of positioning and jousting happens behind closed doors. So it's really nothing new. The thing with Debian is that everything is so open and transparent, so you see it.

I think to a certain extent that Debian is process run amok. You need to have some sort of a process to scale. I mean, you go from one person to ten people, and that exposes a whole new set of issues. You go from ten to a hundred, a hundred to a thousand, and you have to build process in order to scale. The problem with too much process is you get into design by committee ­ you get into a situation where without strong leadership no one feels empowered to make decisions. Sometimes you have to make decisions that are unpopular; that's what leaders do. What ends up happening in this committee mentality is that no leader feels empowered to make decisions unless everyone agrees with him. And since as the size of the organization grows no one ever agrees on anything, no decisions ever get made. That's the quandary that Debian finds itself in today.

LXF: If Debian was a do-over, is there some way that could have been fixed?

IM: Frankly, I can see this on Slashdot already... so I might as well keep going! I think the fundamental mistake was this adoption of a democratic process, which happened after my time and I was opposed to.

LXF: You were against it?

IM: I was against it. Mainly for that same reason: I believe that open source projects are no different from businesses or any other kind of organisation in that to get any meaningful work done, there has to be strong leadership. I think that's part of the reason why Ubuntu has done so well: there is a strong leader, and that strong leader is empowered. An enlightened leader will listen to what the community is saying and factor that into account, and understand that sometimes the leader makes bad decisions and that they have to be revisited. I think in some ways the people who were really pushing for pure democracy at Debian wanted to see this as a sort of social experiment ­ what happens when every decision is put up to a vote. You know, pure democracy... It looks a lot better on paper than it ends up in practice. That's why I was always opposed to it. You know, I've been pleased with the current leadership at Debian: I think Anthony Towns has done a very good job and certainly hasn't been afraid to make unpopular decisions, Dunc-Tank being one example. At this point it is more of an institutional problem. Hopefully the strong leadership will continue.

LXF: You mentioned Ubuntu, and many people have cited that as Debian `done properly' Are you upset by the fact that Ubuntu is basically a populist version of Debian?

IM: Let me defend Debian now that I've attacked it for a little while. One has to remember how completely groundbreaking Debian was. This whole idea of open development, distributed development... it was a model that Debian truly pioneered. Linux really pioneered it, but Debian was the first attempt to explicitly build something this way.

So clearly whenever you are breaking new ground, entering new territory, you're going to make mistakes; part of the measure of a successful organisation is the ability to understand when you've made mistakes. The whole notion that Ubuntu is Debian done right somehow implies that Debian is done wrong, which I think is wrong-headed. Are there things that Debian can learn from Ubuntu and the extraordinary uptake that it has seen and frankly all the things that it is getting right? Absolutely. I think that's the single biggest positive impact of Ubuntu.

Ubuntu has certainly raised the bar. They have had a tremendous impact on the number of people worldwide using Debian (I do consider Ubuntu to be Debian). I think they have made mistakes, but they have shown that they are capable of acknowledging where they have made mistakes and correcting them. I was pretty vocal early on about my concerns about compatibility; namely that we were starting to see Debian packages that you couldn't run on Debian. I remember when that happened around RPM in the late nineties and I didn't want that to happen to Debian too. We had some differences of opinion about how to go about doing that ­ DCC and the various other things that came and went. But at the end of the day, Ubuntu is now an active participant in my current project, Linux Standard Base, which has compatibility at its core, so for the most part those initial concerns that I had have been addressed.

LXF: That brings me to another question: is there ever going to be a time when the Linux Standard Base will endorse a particular package?

IM: It certainly makes sense, what people ask for. What you have to keep in mind is the way that the LSB works ­ we operate in a world where there are already multiple implementations. You can't just walk in and say, "You're right, and you're wrong." It's something like sitting down with someone and saying, "Well, we agree that we have to agree on something: why don't you just agree with me and we'll be done?" And the other person is sitting thinking exactly the same thing...

In terms of packaging, yes, there is clearly need for a packaging standard. Because you just go look at a downloads page of any Linux application ­MySQL is a good example ­ and they've got 15 different packages. Here's the RHEL 4 version, the RHEL 5 version, the Debian version, the whatever version, and in part the LSB is designed to solve the problem of building the application so that it will run on all of these different distributions, but it doesn't address the problem of how you get that application on to the distribution in the first place. So we have recently started working on a packaging standard. And the key here is how you go about doing such a thing. We went to the distributions because we realised that in order for a packaging standard to have real-world impact, the distributions are going to have to not only buy into it but also openly implement it otherwise

LXF: There's no point.

IM: Yes: we're inventing a standard that nobody uses and it's a waste of time. So, we get everybody in a room and say "This is a problem that needs to be addressed," and for the most part everybody agrees. Usually it's at that point that things fall apart, because people come in and say, "Obviously the way forward is to..." Usually their solution involves rewriting everything.

LXF: That's the Canberra solution, isn't it? Can't decide between two equally good things so you just pick something that's a bit rubbish.

IM: It's even worse than just picking one, it's creating yet another one. In terms of the LSB standardising and enforcing things, we operate in this very distributed, multipolar world where how you build the standard is as important as what the standard says.

LXF: Isn't one of the dangers, though, that if you choose something as the standard, then there's no impetus to make that better?

IM: This comes down to the whole question of how standards and innovation relate to each other. The way that you ensure standards don't inhibit innovation and in fact enhance innovation is by standardising as little as possible. So in terms of packaging, it doesn't so much matter that everybody delivers packages in the same format, it doesn't so much matter that if you have two packaging systems, each one of them has exactly the same capabilities and the same interface. What really matters is, at the end of the day, what does the consumer of the technology need to do with it?

In the case of packaging, you go ask the consumers of the technology ­the software developers that want to build that single Linux application that works on any distribution. They say, "Listen: we're supporting two, three, four different platforms already, we don't want to support another one ­ we don't want to have RPM. That's why we have the shell scripts to just dump files in the filesystem. So what we want is an incremental solution that will allow us to add just a few little lines of code to what we have today. Don't make us throw everything out the window just because you don't like the previous iteration of technology." It's really as simple as that: standardise as little as possible and don't go into the discussion with any preconceived notion about the outcome.

LXF: What do you think the major challenges are for the LSB?

IM: The major challenge with the LSB is just the sheer complexity of the job that we have to do. If you think about the Linux platform, it's not this neatly bundled thing. In reality it's dozens or hundreds or thousands of different components maintained by a whole bunch of different people ­ with very different priorities. Some people understand that backwards compatibility is important, other people don't care ­ they're going to change what they're going to change when they're going to change it.

Our job is to bring some order to the chaos ­ or at least hide the chaos. You have people coming in and wanting to look at Linux as a single platform, and the fact that there are 100 or so different distributions and that sometimes this minor component breaks backwards compatibility for some arcane reason... this is all causing these people to think: "Is Linux even viable?" The challenge is to keep all these people with these different interests aligned around a common goal.

LXF: Why is that? IM: Because as Linux grows, more and more people are feeling more and more pain around the problems that we're trying to solve. It's always hard to try to get people to relieve a pain that doesn't exist yet. "You're going to feel this pain in a few years so just trust us ­ we're going to prevent it." It's far easier to sell people on curing as opposed to preventing.

LXF: Will the merging of the OSDL with the FSG make things easier?

IM: Yes, definitely. In terms of the FSG and the OSDL, there was a huge amount of overlap of the major sponsors of those organisations. In terms of the charters of the organisations, on paper there was no overlap but in reality there was some overlap. We were doing the LSB and OSDL was doing Carrier Grade Linux [CGL] and Portland, which looked like standards. At some level we were competing with each other, and it didn't make sense because we had largely the same backing. Bringing these organisations together ­ any kind of consolidation ­ improves efficiency.

LXF: Do you think it makes it possible to have clearer goals as well?

IM: Yes, in the sense that, for example, instead of having LSB, CGL and Portland, we can coalesce that into more of a single message, namely that we need to standardise the Linux platform. That is going to entail compiler toolchain, kernel, desktop, some of the vertical features like carrier grade that are targeted at a particular industry.

What we have to do is to have a crisp story about what it is that we do. People don't think about standards organisations all that much. They're not thinking about, "What kind of standards is this group producing?" They're thinking about, "What is this Linux thing anyway and how exactly do I wrap my arms around it?", "How do I build my product for it?" "How do Ideploy it in my enterprise?" or whatever. We have to talk their language in addition to just rolling up the sleeves and doing the work that needs to be done.

LXF: Are you concerned at all about a possibility of patents being used in some of the standards?

IM: That's a concern that any standards body needs to have.

LXF: Because it's happened so many times already.

IM: Yes, it's a time-honoured technique, I suppose, to get involved in the standards effort and contribute something. They call them submarine patents: these things are lurking in the background. You get yourself perfectly positioned, turn the screws... Because it's a time-honoured technique, standards organisations have built up policies and various electoral property policies, for example, which are designed to deal with that.

We're no different ­ we have the same kind of ID policy in place that is designed to prevent these sorts of things from happening. Obviously ours is different from what you might find in a typical standards organisation because we're open source, but for the most part the same rules apply. LXF