AIX 5L (the L standing of Linux affinity) was a stopgap operating system for those customers, so Unix users would stay with the operating system until Linux was fully ready for the enterprise. And we've learned that IBM began contributing to Linux at least as far back as 1998, and that it was public knowledge.

We also learned that it was always the plan that Project Monterey would be for POWER, not just for Intel. SCO wasn't involved in that end of the work, obviously, but many articles and press releases from the birth of the project onward established that this was the plan. And we also learned that SCO knew about IBM using SVR4 on POWER as far back as 2001, because it put up a glowing website talking about it.

So that raises an interesting question. If all the above is true, where is the monetary damage to SCO? For that matter, where is there copyright infringement? And it raises one final question: was SCO fully aware how quickly Linux would develop, that it would replace Unix, or did it take them by surprise? I have found the answer to that question.

In an article in August 2001 , in the Register, Caldera -- what SCO then called itself -- predicted:

"In two to five years Linux will surpass where Unix is now."

We knew oldSCO knew, when Project Monterey was going on, that Linux was the future and Project Monterey the stopgap, and now we find out Caldera had a clear picture too. But the date is significant. When Caldera's CEO made that prediction, and he was happy at the thought, it was after the August 2000 date SCO has marked in its 2nd Amended Complaint as being the date IBM began contributing to Linux in ways it now claims to take offense at. It's concurrent with or post all the dates in their complaint about IBM's behavior, except a January 2003 date. And it is after Caldera purchased oldSCO's Unix assets. In SCO's first amended complaint, they told this skewed story to the court:

77. As long as the Linux development process lacked central coordination, its direction was primarily aimed at meeting the computer needs of the Linux programmers themselves. As such, it posed little or no practical threat to SCO or to other UNIX vendors since the Linux developers did not have access to sophisticated high-end enterprise class mulitprocessor systems, nor they they have any particular interest in supporting such systems.

78. The entire direction of Linux development changed with IBM's entry into the open source community and its concerted efforts to control the community for its own economic benefit.

79. In furtherance of its plan to destroy its UNIX competitors, IBM has announced its intention to make Linux, distributed to end users without a fee, the successor to all existing UNIX operating systems used by Fortune 1000 companies and other large companies in the enterprise computing market.

What do you think? Did they present an honest and accurate picture to the court? Remember, this is their basis for damages claim, in the billions. In their dreams.

Anyway, as Richard Stallman pointed out way back when this all began, what IBM has contributed is useful, but not essential. And the kernel has always been centrally coordinated by Linus. That is still true, and IBM has no role at all in coordinating the Linux development process. They don't even get all the code they offer accepted. No company does. That's why from time to time, frustrated CEOs, like Computer Associates' executive the other day, put out annoyed remarks about the kernel not doing what they want it to do and how the kernel is "in danger" blah blah.

In their 2nd Amended Complaint, they reworded it like this, but the idea is the same:

The Functional Limitations of Linux Before IBM’s Involvement

80. The first versions of Linux evolved through bits and pieces of various contributions by numerous software developers using single or dual processor computers. Unlike IBM, virtually none of these software developers and hobbyists had access to enterprise-scale equipment and testing facilities for Linux development. Without access to such equipment, facilities and knowledge of sophisticated development methods learned in many years of UNIX development it would be difficult, if not impossible, for the Linux development community to create a grade of Linux adequate for enterprise use.

81. Also, unlike IBM, the original Linux developers did not have access to multiprocessor code or multi-processor development methods needed to achieve high-end enterprise functionality.

82. To make Linux of necessary quality for use by enterprise customers, it needed to be re-designed and upgraded to accommodate complex multi-processor functionality that had taken UNIX nearly 20 years to achieve. This rapid re-design was not feasible or even possible at the enterprise level without (a) a high degree of design coordination, (b) access to expensive and sophisticated design and testing equipment; (c) access to UNIX code and development methods; (d) UNIX architectural experience; and (e) a very significant financial investment. The contributions of IBM, which had access to UNIX System V Protected Materials and years of enterprise level experience, made possible this rapid redesign of Linux for enterprise use.

Nevertheless, Caldera's CEO Ransom Love said it would happen, way back in 2001, did he not? So was it impossible? Did he think so? There is a disjoint here. And that is phrasing it sweetly. So what we observers would like to know is, how many times does SCO get to file wild accusations, without proof, that don't match the reality they know perfectly well?

But the main point is, Caldera knew back in 2001 that Linux would replace Unix. Period. Not only that, they helped. Of course, back then Caldera's entire business plan was to merge Unix and Linux, and CEO Ransom Love even announced he would open source Unix some day, as you can verify in Caldera's 10Q of April 30, 2001 and their 8K of May 14, 2001. They wanted to merge the two, as Love explained back then, so they could "take Linux to 32-way systems. . . .On IA32 you can run smaller applications on Open Linux, or bigger back-office applicationss on OpenUnix, which on IA-64 you have OpenLinux and IBM's AIX 5L, which shares 70 percent common code with UnixWare. a lot of people are running their businesses on Unix, while Linux has a tremendous population on Web servers and other front-end servers. So we are taking both and combining them into one platform. . . . Our mission is to enable development, deployment and management of a unified Linux and Unix operating system." So Caldera wanted Linux on the high end, did it not, and was working to make it happen.

