Feeds

Insiders reveal SCO's Monterey disarray

A marriage of unequals

  • alert
  • submit to reddit

Boost IT visibility and business value

Letters First the sideshow, then the scoop. A former SCO insider puts the relationship with IBM over Project Monterey in an entirely new light.

But first, we're delighted that after a long correspondence over a fortnight with Groklaw editor Pamela Jones, a potentially damaging series of articles about SCO and Project Monterey has been corrected. SCO has made an absurd claim that it didn't know IBM planned to port Monterey to POWER - and yet that was a publicly-stated goal of the project from the outset. But just to clarify one issue, Peter Houppermans writes -

I think the worst aspect of your article is the "retrospective updates" that you allege Groklaw to have put in as a response to your article.

We're happy to clear that up. The Groklaw articles were corrected before we published our account of the saga. As Pamela herself wrote [April 29, 2005 4:00:29 PM PDT] -

I read it again, and I see what you are saying. So I changed the stories to reflect what I now understand, and I'll do an article to highlight it too.

I want to thank you very much for bringing this to my attention.

No problem. For some reason, or combination of reasons, The Mystery That Never Was diverted the community's energies, for almost a month. We're glad to help it back on track - and add something new to the discussion.

A former senior employee at The Santa Cruz Operation during this period has stepped forward to shed light on the project. It's an angle we haven't heard before.

Your article is a very good rejoinder, but there is even more to the story.

Firstly SCO considered themselves a big player. Late in the 1990s Compaq was selling in the region of $1 billion a year of hardware to run SCO operating systems. IBM's number wasn't as large, but it wasn't trivial either. SCO figured you could add the hardware and software ( around $200 million) numbers together to get a true appreciation of the size of the company and compare it to others such as Sun.

The important thing to remember that Groklaw has overlooked, or doesn't understand, is that kernel and userspace are separate. OpenServer had done well, but the kernel was limited to two processors and getting very long in the tooth. UnixWare's base (SVR4) had gone truly multi-processor in 1989. That is why SCO acquired it in 1995.

The plan was to add "the enterprise" to SCO's customer base, and to do that you needed serious software that could run on serious hardware. There was also a datacentre acceleration project that some vendors threw money into that was supposed to bring some enterprise functionality early (IIRC Unisys and ICL parted with a few million for this). UnixWare used to do really well in AIM/database benchmarks on x86 hardware. The idea behind Monterey was to combine the best pieces of AIX and UnixWare kernels. For example, the AIX memory manager had a good reputation.This would result in a new, combined kernel for the new enteprise hardware.

SCO was expecting to migrate their OpenServer customers to UnixWare and especially allow OpenServer binaries to run on UnixWare. Some of the tools, especially the management tools would also be ported. (Monterey was always going to run on 32 bit and 64 Intel chips with IBM seperately having it on PowerPC as you pointed out.)

Ultimately it wasn't Linux that killed Monterey. SCO simply couldn't put the number of engineers on the project as they had originally agreed (it was going to be 50/50). So slowly over time IBM shouldered more and more of the burden until it all fell away. The processor being repeatedly delayed didn't help.

I have always wondered why IBM never sued SCO for breach of contract! [name withheld on request]

So SCO couldn't afford to keep its part of the bargain?

Reader Skip in Exeter writes, rather sarcastically -

You will not question The Groklaw.

Groklaw only wants what's best for you.

Groklaw is your friend.

All who oppose The Groklaw are servents of the SCOX, and will be cast out to the wilderness.

Assist the Groklaw and report unbelievers, fabulous prizes to be won...

Touchscreen pioneer Gene Mosher writes -

Very good work on today's Monterey story. From early 95 to late 97 my own software, ViewTouch, only ran on AIX.

Then we ported it to Red Hat 5. It was barely an hour's worth of work - just a few library path adjustments. The move from AIX to a GPL'd OS, Linux, was clearly a liberating step. AIX was a totally professional OS and was virtually flawless as a technical achievement, as far as it went. The graphic tools for installing and managing it could be handled easily by anyone who was neither a system administrator nor a command line master.

