Unix's Creator Hates Linux
And, as you might guess, Linux users are a little miffed.
By Steven J. Vaughan-Nichols
Sm@rt Partner
May 6, 1999
With the net, there's no question about a tree falling in the forest and no one hearing it.
If someone makes a comment anywhere, even in the rarefied air of the IEEE publication Computer, it will be heard across the net. Especially, when it's Ken Thompson, Unix's dad, saying in an interview [ http://computer.org/computer/thompson.htm ] that "My experience and some of my friends' experience is that Linux is quite unreliable. Microsoft is really unreliable but Linux is worse."
Linux users would have been screaming at a deafening level had it been Bill Gates been shooting his mouth off. But, this... this is different. As is, Linux users on the Usenet newsgroups and such popular online discussion sites as Slashdot are more quietly protesting Thompson's comments. I see such common themes as Thompson is suffering from old-fogey disease, that he's jealous of Linux because his Inferno and Plan 9 operating systems haven't taken off, or that-believe it or not-that he doesn't know what he's talking about again and again.
At the same time, though, I see writers who are painfully aware that they're writing about the Old Testament God of Unix. These people praise his current work, comment that he must not have seen recent versions of either Linux or Windows, or even admit that Linux does have some problems. No one, for instance, is going to say with a straight face that Network File System (NFS) on Linux works as well as NFS on Solaris.
I find myself agreeing with those who say Thompson must not have looked recently at either operating system. Linux is stable, Windows isn't. It's a matter of fact, not opinion.
All of which, I think, though is missing the point of what the real difference is between Thompson's and Linus Torvalds' visions: how one develops software. If you read Thompson's interview closely you'll see someone who is convinced that the best way of building an operating system, or anything else, is with a small group of great developers. The Linux, Open Source, approach is to let the whole world in on development process.
Which works better? I'm on record [ http://www.zdnet.com/sr/stories/column/0,4712,2177209,00.html ] as liking Open Source and my position isn't changing. There's also, however, a lot to be said for Thompson's approach of small, dedicated groups working on a project. It's just that Thompson's methods aren't used by most ISVs.
We all know the story. A great product comes out from the traditional method Thompson espouses, say the original Netscape. It defines the field. Time goes on and the small group of creators goes into management and is replaced by dozens of programmers, then by hundreds. Inevitably, the code quality goes down, the program becomes bloated, and other programs rival and eventually surpass it.
None of this is news. Frederick P. Brooks Jr.'s classic The Mythical Man-Month (ISBN: 0201835959) spelled it all out in 1975. Something that really ticks me off about the entire computer field, though, is how so many of us absolutely refuse to be aware of the field's history. Mistake after mistake are done over and over again, simply because no one even bothers to look at the lessons of the past, much less learn from them.
For example, there's no reason why open source can't be combined with the small group approach. This is exactly the development methodology used by the BSD Unixes [ http://www.zdnet.com/sr/stories/column/0,4712,398025,00.html ]. Despite that, very few developers try this path.
Even by itself, though, open source, potentially, can break the development bloat cycle. With open source, multiple developers and peer-reviewers can attack large products without the straitjacket of large programming teams and their bureaucracy.
Thompson methods work-and for in-house reseller projects they should be emulated-but when it comes to software from outside of a reseller's firm, companies would do well to look first to open source developers, not ISV programmers, for theirprograms. They'll find that their products tend to be better and so will the solutions built from them.
Copyright 1999