Earlier, though, what about Project Monterey? The stopgap? Why was it necessary? Here's how this April 1999 article on ITWeek described the reason for Project Monterey:

Only a few years ago Unix's original goal of providing a unified, non-proprietary operating system was lost in a sea of competing semi-proprietary versions of the platform.

In the last four years, however, the high cost of competing in the marketplace, the rise of Windows NT, and the reluctance of application developers to support more than a handful of Unix variants has forced a dramatic fall in the number of versions under active development.

Analysts expect survival to become even tougher for Unix players with the arrival of Windows 2000 this year, and Merced - the first 64-bit processor to Intel's IA-64 architecture - next year.

The goal became to offer a unified Unix, just one version, to counter the Windows threat. To make that possible, SCO, IBM and Sequent joined forces to publish a set of guidelines for developers to use so they could write for just one platform, so products would be able to run on any Intel Unix system without having to be rewritten or recompiled:

Compaq has also backed another initiative, recently launched by major Unix players, that could be as important as Monterey.

Leading Unix players - including IBM, SCO and Sequent - have agreed to develop and publish a set of guidelines for software developers and hardware manufacturers to make their products run on any Intel-based Unix system without having to be rewritten, or recompiled.

Compaq has joined Intel and HP in backing this standards effort, called the Unix Developers Guide, which is based on specifications drawn up by the Open Group's Unix98 initiative to standardise Unix features across different platforms.

While the Unix Developers Guide will not stop Unix players competing against each other, it will help them to fight a common foe - the one based in Seattle. 'If the Unix players want to compete with Microsoft, they have to make it a lot less irritating for independent software vendors,' says Eunice.

Intel, which is also backing Monterey, recognised this when the project was launched, putting millions of dollars into a fund alongside IBM to encourage developers to write applications for the platform.

'You're beginning to see a genuine desire for one Unix,' says Steve Wanless, senior marketing manager for Sequent. 'The goal is for developers to be able to write for just one platform.'

In an article entitled "Three Blue Letters, Marching Toward Merced", a Research Note by Jonathan Eunice, Illuminata, dated October 30, 1998, which you will have to buy to read, we find out why Project Monterey was needed, namely Unix was struggling in the marketplace, most particularly from the balkanization of the operating system, divided into proprietary versions, each with its own way of doing things. Customers were fed up:

Customers, application developers, and system integrators no longer benefit from, nor will they accept, 99 different variations on the Unix theme. Options are nice, but having too many hues, tones, and subtle shades proves counterproductive because it defeats economies of scale in purchasing, training, and development. That's as true for system vendors as it is for user organizations. Despite an industry-wide game of one-upmanship, most OEMs differentiated themselves only slightly via their house brand of Unix. Yet every year each must pour tens or hundreds of millions of dollars into development to support both the latest processors and innovations such as PCI, I20, Fiber Channel, nuSMP, and 64-bit processors. Consolidation, in one form or another, has become an imperative.

SCO, IBM and Dynix in the short term would continue offering their separate wares, but when the Merced chip was ready, then Project Monterey would come to fruition:

The real product convergence will occur around the Merced launch, or -2H00 on the current schedule. The merged Monterey product will be based on the AIX kernel. We've previously questioned SCO's ability to advance the UnixWare kernel for truly high-end systems, so it's good to see a foundation that provides for sophisticated preemptability, kernel threading, concurrency control, and other genuinely hard system design issues. This is one place IBM's Big Iron skills are hard to approximate, much less surpass. (footnote: Large projects demanding a systematic approach, such as internationalization and directory services, are its forte.) SCO will contribute enhancements, many related to outward system behavior and application packaging.

SCO's complaint portrays it that oldSCO was just swimming along nicely in the marketplace. This report says they were going down slow:

But SCO is under attack by Windows NT, and it remains a low-end provider with 80% of its business attached to its older OpenServer product, not its more modern UnixWare. It's argued multiple times . . . that it's got volume enterprise capabilities well in hand. With IBM's help, perhaps now it does.

So, who needed who, according to this? And now about the POWER architecture. Remember, this paper is dated 1998:

Monterey instances will ship for IA-32, IA-64, and POWER platforms. We expect virtually perfect source compatibility between versions, and perhaps source compatibility between versions, and perhaps useful binary portability of IA-32 executables on IA-64 systems. Intel systems will use a little-endian data ordering; POWER will use big-endian. While this mixed-endian scheme creates some compatibility issues for programmers and within data files, it solves other issues by making Intel versions compatible with Windows NT -- a good trade-off.

