Comment: Why Linux could be the new Copland

 

Gallery

Posted on 25 Oct 2000 at 17:58

Copland was the operating system meant to succeed the Mac OS 7. But it just drifted along, its development largely driven by the demands of its engineers rather than the needs of Apple's customers. The project went on for over three years, with little notable progress.

When someone with half an ounce of technical sense and some management experience - the then-chief technical officer Ellen Hancock - finally took a look at Copland, she was so horrified by what she found that she killed it. This initiated the search for a new OS that would end with NeXTStep, Steve Jobs' return and Mac OS X.

Copland was a prime example of what happens when management leaves engineers to define and develop a project. Few engineers want to work on the kind of slow, steady development work that's essential to a mature operating system. With Copland, new features would be added and engineers would abandon optimising and bug fixing their own code to work on the "cool new stuff". The plan for the project was constantly shifting, as management failed to give direction or enforce realistic deadlines. Had it not been killed, Copland would have killed Apple.

If you believe some of the mutterings coming out of the Linux camp, the same thing may be happening to the operating system that was going to change the world. Developers have described the code of the Linux kernel as "spaghetti" and some comments on Slashdot describe how "No one wants to work on the hard things; they just want to add features. Quickly." This is all rather worrying for those who saw Linux as the best chance to avoid having Microsoft run the world. Given that Apple doesn't want to give the majority of the computer-using world the chance to run its operating system by porting Mac OS X to Intel, Linux is the best hope for the majority of computer users to escape the yoke of Microsoft and its kludgey, feature bloated mess of operating systems.

Linux advocates will claim that, ultimately, a form of Darwinism will sort things out: features that users want will be developed, because there will be a demand for them. However, I can't see where the mechanism is that allows user demand to be transmitted to coders. Instead, Linux is driven by the demands of its own developers, and largely those demands are to work on interesting and challenging problems. Those problems tend not to involve improving things that already exist, except by replacing them with entirely new systems, which is a recipe for disaster in a complex OS where different parts rely on each other.

The problem, though, isn't with the Open Source model as such. Source code being open has numerous advantages, from allowing developers real access to every feature of the OS to a huge peer-review network. But without management driving Linux towards a goal of meeting established user needs, it's difficult to see it avoiding the Copland fate of never getting close to meeting those needs. If Linux is to become truly complete, it needs to start focusing on more than simply the desire of developers to do cool work. And if the developers who contribute to Linux can't do that themselves, then the entire project may ultimately be remembered more for its contribution to management theory than for leaving a usable operating system.

Author: Ian Betteridge