I’m probably going to piss a few people off with this, but it’s something that’s been rattling around in my head for a while, and I wanted to get it posted somewhere. This might not even make much sense. 😉 Also, please note that I’m not knocking your favorite OS when I classify it as a zombie OS.
So, what is a zombie OS? A zombie OS is an OS that “should have” died, but has been kept alive and at least somewhat up to date by its community. Or, maybe it really did die, but its community has brought it back. (By “should have” died, I don’t mean that the OS deserved to die, just that the situation that it was in meant that it would have died if it weren’t for the community.) Either way, it’s now “undead,” if you will.
Most zombie OSes are now considered hobby OSes – OSes that most people play with for fun, and then reboot into a more mainstream OS (or switch to a more mainstream computer) for daily work. That said, there are often many die-hard users that use such an OS as their primary OS. At one time, most of these OSes were commercially sold, but their developer has abandoned the OS, or has gone out of business. That doesn’t mean that there’s not a new owner commercially selling it to the hobby market – in fact, in many cases, that is the case.
Why use a zombie OS? Quite a few reasons. For starters, nostalgia – you may have used the OS before, you liked it, so why not play around with it nowadays? That happens with a lot of dead OSes, too – OSes that have truly been abandoned, and the community around it exists solely to have fun with stuff they used years ago. Alternately, maybe you’ve always been using it, it fits your needs the best, or it has some features that you really like, so why stop now? Or, maybe you’re interested in using alternatives to the mainstream OSes, and as zombie OSes were usually well supported in their past, there’s usually more support available for them than for OSes that began as hobby OSes.
So, what is there to know about them?
AmigaOS is probably the example that defines the term. Originally developed for Commodore’s Amiga line of computers, it was abandoned when Commodore went out of business in 1994. However, the Amiga was well ahead of its time when it was launched, and had a large group of rabidly loyal fans. So, why give up your platform just because its maker went under? I’ll admit that I don’t know all the details (I’m not an Amiga user,) but as I understand, eventually, the rights to AmigaOS were acquired, and development continued. And then a clone of the OS was developed. And another clone, too. And then new hardware was developed, and the OSes brought to that new hardware. And then someone pissed someone else off, and the lawsuits started flying – a rather common theme in the zombie OS world.
My personal theory as to why this happens consists of several factors. First, when a company abandons a closed-source OS, the rights to code contained within may not be clear. While this is difficult enough to figure out when the company’s still alive, when a company goes out of business, it gets worse. The second factor is that, due to the rabid loyalty of the fans of such an OS, there’s a surprising amount of money in marketing to those users, in most cases – many will pay anything to not have to switch to a mainstream platform. However, there usually isn’t enough money to support multiple companies fighting over the same userbase, so there’s a natural tendency to want to shut down any competition. Therefore, lawsuits happen. Add in the fact that the users of a zombie OS tend to be willing to fight against any threats to their OS of choice, and then you get the userbase itself fighting over the legality of the OS.
Unfortunately, this sort of thing tends to tear communities like this apart. And, remember, there’s usually not enough money within such a community to support multiple companies. The same applies if the community is divided, except now, parts of the community are fans of certain companies, and refuse to buy from other companies. The upshot is that there ends up not being enough money for anyone, and then the platform can completely die, as most of the users become disillusioned with the infighting, and development often slows or stops when lawsuits occur, further disillusioning users.
Another thing that the Amiga community is legendary for is vaporware – one quote I’ve read states that, “[w]hen it comes to spewing ‘vapor’ the Amiga universe is a gasoline truck after a head-on collision with a turpentine factory.” Someone announces a new product (usually hardware, although it happens with software, too) that will revolutionize the world, and bring the Amiga back up to compete against the PC and the Mac… and then the launch date starts slipping. If it ever does come out (usually years later if it happens,) the specs won’t be anywhere near competitive (and often won’t even be what was claimed) by the time that happens, and the price will usually be extremely high relative to commodity hardware, due to the low volumes. Then, when it doesn’t come out, or doesn’t meet the goals set for it, users get disillusioned, and leave the community.
This happens because people such a community generally want such a thing to happen, so they’ll believe it when people tell them that something’s going to happen. Tons of hype is generated – and remember, the users tend to generate hype amongst themselves, too – without any skepticism. Often being part of the community themselves, the people making these claims often have no idea what they’re up against, and fail miserably at their goals.
At least, last I heard, the lawsuits have been resolved, there’s a choice of three OSes (AmigaOS 4, MorphOS, and AROS Research Operating System,) and twomotherboards that I know of.
Now, what about some other examples?
RISC OS is another such zombie OS. (I do use this one, as a hobby OS.) It was originally developed for Acorn’s Archimedes line of computers, and later the RiscPC. Acorn was eventually forced out of their primary market, the educational market, by competition from Windows PCs, and closed down their workstation division in 1998. Again, rabidly loyal fans kept the platform alive, and a company called RISCOS Ltd obtained rights to develop desktop versions of the OS from the company that at that time owned the OS, Element 14. Several companies got into the fray of making hardware, most of it clones of the low-end A7000+ machine, although a few decided to make updated replacements for the RiscPC.
Of course, much of this hardware was announced long before it was ready, to generate hype – something easily generated in such a community with a new hardware announcement. And, of course, much of it was vapor. One machine, the Microdigital Omega was released before the hardware was finished, and the company that manufactured it ultimately ended up disappearing.
Another company, Castle Technology, managed to release their machine, the IYONIX pc, on time, and quickly squashed bugs that were found. Due to a quirk of early ARM CPUs compared to later ones (the oldest ARM CPUs used 26-bit addressing, and even after 32-bit addressing was added to ARM CPUs, Acorn stuck with 26-bit addressing for RISC OS. This wasn’t a problem until later ARMs dropped 26-bit support,) a new version of the OS had to be developed. While most of the details are secret, it is known that they obtained the rights and code to do this from the owner of the OS at the time, Pace Micro. Later, they purchased all rights to the OS from Pace.
Then, lawsuits started happening over who owned the OS, who had the rights to do certain things with the OS, and such. The community divided into separate camps (which it had already proven itself to be good at, with the Microdigital Omega and the IYONIX’s fans fighting amongst themselves,) and much pointless argument occured.
Ultimately, Castle discontinued the IYONIX due to RoHS regulations, and the only current version of RISCOS Ltd’s version of the OS was (and still is) for RiscPCs and the like – there was another 32-bit system released, Advantage Six’s A9home, although RISCOS Ltd has been unable to release a finished OS. Castle eventually decided to release a shared source version of the OS to RISC OS Open Ltd, once the rights had been secured. While there’s still two camps within the community, there seems to be much more momentum behind RISC OS Open’s efforts, and individual developers are able to contribute to the OS, and port it to new hardware in their free time (and a port to the Beagle Board is underway.) Also, because ARM is currently pushing their architecture as an option for low-end machines running Linux, low-cost hardware is coming out that is suitable for RISC OS, from commodity hardware channels.
Now, a zombie OS doesn’t have to be on proprietary hardware.
BeOS is an OS that ultimately died when its developer, Be, was purchased by Palm. BeOS had already been running on commodity x86 PCs for a while by that point, and that’s where most of the userbase was by that time.
A few years after Be fell, a company called yellowTAB released the ZETA operating system, meant as a successor to BeOS. As is the norm for zombie OSes, claims that were made for the OS weren’t met. Worse, there were allegations that yellowTAB stole BeOS source code to develop it – after which the product was discontinued.
The story doesn’t end there, though. An open source reimplementation of BeOS, Haiku, is currently being developed.
What about zombie OSes that buck the trends of infighting, legal issues and vaporware, though?
OS/2, IBM’s attempt to replace DOS on their PC line, ultimately failed due to a combination of a lack of marketing on IBM’s part, high system requirements, and strong marketing on Microsoft’s part.
IBM, of course, didn’t go out of business, unlike the other examples. They’re still around. They licensed OS/2 to Serenity Systems, who released an updated OS/2 as eComStation. There have been some delays, but from what I’ve heard, things eventually get released.
Amazingly, the community has stayed largely intact, with little infighting that I’ve seen. I think the fact that its original creator is still around has helped, because it keeps any legal issues from being an issue, and it makes it harder to create a competitor to the OS.
Now, here’s a weird one for you.
Windows XP. Yes, that’s a zombie OS. Microsoft tried to kill it, but the community hated Vista so much that it kept it alive, and Vista wasn’t suitable for netbooks, so Microsoft had to keep it alive to keep people from switching to competitors. I think this is the only case of a zombie OS whose creator ended up having to actively sell and support it after trying to abandon it, at least outside of the corporate market. (And, in the corporate market, you usually use such an OS because a mission critical application requires it, not because you want to use it (and often, you DON’T want to use it.) Such an OS is a legacy OS, not a zombie OS. Zombie OSes are abandoned OSes that the users want to use, but don’t have to, legacy OSes are abandoned OSes that the users have to use, and may not want to.)
There was similar backlash when Microsoft announced that Windows 98 was entering extended support, causing Microsoft to continue extended support for 2.5 years after they planned on discontinuing such support. However, I don’t believe Microsoft sold Windows 98 during that time.
Now, are zombie OSes bad? No! Zombie OSes are often innovators that were pushed out of the market, and often have interesting features that can’t be found elsewhere, or aren’t done well on other platforms. Zombie OSes were intended to let you get stuff done, and occasionally, they can even be the best tool for the job. It’s just that they’ve been abandoned, and now the community, in one way or another, supports them instead.
So, if you’re in a zombie OS’s community, here’s some advice for helping keep the OS alive, and not driving yourself insane.
- Be skeptical. Often, people will try to appeal to your emotions with new announcements. Investigate their claims before jumping on the bandwagon. If you jump on every bandwagon that comes through, you’ll get let down a lot.
- As a corollary, if you’re developing hardware or software for a zombie OS, be careful with your claims. Make sure they’re things that you can actually do, on the timeframe that you’re claiming. Nobody likes vaporware.
- Work with, not against, people. Fighting just distracts from what’s important. Granted, some people just can’t be worked with.
Try to not take things personally. This especially goes to long-time users. Taking things personally results in emotional reactions, which are dangerous. - Avoid getting separated into a camp. Sometimes, this is unavoidable, but generally this isn’t good for a platform.
- On the flipside, zombie OS communities typically can’t support dead weight for long. If a company that you support appears to be dead weight – that is, they can’t do what they claim, or they haven’t contributed to the platform when others have – it might be time to support someone else instead.
- Remember to have fun. Not everything is serious business. Taking things too seriously results in flamewars and emotional response, rather than constructive discussion and logical response.
- Constructive criticism is good. If there’s something that needs work, mention it. If someone’s mentioning an area where something needs work, don’t take it as an attack on the OS.
- Be careful about rabid fanboi-ism. This leads off of the previous point somewhat, but it can alienate new users (yes, there are sometimes new users for a zombie OS,) especially when claims are made that problems with the OS are actually the user’s fault. Sometimes people just want to get stuff done. Sometimes your platform of choice isn’t the right answer. That’s OK.
- To spell the previous two out in simpler terms: Every OS Sucks. OSes are tools, not religions, and every one has its weaknesses. The best OS is the one that lets you do what you want the most effectively. This is different for every person.
- If you’re in a position where you can make decisions for the future of the OS, think through your decisions. Discuss them with others, if possible. Generally, a workaround for a design flaw will cause less pain now, but it will probably cause much more pain down the road. It’s usually worth it to fix the flaw, rather than work around it. However, if fixing it will cause too much pain now (excessively breaking compatibility with existing software, or the fix will take too much effort to do in a timely manner,) consider working around it, but plan to do the real fix in the future, and let developers know this is going to happen, and that they need to be prepared, to soften the blow.