Software Interoperability, Hardware, and Next Year's Model

I was reading Standards and specs: Not by UNIX alone, which is a nice article on Unix software development. It made me pull out an older rant of mine and polish it up for this blog.

---

Software companies build a fundamentally different thing from hardware companies.

To most people, this is so obvious that it shouldn't even need to be stated. In the obvious ways, Most People are right. But there are non-obvious ways in which this is importantly true.

Toyota or Ford don't actually have to make next year's models "interoperate" with this year's models. I'm not even sure what "interoperate" would mean in the context of cars, beyond "they have to use some version of unleaded gas, and be able to fit on the roads, park in garages (I'm talking to you, Ford Excursion) and have the same user interface -- steering wheel, accelerator & brake pedals, etc.".

Auto companies can make everything else about their cars change from year to year.

They don't, of course -- there are strong rewards to not changing too much too fast, and for sharing ("conserving", in the genetic sense) parts within a product line -- both temporally (last year's model and this year's model have a lot of the same parts) and organizationally (our luxury model uses most of the same parts as the base model). But if someone wanted to radically change their engine without touching their car body or interior at all, they could. In fact, that's basically what Honda did with their Hybrid Civic. Looks just like every other Civic on the road, except for the little "Hybrid" sigil on the back.

In the same way, computer companies could radically re-engineer their hardware (motherboards, peripherals, CPUs) as long as they look the same to the rest of the world (e.g. programs). This is what Intel and AMD do every time they bring out a new product line. (Well, these days. The 286 to 386 jump was a doozy.)

But software? Software is a totally different thing. It has to interoperate. The lateral interoperation (between co-existing hardware) isn't that important to some software producers -- Microsoft deliberately engineers incompatibilities all over the place to keep the Mac a second-class computer -- but temporal interoperation, that's a big one. The Office 95/97 incompatibilities burned Microsoft pretty badly, although they'll never admit it.

This is arguably the defining distinction between the Unix and Microsoft worlds.

Most Unixes are built, maintained, and pushed forward by one of two groups:

• Software engineers who work for hardware companies, and whose job is to build a great OS which can help ship more hardware units. I'm mostly thinking about Sun here, but most other Unix vendors were in this camp: HP, SGI, DEC, etc. And Apple is now in this group with OS X being Unix underneath.
• Hobbyists: Linux and the BSD bestiary. These folks are not tied to any particular hardware, usually. These follow the original Unix in the way they're developed: by the people who use it, for the people who use it, and not directly for money.

Microsoft is a (relatively) hardware-agnostic software-only company (notwithstanding the Xbox or the Microsoft Mouse or Keyboard). Windows runs on most Intel x86 hardware.

Guess which set of software producers has sold the most incompatible versions of software?

Okay, that's a no brainer.

Apple navigated the 680x0 to PowerPC migration in the early 1990s quite well; I'm sure they'll handle the PowerPC to Intel migration just as well. Stuff will Just Work -- on expensive Apple-only Macs, but it'll Just Work. Mostly.

Unix is a weird case for a lot of people, I think. I remember doing a Sun 3.7 to 4.0.1 OS migration, which also involved a 68020 to SPARC 1 hardware migration at the same time. We had specialized video capture hardware to deal with, including all sorts of special code to drive it. We simply recompiled everything, and except for a few little things, it all Just Worked. Try that going from Windows 3.1 to Windows 95, or 95 to NT.

There are programs written in the early 1980s which would compile directly on any modern Unix these days. They might need a little tweaking for header files or libraries, but they'd Just Work. A lot of this is the whole command-line vs. GUI issue (all our fancy Unix boxes still act like they're talking to VT100 terminals from 1978, which in turn are not all that different from actual teletype machines from the 1950s -- cf. In the Beginning was the Command Line). The Unix programming model is so clean and spare, it has barely changed (regardless of what's under the hood in the OS) -- the clean separation of functionality and coherent interfaces simply make it Just Work.

Unix has a long history of having things layer on top of each other -- things continue to Just Work. Contrast this with Windows, which changes radically (and disruptively) every few years. That might be calming down; Windows 2003 seems to be more like "Windows 2000, but done right this time" than a totally new OS. But the Home edition of it (XP) still has some idiotically disruptive things in it compared to 2000. E.g. the My Computer and My Documents links disappear off the desktop. The claim is that having everything under the Start Menu makes it easier to learn Windows. That may be true, but it's sure annoying to someone used to Windows 2000. Sure, you can tell it to look like Win2k, but you still have to manually tell it to put My Computer and My Documents back on the Desktop. Stupid!

This is one of those clear cases where Microsoft is trying to make software the way that auto companies make cars -- "next year's model can be different because it'll be a new batch of people". Except it's not. The software market is a lot more mature than it was 10 years ago when Windows 95 came out. It's a lot closer to saturation. Even most home users are buying upgrades, not a first computer. And businesses? Wasn't Windows supposed to be the business OS? (Macs, of course, are the long-haired arty-farty computers.)

Businesses that plan for the future (i.e. businesses that will be around for the future) do not buy new OSes and throw the old ones away. They migrate: they have different versions coexisting. As much as it'd be nice to simply rip out everything and rebuild, it's simply impossible to do. If you have a big IT installation (and especially if you're providing a service, like web pages or email, or VOIP or something), you simply cannot do that. Won't work. You have to evolve, not revolve.

Any OS that makes it hard to migrate from one version to the next is a real pain. Unix is simple. It all Just Works. It has its pains, but it usually Just Works at this level.

Windows? Ha. This is an OS that doesn't have to worry about long-term OS uptime because urgent security patches come out monthly and therefore no box is going to be up longer than a month, because so many patches require a reboot. There are Solaris boxes at my company that have been up for 3+ years without breaking a sweat.

To summarize: software is NOT like hardware. It's not like automobiles, or appliances, or anything else that people replace. Software lives a lot longer than any single piece of hardware, has to play nice with other software, and most importantly, has to play nice with its descendants. The entire idea of "next year's model" is absurd and idiotic when it comes to software. There's only the next version. And that version MUST play nice, or you're going to piss people off.

It's entirely unclear to me if any Windows admin (who hasn't used Unix for any length of time) understands this. I'm guessing no.

It's entirely unclear to me if anyone at Microsoft truly knows this, either. Or is it just that if they understood it, they wouldn't be able to market their stuff without wanting to kill themselves in shame?