AIX was proprietary, however, and it did cost serious money - it was nearly equal to the cost of the hardware, in a time when hardware was getting less expensive but was still far from the commodity that it is today. AIX updates were not quite frequent enough and the news about AIX was, by today's standards, sparse. The community around the OS barely existed. Every piece of software that extended the usefulness of AIX (X, Motif, debuggers) also cost serious money and was proprietary. X and Motif were pretty good layers to make all the UNIX OS's graphical, etc., but they were nearly dead from a lack of fresh air. They were proprietary and stuffy - absolutely nobody was doing anything with them except using them to build widget toolkits.

That was, apparently, the extent of the plan by those who controlled them. Linux, the GPL workalike, needed equivalent extension workalikes for itself - Lesstif, for instance.

As the various software components died, or were recast in GPL versions, so, too were the companies & organizations behind the software fated to die unless they could recast themselves, as IBM did, and as SCO refused to, hanging on to the ugly, bitter end. For SCO it is indeed ugly, and bitter. For those of us who were there, as you and I were, knowing the difference between what happened and what somebody says happened is easier.

While we can we have to tell it the way it actually was, and we can only hope that doing so will be enough to keep the truth separate enough from the myth to remain the truth. They can't pay you enough for what you do.

Gene Mosher

And thanks to Peter Norman for pointing to many unanswered questions.

Yes PJ is a bit off base about IBM's Linux plans, but you left out a few important things that are every bit as serious. Nothing is ever completely straightforward with a company as big as IBM.

IBM has always had different parts of the organization working for conflicting goals. Look at the FS vs. 360 wars or the development of VM/CMS.

First the research showing Monterey was always intended to run on the Power PC was aimed at SCO's claims that they never knew IBM was using certain system V code in AIX. It wasn't intended to be a great discovery. It was intended to be a refutation. Caldera knew IBM was using the system V print code in AIX 5L.

Second there is the Trillium project. All of the parties IBM, Caldera and SCO had a foot or more in the Linux camp. This should surprise no one, since IBM is famous for hedging its bets. When the Itanium flopped IBM had plan B ready to go.

Since you claim knowledge of the circumstances, if you want to contribute something new, here are some unanswered questions.

Was there ever a formal cancellation of Monterey, or did IBM just reneg on its marketing commitments on the grounds that they were pointless? What compensation did IBM offer Caldera (Ransom Love made this claim in an interview), and why did Caldera refuse it? Did they refuse compensation in order not to lose their right to sue (Ransom Love implies they considered it)? This indicates a great deal more continuity of planning than SCO have admitted. There would be a number of unpleasant legal consequences should Caldera have planned to sue a year earlier than Darl has said they did.

At the end of May 2001, after the Santa Cruz deal closed, Caldera announced they would ship Monterey in the second half. Did they do so? If not, why not? If so, why did they stop selling it? What is the relationship between Unix 8 and Monterey? Why did Unix 8 get rebranded? The Monterey contract is incomplete by itself, since it refers to work scope documents to be created during the project. What is in those documents? Did IBM ever exercise or threaten to exercise the change of control clause in the Monterey contract?

Peter Norman

To which we can add one more question: does the statute of limitations allow IBM to sue SCO for not fulfilling its part of Project Monterey? Or perhaps this is so damning that IBM is saving it for the trial. ®

Related story

SCO, Groklaw and the Monterey mystery that never was

5 things you didn’t know about cloud backup

More from The Register

next story
Munich considers dumping Linux for ... GULP ... Windows!
Give a penguinista a hug, the Outlook's not good for open source's poster child
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Intel's Raspberry Pi rival Galileo can now run Windows
Behold the Internet of Things. Wintel Things
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
Eat up Martha! Microsoft slings handwriting recog into OneNote on Android
Freehand input on non-Windows kit for the first time
Time to move away from Windows 7 ... whoa, whoa, who said anything about Windows 8?
Start migrating now to avoid another XPocalypse – Gartner
You'll find Yoda at the back of every IT conference
The piss always taking is he. Bastard the.
prev story

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.