 |
 |
| ||||||||||||||||||||||||||||||
| IBM home | Products & services | Support & downloads | My account | ||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
| ||||
| Interview: Eric Raymond goes back to basics | |   | |
| ||||
| ||||
| Talking with a hacker historian
Robert McMillan (bob@linux-mag.com) Author of The Cathedral and the Bazaar and publisher of the now-famous "Halloween Documents," Eric S. Raymond talks about his latest projects and sheds light on why UNIX developers don't like IDEs. Freelance writer Robert McMillan catches up with an older, wiser open source advocate. Open source advocate Eric Raymond has been spending more time lately in front of the computer than in front of the crowds. He says he's backed off on the public speaking engagements, in part because the travel schedule was exhausting, but also because the need for a 24x7 open source advocate is just not what it once was. The open source revolution is "basically on course," he says; the enterprise has embraced Linux, and these days very few people now need to be convinced that the open source methodology can create best-of-breed software. So, Raymond has spent some time writing and some time hacking. On the writing side, he's recently posted a draft of his latest book The Art of Unix Programming (see Resources for a link), which is slated to be published in August 2003. As for hacking, after spending two years trying to get an ill-fated Linux kernel configurator accepted by the Linux kernel developers ("It was the best work of my life, and it was mugged by kernel list politics," he says), he has hacked a program called Doclifter (see Resources for a link to more information) that will intelligently lift troff markup pages into XML DocBook. He is also co-developing a currently unreleased configuration editor for DNS. We spoke with him recently about the state of the open source revolution, the art of UNIX programming, and a little about what he's been doing lately. developerWorks: Where did you get the idea to start working on The Art of Unix Programming? Raymond: It started five years ago when Erik Troan and Mike Johnson and a couple of people at Red Hat did a book called Linux Application Development (see Resources for a link). I thought it was a very good book, but it wasn't the book I wanted to read. The book I wanted to read was less about the Linux application programming interface and the low-level details of how you got things done, and more about design patterns and high level stuff about why you should do things in a particular style. My idea of a good UNIX book hearkens back to [Brian] Kernighan and [Rob] Pike's The UNIX Programming Environment (see Resources for a link) from 1984. dW: What inspired you about that book? Raymond: The thing that made The UNIX Programming Environment wonderful, and still unmatched as a book, is that they talked not just about tactics but about philosophy, about thought patterns, about the unwritten generative rules that UNIX programmers use without really being aware of using. I discovered that I really wanted to do a book about that. As time went on, it became clear to me that this was really a book that was needed, because there are lots of people in the Linux and open source community who are running around with fragments of the tradition, but they don't have the whole thing. And this is not their fault, because nobody has written it down for them. You really have to have marinated in the tradition for 20 years before you can even think about doing that. dW: Is this something you see changing in the UNIX community in particular? You've talked a lot about the desire to make Linux a more mainstream operating system, but as this happens, you bring in people from outside of the Linux tradition, who may know nothing about this way of programming. Raymond: And my answer is, instead of giving up on that tradition, bring them the fire. That's what I'm trying to do with this book. dW: Some people have said that a popular Linux IDE is going to be crucial, at some point, to Linux's success. Do you see your book as the antidote to that? Raymond: I think one of the things you can learn from this book is why UNIX programmers have historically been hostile toward IDEs. It turns out that there are good reasons for this. IDEs are not a good fit for the kind of knowledge-intensive, mixed language style of programming you see under UNIX. IDEs are great if what you're doing is cranking out C++ code by the yard. But if you're writing systems that are glued together from C, shell, Python, Perl, and maybe several other languages, the worldview that IDEs tend to enforce on you is too rigid for that kind of programming. And that's why UNIX programmers have historically tended not to like IDEs, because they limit your options too much. dW: So do you see Linux influencing programmers more and eroding the popularity of IDEs, or do you see a popular Linux IDE being developed that brings Linux into the mainstream? Raymond: I think everything will happen. Everything you describe. We'll both get more people who catch onto the UNIX Zen and are programming in that style, and we'll have people who don't get it. On this level, I don't think that it's necessary that the UNIX idea take over the world, as long as it remains alive because, frankly, I think that's where the good software's going to come from. dW: In your draft of The Art of Unix Programming, you talk about the Macintosh community and how the Macintosh community is merging, in a way, with the UNIX community. Are there projects where you're actually seeing that happen? Raymond: I don't say that in the book and I wouldn't put it that way. I would say that the communities are looking at each other's stuff and beginning to learn some things. dW: So are there shining examples of this kind of convergence? Raymond: Well, I have one good one. There's an audio editor called Audacity that I use as a case study in my book, which I think is a brilliant example of how you take the Macintosh ideas of discoverability and interface transparency and move them into a UNIX environment without losing the UNIX virtues in the process. dW: The other thing that struck me about your book is that you talk about some of the problems with UNIX design. What do you see as the most pressing problems? And what do you see as the problems most likely to get solved in the near future? Raymond: The most pressing problems that UNIX has right now, in my opinion, are not technical problems. There are technical flaws and gaps in the UNIX design. These are things that the hacker community can address. These are the sorts of things that we're very good at addressing over time. I think one gap that has been repaired quite recently is that file attributes are now part of the 2.5 Linux kernel. I went back and forth on this for years, but I now think that I understand that file attributes are extremely useful for a GUI environment. Basically, the reason is that there is a class of properties -- things like "where is this application located on this desktop?" for which you want to be able to associate data with those applications -- that have exactly the right semantics for file attributes. That is, they are persistent through user sessions, but not something you want to save in a tarball or export over the wire. And that's exactly the kind of persistence that file attributes tend to have. So I think that's one gap. I think we're going to be able to do things that are equivalent to what the Macintosh resource fork does through the new file attribute feature. But those are technical problems. Those are easily solved. Hackers have big arguments over them and eventually something gets grabbed out of the machinery that more or less works. I think the most serious problems are actually cultural ones. UNIX hackers are not very far along in the process of figuring out how to do interfaces well. And this is not because we've been lazy. We've assimilated a lot of stuff in the last 15 years. We've assimilated pervasive networking and we've assimilated GUIs at the developer toolkit level. We understand how to do graphics, we understand how to do libraries, we understand how to do toolkits. What we don't understand yet is good user interface policy and how to listen to users. And that, I think, is the biggest problem the UNIX tradition has right now. dW: Are you doing less travelling and advocacy these days because there are simply less important things to advocate for right now? Raymond: Well, part of the reason is just exhaustion. But also, I think I do perceive that we're basically on course. On the advocacy level, all we have to do to win is to keep doing what we're doing, and to deal with the occasional counterattack from the forces of darkness. dW: People have talked about patent lawsuits and the liabilities for open source projects. Are you worried about this? Raymond: It is a concern. And we need to take appropriate steps on the PR, legal, and other levels to counter that sort of thing. These are solvable problems. They're problems that will take work and attention from various people, including myself. dW: Do you think we're going to see lawsuits against the Wine project or Samba? Raymond: It wouldn't astonish me. dW: Is this something you're spending much time worrying about? Raymond: There's not a lot of point in my worrying about this in advance, so no, I don't spend a lot of time worrying about it. I bear the possibility in mind, and basically what I do when something comes up is reactive. The way to deal with these things, I've found in the past, is to be intelligently reactive. You can't know in advance that something like the Halloween memorandum is going to land on you. All the thinking in the world won't predict something like that. So rather than worrying about this sort of thing a lot, I just prepare for opportunities and I think how to respond when the challenges come up. dW: Since you wrote the Cathedral and the Bazaar in the late 90s, a lot of the ideas that you talked about in that book have been tested in the commercial world, and you even participated in one of those companies, as a member of the Board of Directors for VA Linux. If you were writing the Cathedral and the Bazaar today, would you change anything about it? Raymond: The only thing that I would change, I think, is that I would emphasize something that I talked about in 1997-98, that nobody listened to because everybody was in a state of euphoria. If you read the original papers I wrote back then, you'll see that I warned everybody that the corporate structures that were going to come out of the open source revolution were not going to have the kind of high margins that have historically been associated with closed-source software companies. Because what we're heading toward is a world where software is a service industry, not a pseudo-manufacturing industry, and service businesses never have the huge investor multiples and high margins that are associated with manufacturing businesses. The only thing I would change, if I knew then what I know now, is to make that warning louder, because back in 1997-98 nobody listened. They were so caught up in new technology euphoria that all they heard was "better way to develop software, more efficient, better for the customer." They didn't hear the part where I warned them that you couldn't sustain an incredible speculative frenzy on top of this stuff. dW: What happened with the CML2 kernel configurator? Raymond: It was horrible. It was the best work of my life, and it was mugged by kernel list politics. dW: It sounds like that was a pretty ambitious project. Raymond: It was, I mean I built an intelligent configurator -- basically a baby rule-based expert system -- for configuring Linux kernels, and I did it all in less than 8,000 lines of Python. It was a system that literally made it impossible to get an invalid kernel configuration because it would do intelligent deduction from constraints. And I had the full approval of the kernel config group, I had Linus's imprimatur that this was going to go into 2.5, and it all fell apart politically. It was horrible. dW: But you're the guy who taught the world that in the open source community the best code wins. Raymond: And it didn't this time. And that was horribly disappointing to me. dW: Why didn't it? Raymond: Because Linus abdicated his leadership role, broke his promises, and there are dinosaurs on the kernel list. It's a very conservative, hostile culture. dW: So if there was another chapter for Cathedral and the Bazaar that you would write based on what you learned there, what was the lesson? Raymond: That it is possible for open source cultures in some respects to ossify enough that good work is locked out. And that is a long-term problem that I don't know how we're going to deal with. I also think part of the reason that it happened was that there are people on the kernel list who are really hostile to the idea of making kernel configuration accessible to everybody. They want it to continue being a black art.
| | ||||||||||||||
|
| About IBM | Privacy | Legal | Contact |
