A virtual museum cataloguing nearly every operating system ever shipped — from CP/M to BeOS to Plan 9 — recently surfaced on Hacker News and lit up the comments section. It is easy to dismiss it as a hobbyist curiosity. Do not. For anyone who builds software professionally, it is a compressed history of every architectural decision, platform war, and design philosophy that quietly shaped the tools you use today.
Why Operating System History Is Not Just Trivia
Every OS in that museum represents a set of bets made by engineers and product teams about what users needed and what hardware could realistically do. Some bets won. Most lost. But losing did not mean disappearing without a trace.
- BeOS pioneered a pervasive multithreading model and a media-first architecture that macOS and iOS engineers later borrowed from heavily.
- Plan 9 (Bell Labs, 1992) treated everything — including the network — as a file. That idea lives on directly in Linux's
/procfilesystem and, more broadly, in the Unix philosophy that still governs how containers and microservices expose their internals. - OS/2 shipped genuine pre-emptive multitasking years before Windows 95, and its failure was commercial, not technical. It is a clean case study in how superior engineering does not guarantee market survival.
The pattern repeats across every decade: good ideas do not die, they migrate.
The Platform Lifecycle Every SaaS Founder Should Understand
Looking at a hundred operating systems side by side makes the lifecycle painfully obvious:
- Bootstrap — a small, opinionated kernel that solves one problem well.
- Growth — third-party developers build on the platform; the API surface expands.
- Calcification — backward compatibility demands accumulate; every new feature carries the weight of legacy decisions.
- Disruption or death — a leaner challenger arrives and the incumbent either adapts (Unix → Linux) or fades (Digital Research CP/M).
SaaS products follow exactly the same arc. The teams that study this pattern treat their own APIs the way careful OS designers treat system calls: define them narrowly, version them explicitly, and never promise what you cannot afford to maintain for the next decade.
What Emulation Tells Us About Abstraction
The museum works because modern browsers can emulate hardware from the 1980s in real time. That is not magic — it is the payoff of layered abstraction done right. The CPU instruction set is emulated in WebAssembly. The display is rendered on a canvas element. Storage is faked with IndexedDB. No single layer knows what the others are doing.
This is the same principle behind every cloud-native architecture worth shipping:
User Request
└── API Gateway (routing, auth)
└── Service Layer (business logic)
└── Data Layer (storage abstraction)
└── Infrastructure (swappable: AWS, GCP, bare metal)
When each layer only knows about the contract immediately above and below it, you can swap out the underlying hardware — or, apparently, emulate a 1984 workstation — without rewriting the software running on top. That is not an accident of good intentions. It is the result of deliberate boundary design.
The Graveyard Problem in Modern Stacks
The museum also contains a graveyard section. Operating systems that launched, gathered users, and were then abandoned — leaving anyone who built on them stranded. Developers who bet their livelihood on certain platforms in the 1990s know this feeling acutely.
The modern equivalent is not operating systems — it is cloud services, ML APIs, and third-party SaaS dependencies. A model endpoint deprecated with sixty days' notice. A messaging API that pivots its pricing. A mobile SDK that stops receiving security patches.
The mitigation strategy is the same one that portable software authors used during the platform wars: wrap external dependencies behind your own interface. If your entire codebase calls openai.chat.completions.create() directly in forty different files, you have built the same fragility that trapped OS/2 developers when IBM changed course. Abstract it. One internal client, one place to swap the provider.
Preservation as Engineering Discipline
There is a less obvious lesson here: the museum exists because someone cared enough about preservation to do serious engineering work. Collecting disk images is the easy part. Making them run reliably in a browser requires understanding boot sequences, BIOS emulation, filesystem quirks, and input handling across hardware generations spanning fifty years.
Software teams are notoriously bad at preservation. Documentation rots. Internal wikis go unread. The engineer who understood why a critical design decision was made in 2019 left the company in 2022. What remains is the code — and code without context is archaeology, not engineering.
The fix is not complicated, but it requires deliberate habit:
- Write architecture decision records (ADRs) at the time the decision is made.
- Keep a changelog that explains why, not just what changed.
- Treat your README as a living document that a competent stranger can follow.
A virtual museum built on recovered disk images is what happens when you fail to do this at civilisational scale. Your codebase is smaller, but the principle holds.
Why This Matters for Your Project
Whether you are shipping a mobile app in Accra or scaling a SaaS platform to enterprise customers, the arc from bootstrap to calcification to disruption is coming for your product too. The operating systems in that museum are not relics — they are worked examples of every architectural trap and every inspired abstraction you will encounter. Study the ones that survived by adapting. Build your own layers with the same discipline. And document the decisions that future engineers will otherwise have to reverse-engineer from the binary.
Source: Virtual OS Museum — https://virtualosmuseum.org/ (via Hacker News)
