Back in 1999, D.H. Brown Associates, Inc. (later acquired by Ideas International in 2004) wrote a guest commentary for the newsletter, "inside the New Computer Industry," on "Linux and the Future of Unix," [PDF], which was posted on lug-list on June 23, 1999.
It's dynamite. It talks all about Project Monterey and AIX on POWER and ABIs and APIs and what the project was planning. Note this is before the project died or was killed, depending on your point of view, so it's before the alleged time period when IBM, according to media reports about SCO's thinking, "misused" Unix code by inappropriately using it for POWER. This is the third article this week debunking that theory. It seems the more research I do, the more Groklaw's readers do too.
Some of you may be new to this story, so for you, here is some background information. For a 1999 press release quoting a SCO VP on AIX on POWER, read this article. For more detail on Project Monterey's plans for AIX on POWER and whether it wasn't allowed to participate, check out the article just before this one. For earlier Groklaw research on whether SCO knew at the time that IBM was using SVR4 on POWER, read this one and another I wrote way back in July of 2003. I believe this D.H.Brown article puts the last nail in SCO's coffin on this subject.
The D.H. Brown piece begins by stating clearly that back in 1999, it was beginning to look like Linux was the future, and it was already capable of competing with SCO:
THE HIGH LEVEL OF ACTIVITY on both the Unix “Classic” and Linux fronts during the past few weeks has, I believe, made the future direction of Unix/Linux rather clear. One of the key shifts which have occurred is that Linux has clearly established itself as a dialect of mainstream Unix. It’s also begun to look as though Linux is eventually going to be transformed into a full-fledged enterprise-class operating system, although that’s not yet a certainty. . . .
It’s become pretty obvious that, barring a muck-up of truly monumental proportions, the dominant implementation of Unix for IA-64 in the near-term will be the IBM/Intel/SCO version currently known as Monterey/64.
Longer term, it now appears as though the Monterey distributions and Linux will fight it out for leadership of the Unix-on-IA market. . . .
The big loser in all of this is Microsoft, which seems likely to be faced with a more-or-less united Unix-on-IA-64 front based on AIX in the short term and Linux in the long term. . . .
The big challenge for SCO, and hence for Project Monterey, is to move the OpenServer customer base to UnixWare before they go elsewhere. It’s not Linux, which while not yet ready for the more demanding applications served by enterprise-class Unix implementations is demonstrably ready for the replicated application market which accounts for much of SCO’s business . . .
So even back in 1999, Linux was no little bicycle compared to a racing car. It was in the race, lacking some enterprise features, but already able to compete for the kind of business SCO had.
The paper also talks about whether SCO's theory of Project Monterey being only for Intel is correct:
It’s Happening in Monterey
The real action on the Unix front is within Project Monterey. Last month’s status report from its organizers revealed that Monterey is not, as previously thought, the code name for the AIX-based implementation of Unix for IA64 being developed by IBM with a little help from Intel, SCO, and Sequent. Rather, it is a broadly based, single source-tree initiative encompassing POWER/PowerPC, IA-32, and IA-64, and, so far, Alpha. In reality, Project Monterey is nothing less than an across-theboard, frontal assault on NT, the 64-bit OS component of which is Monterey/64. Among second-tier suppliers, in addition to Sequent, Acer, Bull, Fujitsu/ICL, and Unisys have already signed up.
But here's more. It seems there was a deliberate effort to include API and ABI compatibility:
The aforementioned update also revealed that the efforts to integrate AIX, UnixWare and Dynix/ptx (Sequent’s ccNUMA version) and port key IBM middleware for both the IA-32 and IA-64 platforms is moving right along: The first releases of UnixWare 7 (the IA-32 Monterey platform) incorporating the new features are scheduled for the fourth quarter of this year. Sequent will provide API and ABI compatibility with the UnixWare family of products and re-brand its Dynix/ptx operating system UnixWare ptx. SCO will supplement its UnixWare 7 products with initial AIX libraries and headers for application support, as well as AIX system management enhancements. These releases will be preceded by one in the third quarter incorporating Compaq’s NonStop Cluster capability. With the first IA-64 system prototype now anticipated to appear next quarter, the IA-32 market is looking increasingly attractive, and the Monterey offering is maturing rapidly. . . .
Also announced last month, with even broader support than that for Monterey itself, was a separate initiative to develop a standard Unix on-IA Developers Guide (UDG). This will result not merely in a common API but also a common ABI for the implementations from most Unix system vendors and SCO. In addition to the Project Monterey ringleaders, Compaq, HP, and Bull signed on, as did several leading ISVs. The good news (for customers and ISVs anyway) is that applications written strictly to the standard API and ABI will run under any compliant OS, not just UnixWare or Monterey/64. With IBM, HP, and Unix-on Intel market leader Compaq (with 37 percent of the Unix-on-Intel market server) already committed, the choice for Unix-on-Intel suppliers is pretty simple: endorse Monterey
or die a slow death. The specification is due to be submitted to The Open Group for fast track review around the end of next quarter.
Conveniently for those wishing to provide a bridge from IA-32 and -64 to their proprietary implementations or foolish enough to continue with plans to port their proprietary implementations to IA-64 in the teeth of the Monterey gale, the Developers Guide will come in two pieces, the application-independent UDG Programming Interfaces (UDG-PI -- I trust the reason it’s not the Unix Programming Interface Guide is obvious!) and the OSindependent common OS and Driver Interface Guide (UDIG).
So, Open Group. Time to dig up that specification, methinks. I know I'm wildly interested in knowing more about those "common" ABIs and APIs, and I imagine some SCO victims might like to know more about it too. While we wait, we might as well go digging ourselves and see what we can find on this little corner of history.