Dougherty: When did the Linux How-to's emerge? Is that something that you were involved with?
Welsh: Yeah, I started the How-to project along with Ian Jackson. Ian Jackson was one of the original Linux documentation guys and this emerged out of our frustration with the original Linux FAQ. The FAQ was this enormous document that was posted in seven separate sections to Usenet once a month. It was just unbelievably baroque and complicated. We decided to just throw it in the trash can and start from scratch with a new FAQ that was just really frequently asked questions, not everything about Linux, right? Frequently asked questions only. We'd start writing a new series of tutorial-oriented separate documents about Linux called How-to's; Ian was the one who actually recommended the name How-to for that. So I wrote the installation How-to and the X Window How-to and the Network How-to. Along with the Linuxdoc-SGML tool suite, I put those out there to people and said "Hey, here's this new thing, there's How-to's and here's the tools that you use to write them. If you want to write a How-to, here's how to do it and e-mail it to me and I'll format it and post it once a month to the Web and to the Newsgroups." And, that's how it got started. It was kind of a fun thing because now there's hundreds of How-to's.
Dougherty: Right. It's on one hand a very obvious idea, but it still looks to me fairly. Others haven't necessarily picked it up -- other projects. It is that it is a format that almost anyone can contribute something to. When you say, "I'm going to write an administrator's guide" it kind of implies a book with chapters and all that.
Dougherty: And this is, "I solved this problem, let me document it for others and submit it to the How-to's."
Welsh: That's totally the idea, that it's completely collaborative in the sense that you don't need to collaborate with another person to write a How-to. That's the reason that it seems to work. People can just go off on their own and write a document about getting the Croatian keyboard mapping to work under Linux. We have How-to's like that. If you write that and you send it out there, it kind of takes on a life of its own. Multiple people might contribute and collaborate on one How-to, but more often than not, it's somebody doing their own -- scratching their personal itch to put it in Raymond-esque terms, right?
Dougherty: So, in many respects, people point to the Linux Documentation Project as at least one of the better models out there for trying to organize information that's needed for new users. But, I know from talking to you it's not necessarily a solved problem and there are a lot of interesting things that need to happen, not just for LDP but really any of the open-source documentation projects. Can you talk a little bit about some of those?
Welsh: What's happening now is that there are just so many sites that you can go to to find Linux information that the real problem is just navigating all that information. Originally, if you wanted to learn something about Linux, it was pretty straightforward. If there wasn't a How-to about it, then nobody knew how to do it. I mean it was easy to go to this one site and to find the How-to's and to do that, so now there's this proliferation of Web sites. The real challenge is to create the Linux portal. Several people are interested in getting involved in that space. How do I distill out this information and provide a way of searching for what I want and navigating to the information that I'm looking for. That's the biggest remaining problem with documentation. We've got lots of content out there, lots of very good content, some bad content. How do we make people aware that that content even exists?
Dougherty: OK. What I see is that these documents become living documents. They might pass through the hands of several different authors over the life span, just as here at O'Reilly we have books that go out of date. There's documentation that goes out of date and it's not always clear from an open-source perspective, how can I go about changing it or improving it or updating it.
Welsh: It's pretty informal. The documents are effectively in electronic form and the How-to's especially are short enough that it's pretty easy for it to change hands? An entire book is a little bit harder to do that with. I had problems getting my original Linux book, the "Linux Installation and Getting Started Guide," into the hands of some people that could actually take care of it. So, getting access to writers that know what to do with a particular document is a lot easier when it's shorter, right? And, so that's one of the ways that works in the How-to's projects is that when somebody says that I'm not maintaining the How-to anymore, they find somebody to do it and it's usually somebody who has made some contribution to that on the site.
Dougherty: OK. Well let's -- you've moved on. You went from Cornell to Berkeley. Let's talk a little bit about some of the work you're doing there. You told me you were working with Java and Linux, which is sometimes a problem putting those two together, isn't it?
Welsh: Yeah, I've said that this is like chocolate and cheese, I mean, you really like Java and you really like Linux, but the two don't always go together. One of the problems is that there's a number of competing Java implementations for Linux and it's not helped out by the various kind of commercial interests that the parties involved have. It's clear that there is enough interest in having Java on Linux that numerous people are going to be providing that solution. So, Sun and IBM and separately the Blackdown porting team as well as the Cygnus Redhat GCJ project and Kaffe and I could go on and on with the number of people out there trying to do Java on Linux.
We're interested in building really high performance workstation cluster applications in Java. We're taking what is called Beowulf, which is just a bunch of PCs in a cluster all running Linux. All of the applications are written in Java and there's a lot of reasons we're doing that. I could go into detail but it's not really all that interesting. The main thing is that we think that Java is a great programming environment for doing certain things that are very difficult to do in C and C++. So, if you're going to write your applications in Java, and plenty of people are doing that anyway, and you want to get high performance, what are the problems that you have to solve with that? That's where my own personal research is going.
Dougherty: OK. Well, thank you, Matt, for coming in here and I appreciate your spending time with us today.