There were actually three products planned to come out of Project Monterey, not just one, in planned stages: first, there was a version of SCO's UnixWare for 32-bit Intel processors, with IBM middleware. The second entailed IBM and SCO incorporating UnixWare technology into AIX. Then would come the third, a Unix version that would run on Intel's IA-64 processor architecture. It would all run on PowerPC:

The result, the companies claim, will be a single Unix operating system product line that can run on IA-32, IA-64 and PowerPC platforms, in computers that range from entry level boxes to large enterprise servers.

SCO was counting on being the beneficiary, because it was having troubles:

One immediate beneficiary is SCO, which this week reported a loss for fiscal 1998, but claimed the deal would help it generate far greater revenues in the future.

SCO's ability to stay in the Unix market as it moves towards a 64-bit environment has been under question for some time, given the high levels of investment required -- estimated as at least $100 million annually -- and with many of its earlier partners, including Compaq, and Hewlett Packard, taking their own direction. . . .

Unix has been under threat from NT for the past couple of years, as Microsoft benefits from being able to present developers with a single applications platform, and more effective price competition.

The coming of IA-64 should lead to Unix being more cost effective, which will take away one of NT's advantages, but it is the fragmented nature of the marketplace that is the real stumbling block.

That was the plan and the hopes. But something went wrong, and it has to do with Merced. It wasn't ready when it was supposed to be. In May of 1998, Intel announced Merced would be delayed a year, and wouldn't be ready until 2000. Keep in mind that Project Monterey was designed to be a stopgap measure until Linux was ready. Now the chip is a half year late.

And there were press reports it was too expensive for the desktop, it gave lousy IA32 performance and had heating and other problems. There were even hints Intel wanted to dump Merced and jump to its successor, McKinley. In August of that same year, 1998, a headline appeared, "Is Merced Doomed?"

Touted as a major milestone for Intel and the computer industry in general, Merced, the company's first 64-bit chip, appears to be losing its luster because of delays, performance issues, and upstaging by other processor manufacturers.

Industry experts have called into question the wide-ranging commercial rollout of Merced, which has been pushed back from late 1999 to mid-2000. Instead, it now appears that the chip which will propel Intel deep into the 64-bit computing arena will be McKinley, a Merced successor that's touted as having "twice the performance" and likely to come out in 2001. . . .

"If Merced slips another couple of quarters...this could lead Intel to not market Merced as a product but use it only as a development vehicle," said Linley Gwennap, publisher of Microprocessor Report, writing in themost recent issue of the respected industry newsletter. "Sources indicate that [Merced]...is facing problems that could jeopardize [its] existence as a viable product," he wrote. "Even if that chip is compromised, however, IA-64 [the name of the 64-bit platform] itself is likely to prosper." . . .

Questions surrounding Merced's commercial appeal arise in part because the delayed launch puts it so close to McKinley. In May of this year the chipmaker said that Merced's launch would be postponed due to its complexity.

Previous statements from Intel executives can also be seen as encouraging computer vendors to wait. At a 1997 chip conference, for instance, Fred Pollack, Intel fellow and director of measurement, architecture, and planning, commented that McKinley will "blow your socks off."

"There's no question that more and more lately we're hearing the mantra 'Wait for McKinley," said Keith Diefendorff, editor in chief ofMicroprocessor Report.

Merced is expected to debut at a speed of 800 MHz—compared to today's 400-MHz chips--and be capable of processing six to eight instructions per every "tick" of the chip's clock cycle. That would constitute an architectural improvement over current and competing chips, according to the report authored by Gwennap. . . .

Despite these impressive gains, Gwennap points out that they would be considered more impressive if the chip came out in late 1999, as originally planned. By mid-2000, Merced's performance will rank it equally with other cutting edge RISC chips.

Although quite different from Merced in some respects, the 21264 Alpha chip from Compaq Computer will likely be available at clock speeds greater than Merced. Compaq is sinking considerable resources into Alpha and touting it as a highly viable 64-bit technology--especially because it is already on the market.

Folks started to abandon the Merced ship. Compaq stunned everyone by announcing that same August that it was dumping Merced for the Alpha chip, saying the Alpha chip was better, because it had more applications, and that by the time Intel delivered Merced, Alpha would be by that time 50% cheaper and two and a half times faster than Merced.

In that same article, Aberdeen then came out with the prediction that "Merced workstation units will reach 350,000 at most in the first year after the chip's release. Overall workstation sales for the same time will come to over 2 million."

Imagine you are IBM now.

So that is a little slice of Project Monterey history, to show you what really happened to Project Monterey. Things went wrong, things completely beyond the control of any of the participants in the project, including IBM. Had Merced worked and been delivered on time, would history have been different? Very possibly. But the plain fact is, it wasn't. And as we now know, the plan was to move some customers to Linux at the earliest opportunity anyhow, and so, when Merced failed to hold up its end, and customers were buzzing about Linux, IBM did what made sense in the market as it found it, not as it made it.

It will be interesting to see how SCO spins this history today when it tries to persuade the court that it should be allowed to amend its complaint yet one more time.