Unix was an option, even back then. An expensive option, sure, but you could even run it on some types of Mac:
https://en.wikipedia.org/wiki/A/UX
Actually A/UX was a pretty amazing operating system. The GUI of a Macintosh with the underpinnings of UNIX. Just like OS X - only in 1988!
Unix licensing costs almost definitely.
A/UX was forked from UNIX System V Release 2.2, with "additional features from System V Releases 3 and 4 and BSD versions 4.2 and 4.3". It also had a TCP/IP stack, since before MacTCP (if I recall correctly).
I don't have any direct knowledge of Apple's licensing issues with AT&T, but I worked for SCO in the early 90s, back when it was a UNIX OEM, not a litigation zombie.
AT&T licensing fees for UNIX back in the late 80s/early 90s were fiendish; that's the whole reason for the ascendancy of Linux today. (Linus couldn't afford his own Intel UNIX shrinkwrap, so he began rolling his own kernel.) I heard a ballpark figure that SCO paid out $200 in royalties every time they sold a copy of Open Desktop 3.0, which included royalties on SVR3.2, a third-party TCP/IP stack, X11 (which was free), and OSF Motif (which wasn't) and IXI's X Desktop (the desktop and utility apps build with Motif/X11). This drove the price of a copy of ODT 3 up to the $1000-2000 mark depending on trim. SCO also paid royalties to Microsoft every time we sold the developer tools, because SCO had inherited the MS C compiler by way of their Xenix license in the late 80s, and SCO SVR3.2 was built using MS C.
The AU/X "additional" features from SVR 3 and SVR 4 was probably the result of a similar process to SCO's cloning of SVR4 features in the early 90s. SCO's UNIX license only covered SVR3.2. AT&T jacked their license prices for SVR 4 so much that going to true SRV 4 would have drastically raised the price of Open Desktop. It worked out cheaper to assign a couple of hundred developers to work for 3-4 years at cloning SVR 4.3 (needed to hit the standards compliance checkboxes required by customers), while keeping the AT&T SVR3.2 copyright declarations in the header files (and on the box).
My guess would be that Apple hit the same wall that SCO hit after 1995; AT&T licenses were too expensive and cloning features and bolting them on top of an ancient code base was also becoming expensive. (As I remember it, SCO bought a license for SVR 4.3 in the end and switched to that, some time in the mid-to-late 90s, too late to dodge the bullet of Linux gobbling up the Intel/Posix world.)
It took a long time for Mac developers to really buy into Cocoa, many of them saw it as a less-capable version of existing APIs rather than the future of Mac development. That viewpoint wasn’t entirely without reason, at first, but the longer you spent with Cocoa, the more clear it became that Carbon was a second-class citizen.
My other thought is that Apple didn’t just want tech, but the experience to develop it. That’s why acquisitions were at the top of the list. Apple has certainly bought a few other companies just to access their engineering talent.
1. Switch to using the Carbon API, and create a "carbonized" application that works on both Mac OS 9 and Mac OS X (same executable for both platforms, basically a special executable format and some restrictions on how you used various APIs)
2. Once you don't care about Mac OS 9 support, migrate to Project Builder (or at least GCC)
3. Eventually, migrate to Cocoa
The path was set up so that you could stop at any point along the way and keep shipping your application. In my personal experience, steps #1 and #3 could be difficult and labor-intensive, but step #2 was usually easy.
My understanding is that Quark got stuck and took too long to complete step #1, long enough that their customers didn't want to keep Mac OS 9 around just so they could use QuarkXPress and switched to InDesign.
Step #2 mostly involved fixing the parts of your code which used weird, non-standard C extensions that GCC did not support. Things like:
(long)*ptr = x;
Adobe got stuck on #3, which is understandable because it's an enormous amount of work with a relatively low payoff. The main drawback of not completing step #3 is that you're stuck with a 32-bit application until you complete it.That's hard to side with, when preemptive multitasking and protected memory wasn't a thing in Classic Mac OS. Those were some big sticking points when trying to Get Shit Done on a Mac, especially in the late nineties.
I agree Cocoa was amazing tech, but I don't see the sluggish migration from Carbon being because people didn't buy into it. I think it's more that Carbon worked, and there's just other things to put the expensive engineer's time to good us on.
My experience with the Mac developer community at the time was that someone new would come to the mailing lists and ask whether they should use Cocoa or Carbon for developing. These are people who don't have any legacy code and don't have a bunch of skills they've built up, working on greenfield projects.
A common response was along the lines of, "Carbon is a Serious API for developing Serious Applications, and Cocoa is a kids tool for making toys."
They probably looked at projects like FreeBSD at the time (1997-2000 era) and decided that too much time would be required to re-implement what they wanted to do, vs buying NeXT.
Only the NSA was exempt from this requirement, and they did buy a lot of NeXT's equipment.
NeXT was never about UNIX, the compatibility that it had was just to ease the porting into the platform, not to get away from it.
The Objective-C APIs were what mattered.
Likewise when it was reborn as OS X.
I attended an Apple session at CERN during the early OS X days, with the same idea being transmitted.
At this point, what would be the downside to open-sourcing the original code and putting it under GPL 3? Why hold onto IP that you aren't making any money off of?
Additionally, some of the games distributed by Ambrosia were written partially or entirely by outside developers. It's not clear if Ambrosia even had the source to all of their games, let alone the rights to relicense it.
https://www.reddit.com/r/VintageApple/comments/9v3gd0/macfor...
Someone else is seeding the same data as a torrent:
https://www.reddit.com/r/VintageApple/comments/a04o1k/macfor...
If you're interested in the 32x32 icon style for graphic art reasons, I wrote IconPush to search my old Mac OS 9 icon collection:
What features are missing?
User-created templates are such a pain in Google Docs that I would almost consider it a missing feature.
Tab stops that align to the decimal point.
Feature wise Word 2.0 is miles ahead of gdocs. In fact I'd rather use office 95 than the bloatware that came after it.
Office 95 was a beautiful thing too. Oh how I miss the no BS interface and the UI consistency of Windows 95 and its applications.
https://archive.org/details/macworld-magazine?&sort=date
https://archive.org/details/macaddict?&sort=date
This was how we knew what Apple was doing, how to keep computers running, etc.
There are some things I really miss about the classic Mac era. Computers were cool. The entire experience of using a computer was very consistent. Poking around in MacsBug or ResEdit was interesting. Install an app by dragging it to your hard drive, uninstall it by dragging it to the trash. Word 5.1a, a.k.a. the best version of Microsoft Word ever made. Still waiting for Google Docs to catch up in terms of feature parity, it’s not even close.
Plenty of things I don’t miss. No memory protection. Cooperative multitasking. Open Transport. As much as Unix is a bit of a mess, it doesn’t have any of these problems.
The only reason I still go back is for the games. A few of the old games can be played on new computers—if it ever got a PC port, there’s a chance you can run it in DOSBox, but the Mac exclusives got left behind, and a bunch of them were just cute little shareware pieces that never had a bunch of money behind them.