For a man who says he can get a "bit crazy over inadequately commented code", Open Source Development Labs' (OSDL) newest recruit, Andrew Morton, is the first to admit his enthusiasm for the open source cause. The Australian-born and -bred systems software engineer -- whose full-time position with the industry consortium will see him second in command to Linus Torvalds in developing the new 2.6 Linux kernel -- says he is driven by seeing Linux as a useful tool for as many people as possible.
In this exclusive interview, Morton gives LinuxWorld his take on the ups and downs of the open source community, working with Linus Torvalds, the upcoming 2.6 kernel release, his advice for budding developers and the future of Linux.
Q: Could you provide us with a bit of information on yourself - what's your background, where did you study?
I spent most of my life in the Sydney area [Morton is now 43] and studied Electrical Engineering at the University of NSW. I worked for a couple of small technology companies, then nine years with Nortel Networks in Wollongong. Two years ago we [wife and three children] moved over to California.
Q: How did you become involved with the open source movement?
I've always been a system software hacker. I was lurking on the Linux mailing list for a couple of years and would occasionally build and test a new kernel.
In February 2000 I decided to give this 2.3.47 thing a whirl, only to discover that Alan [Cox, from Red Hat] had marked the driver for my $2 Ethernet card [old Ethernet card which plugs into the computer to provide a networking interface] as "obsolete"!
So I got in there and mostly fixed the driver up, sent a 2000-line patch to Linus. He took that, which was neat. I moved on to another driver, then kept on going.
Q: What prompted you to become involved with developing Linux on a full-time/career basis?
Digeo [a US-based company which uses Linux to provide broadband and interactive TV solutions] employed me two years ago as their kernel guy. I spent six months on the ext3 filesystem, moving it from the 2.2 kernel to 2.4, culminating in a merge into 2.4.15.
Early last year I started work on the 2.5 kernel series and most of my time was devoted to that work, with the support of Digeo management.
OSDL are now sponsoring my kernel work, which I must say makes it a lot easier for Digeo to continue to support it.
Q: What other initiatives have you worked on prior to maintaining the Linux kernel?
In the free software world: not much, really. Back in '86 I developed a 68000-based do-it-yourself personal computer which was rather fun. Jon Fairall at ETI magazine published the design articles and quite a few people built the systems up. A couple of people still have running systems, apparently.
Q: What do you consider to be your greatest achievement/contributions to the open source cause?
Hard question, really.
One thing to which I have devoted quite some effort over the past 18 months is working with many other kernel contributors. Accepting work from them, working with them, testing and generally grooming the changes, redistributing it for other testers and ultimately sending the changes on to Linus for inclusion. I think it is fair to say that quite a lot of these people's work would not have made it into the 2.5 kernel had I not been providing that service.
Plus it is probably that the ext3 filesystem would not have gone mainstream if Digeo had not used it in their product and asked me to work on it.
Q: Do you have any pet likes and dislikes about the open source community?
Well, confining the question to the kernel development team:
A pet like would be the closeness between the users, testers and the developers. It is a really tight and fast feedback loop which enables us to identify and resolve problems quickly. It also allows us to feed ambitious changes into the kernel and get them settled down quite quickly.
I believe that this is a much more effective process than that which is available in traditional provider/customer commercial development.
Pet dislikes? No big ones, really. Sometimes, some good changes (and good people) tend to fall by the wayside due to lack of diligence, or effort, or social nous. This is something which I have been trying to address.
I do tend to go a bit crazy over inadequately commented code!
Q: How did your relationship to Linus Torvalds come about?
Pretty simple: I send patches, he merges them. Occasionally we discuss them a bit.
We don't disagree about much: I believe that his way of doing things is sensible, and works. So I simply study that way and try to ensure that the changes which I send fit into that way.
Q: Are you close?
No. It is very much a technical/professional relationship. We live a few miles apart and have met a couple of times for lunch.
Q: How did you feel when Linus asked you to maintain 2.6?
Fairly unsurprised, really. I have been very active in the development of 2.5 and have a broad knowledge of the kernel and a decent understanding of how Linus wants things done.
From a personal perspective I was pleased with it: I am quite keen to see Linux be as useful as possible to as many people as possible, and this is a good way in which I can continue to contribute.
Q: Why do you think you were chosen to take on this role?
Breadth of understanding, familiarity with the changes which went into 2.5 and general ability to work with people via e-mail, I guess.
Q: How does your new position with OSDL work? Are you employed as a full-time, permanent employee or are you working on a contractual basis?
There is a contract between OSDL and Digeo under which Digeo provide contracting services to OSDL for the maintenance of the 2.6 kernel.
When Linus asked the question, I felt that I needed to place everything on a more formal footing with Digeo. And it was a huge stretch to ask a small company to devote their principal system software engineer to working on the public kernel for a couple of years. Digeo had supported me well, but at some point one does need to ask "where's the business case for this?".
Linus suggested that OSDL might be able to help Digeo out. OSDL agreed and it has worked out well.
Q: What problems are you anticipating with developing 2.6? What area of the kernel will be taking up most of your energy?
2.5 is in good shape. Much better shape than 2.4.0 was. But there are still many months worth of bugfixing before the 2.6 stream will reach the stability level of the 2.4 stream. So general diligence, problem tracking, working with testers, users and developers to get these problems mopped up will be the main task.
Later, commercial kernel distributors will come online with 2.6 and will have design changes which need evaluation and integration. New filesystems and new device drivers will appear. It's a large body of software, used by a large number of people for a lot of things. It will keep me off the streets.
Q: Could you elaborate on some of the new and improved features that will be incorporated into the 2.6 kernel? For instance, how different will the 2.6 kernel be from the 2.4 kernel?
Frankly, there will not be a lot of visible changes for the less demanding users. If one is just using a Linux box for desktop or small server applications, the differences will be subtle.
People do say that the 2.5 kernel is smoother and a little faster in desktop situations, and that is certainly something which we have focused on. It is considerable faster under heavy disk IO loads, has less tendency to exhibit jerkiness, etc.
The difference will be most noticeable at the high-end. 2.6 will be much more scaleable on large SMP machines than 2.4. 16 CPUs is a reasonable target, and we seem to be doing fairly well on 32-processor servers.
In terms of new features: there are quite a lot. Dave Jones maintains a nice list at http://www.codemonkey.org.uk/post-halloween-2.5.txt
Q: When can users expect to see the first release of the 2.6 kernel?
2.6.0-test1 was released this month (July 2003). At a mad guess, 2.6.0 may be three months after that, but who knows? It depends on testing.
But barring any disasters, I'd expect that we'll be in pretty good shape in September/October.
Q: SCO Group has recently been criticising the way intellectual property of other organisations or entities has been allowed to enter the Linux kernel. What's your opinion on this - how seriously do you take the group's claims?
I really haven't paid much attention to it. We spent some time scratching heads over what the alleged stolen code was, and came up blank.
I expect that it's something fairly minor. And I expect that when it finally is revealed, that code will disappear from the tree within six hours and will be re-implemented within a couple of days. Thus demonstrating that the "theft" was worth about $500.
So from a technical standpoint I don't take SCO's claims very seriously at all. It is only code, after all. And we write a lot of code.
Their claims that Linux could not have achieved its level of scalability without UNIX code are fairly insulting and quite wrong. When I first saw that I had to make sure I wasn't reading welovetheiraqiinformationminister.com
Q: What measures will you be putting in place to guard against future criticism/hype/legal action?
None, I expect.
Nobody owns Linux: it is available to every person in the world, and every person in the world is free to contribute to it. When they attack Linux they attack everyone. History will just roll over them and keep going.
Q: What scope do you feel Linux software has in either the consumer, small to medium business or the larger enterprise market? Is it for everybody?
For embedded systems, and servers small-to-huge, Linux is a great fit. The growth there is due to people discovering that fit, and wanting to use Linux in their applications. I see no reason why that should slow down.
The problem in the middle is the desktop. The challenges on the desktop are the breadth of applications, integration between them. Plus ease of installation, use and administration.
I believe that the kernel team have done their part for the desktop and it is now down to application developers and integrators. Sun's work on OpenOffice has been a huge contribution and I expect that if Sun remains committed to that effort they could do quite nicely in the desktop space. We shall see.
Q: What's the next step after 2.6, both for you personally and for the open source community generally? What still needs to be done to the operating system?
Me personally: I don't know, really. A couple of years commitment to the 2.6 stream, followed by "we shall see".
The community generally: no great change, I expect. Free software has its place in the world. It makes complete technical, commercial and social sense in many areas and it will continue to provide useful software.
Kernel futures? Well, the Linux kernel is a large and mature body of software which does one thing according to well-defined published interface standards. There is not much room in there for great leaps of software self-expression, and nor should there be.
People do have plans for quite significant changes to the kernel, and quite large changes went into the 2.5 series. But these are internal reorganisations and optimisations. They're really fairly small changes from a normal day-to-day external perspective.
There simply is no room for great flights of self-expressive fancy in the Linux kernel. It is very much an exercise in maintenance and gradual evolution. You'll see much more innovation and change in the application world than in the kernel.
And I really don't pay much attention to what is going on in the application world. Applications are just kernel testcases.
Q: Any advice for budding developers?
a) Fix bugs. I spent the first 18 months of my involvement with the kernel just working bugs with people on the mailing list. As a consequence I learned a good deal about a large amount of the kernel. It is a great way to pick things up, and you're doing useful things at the same time.
b) Switch off your ego. Don't be rude to people. Learn to give in. Learn to change your ways and perceptions to match those of the project which you are working in.
Sometimes it is difficult, and sometimes you end up believing that opportunities have been lost. But in the long run, such sacrifices in the interest of the larger project are for the best.