Paul Hammant's Blog: BTRON, OLE, OpenDoc and the Web: Why Dumb Won

Note: By “dumb” I don’t mean badly designed. I mean something more specific: the architecture with the weakest internal semantics had the strongest boundaries.

Japan’s TRON project bubbled up again recently - an XDA piece by Adam Conway and an OSNews write-up by Thom Holwerda with a good comment thread. BTRON, the desktop branch, is the interesting one. It tried to replace “files owned by applications” with a document model: typed parts, handlers per part type, and persistent system-managed links between parts. A document holding writing, a table and a figure would invoke a handler for each, with each handler drawing inside the parent document’s window. Its filesystem was an arbitrary directed graph, not a tree. That was late 1980s (it only began in 1984).

Meanwhile ITRON, the embedded sibling, quietly became one of the most deployed operating systems in the world - in cameras, engine control units and phones - because it was small, deterministic and royalty-free. That’s the “dumb won” story in miniature, inside TRON itself. Maybe dumb-won is too pithy and the architecture with the weakest internal semantics had the strongest boundaries is more accurate.

Thom’s pet theory is that the application-first model won because it is better at wealth extraction. Commenter ssokolow disagreed: compound documents were a fine idea while documents mostly left the building as paper or PDF, but once the Internet arrived, making the recipient acquire every handler for every embedded part became prohibitive. Another commenter, metaning, remembered OpenDoc files sent to a service bureau, which then had to own the same OpenDoc components you did before they could RIP your job to an imagesetter.

I think ssokolow is closer, and I went back and forth with ChatGPT to put it in a table.

Four answers to “what comes after files + applications?”

Between roughly 1984 and 1997 the industry tried repeatedly to answer that question. Four answers stand out:

1. BTRON - hypermedia + compound documents at the OS level
2. OLE - compound documents retrofitted onto the conventional Windows desktop
3. OpenDoc - documents as federations of small, interchangeable parts (Apple/IBM et al)
4. The Web - hypermedia stripped down enough to become universal

The dates are approximate, and mean when each was introducing its distinctive ideas rather than when it peaked commercially.

The first eight rows are the conventional comparison, and on those the Web looks primitive. It’s the dumbest of the four. The three rows I asked to be added just before “historical outcome” are where it wins, and I think they are the rows that matter.

Then also “high - browser supplies selection/copy for every page” re copy/paste wasn’t there from the outset of the web, had a peak, and has declined quite a bit in the last decade. Canvas-rendered applications, images of text, custom controls, DRM-ish interfaces, CSS selection suppression, etc. can defeat normal selection. And I have to say I really hate that defeating of one of the true genius aspects of the web.

Graceful degradation outward

The richer systems optimized for movement of content within themselves: from a BTRON part to another BTRON part, from an OLE server to an OLE container, from one OpenDoc part editor to another. That’s interoperability between equally sophisticated peers.

To be fair, BTRON did think about degradation inside the system: applications could skip TAD data types they didn’t support. But Conway’s article has a telling detail: if no handler exists for a part, or the handler fails to draw, the system strikes a diagonal line through the region where the content should have been. That’s the compound-document failure mode drawn literally - a box you can’t see into, which is exactly what ssokolow’s recipient without the right handlers gets.

The Web’s artifacts instead degrade gracefully when they leave:

CONTENT:
interactive page
  -> HTML / structured fragment
    -> formatted text + images
      -> plain text

REFERENCE:
interactive page
  -> URL

^ The Web has both graceful representation degradation and cheap referential escape

At each step you throw away semantics and still have something useful. The destination needn’t understand the source. An email client, a Slack message, a Word doc, a text file, or a sticky note on a monitor will each take some level of that. That’s precisely ssokolow’s point about handlers: the compound-document systems required the receiver to be as capable as the sender, and on the open Internet that’s rarely the case.

A better name for the row might be “graceful degradation when copied/pasted outward”. The question is how easily can information escape the system without the destination knowing anything about it?

Navigation master control

This is the one I find most under-appreciated. OLE says the container/application controls your experience. OpenDoc says the compound document coordinates your parts. BTRON says the information environment manages your graph. The browser says:

<- Back   -> Forward   Reload   Stop   [ Location ]

… and the page doesn’t get a vote (fundamentally the page doesn’t own those controls). A terrible page and a brilliant page get the same navigation machinery, owned by the user, sitting outside the document. Back is a generic undo-like operation over navigation that requires no cooperation from the content author. The location bar gives Web resources - and well-designed application states - a name the user can copy independently of their contents.

Single-page apps eventually had to learn to cooperate with that model via the History API: if application state changes aren’t reflected in browser history, Back stops meaning what users expect.

Green-screen techs as represented via IBM’s “common user interface” definitions from the late 1980s, had an F12 for back-one-screen (not page) and F3 for back-out-completely (exit) didn’t make the jump to the web, even if F5 for refresh did. Well, less and less today.

What about Lotus Notes?

Notes was a love-it-or-hate-it thing, and it’s a fifth answer from the same window. Ray Ozzie’s Iris Associates started in late 1984 and Notes shipped in late 1989. The fundamental unit was the document - rich text with embedded objects and attachments - and an “application” was really just a database design (forms, views, some scripting) wrapped around documents.

Its links had one important BTRON-like property: they were based on persistent identities rather than merely filesystem paths. Doclinks keyed on a replica ID plus the document’s unique ID (UNID), so they could survive replication and server moves where the Web’s rot. And it had a strength none of the four above had: replication. Offline-first documents that synced between servers and laptops, years before anyone said “local-first”.

But on the three rows that matter, it looked like OLE and OpenDoc. Rich Notes content degraded unevenly outside the Notes ecosystem; preserving Notes-specific behavior required Notes-aware software, and navigation belonged to the Notes client - until Release 5 added browser-like Back/Forward and bookmarks, which was Notes imitating the browser. The “Domino” version (1996 or so) then served Notes databases over HTTP as HTML. Domino eventually gave Notes databases a Web escape route: HTTP/HTML could expose their contents without requiring the Notes client.

Ozzie kept pushing the replication idea after Notes - Groove (2000-2005) for peer-to-peer shared workspaces, then Live Mesh (2008) at Microsoft. It was the browser-based, URL-addressed takes on the same idea - Google Docs, then Microsoft’s own cloud Office - that won.

Notes’ data model did survive, though: Damien Katz described CouchDB (JSON docs, map/reduce views, replication) as “Lotus Notes built from the ground up for the web,” and PouchDB (~2012-13 (?)) put the offline-first replicating client in the browser. The easy built-in UI didn’t survive - as I noted in Lotus Notes vs CouchDB back in 2013 - the Web’s own UI stack took that job.

The linked-parts half of the idea is back too. Conway notes that Roam, Logseq and Obsidian have spent the last decade rediscovering BTRON’s model of linked, transcludable blocks - mostly as local-first files on disk.

Denny called this in 1990 - in reverse

Back in 2013 I wrote about Interface Builder’s alternative Lisp timeline, and Dennison “Denny” Bollay told me about “Dynamic Documents”, built for the CIA after Xerox PARC’s NoteCards. It had unidirectional, bidirectional, contextual and searchable links, stored out-of-band in an object database, and linking arbitrary portions of documents from word processors, drawing programs and databases. When the CIA handed them an HTML spec, they and PARC concluded it was “dumb from almost every angle”: every document had to be rewritten in HTML, links couldn’t be contextual, links were one-way with no dead-link checking, it was completely static, and “even HTTP was stupid”.

“Obviously we misjudged…”, he added.

Most of those criticisms accurately identify capabilities the early Web omitted compared with richer hypertext systems, and in the same post I noted that Action! itself had no forward/back button and no URL concept. Denny’s list is really a list of the Web’s trade-offs, and the three rows above are what those trade-offs bought. Converging on a small set of simple, openly specified representations made graceful degradation much easier. Links being the same for all users is what makes a URL something you can paste into an email. Static documents with a browser in charge are what let the user, not the author, own back.

So, wealth extraction?

I don’t think Thom is wrong that application-first suits vendors - look at how many SaaS products break copy/paste, deep-linking or Back on purpose today. But BTRON, OLE and OpenDoc didn’t lose to greed. They lost to something simpler that was easier to leave. If someone wants to try document-centric computing again, ssokolow’s advice holds: solve the dependency problem first. And I’d add: keep the Back button outside the document, and make sure every part can collapse to plain text and a URL.

Files + applications again

They don’t go away just yet. I enjoy using my Chromebook and Google is an almost entirely online company, but they still have dirs and files and apps that would operate on them for ChromeOS. I’m 70% in that world day to day. Google are rolling out AluminiumOS presently so I get to find out how much my preferred OS changes in the transition, I guess.

Where do phones fit?

That’s where the burning hot race is, so iOS and Android deserve a look against the three rows that matter. I’ve kept them out of the big table as their peak years (roughly 2007-2014) would break the 1984-1997 story:

A few things stand out:

1. BTRON’s bet paid off - upside down.

Phones hid the filesystem (iOS until the Files app in 2017) and imposed a whole new platform worldview, on a non-x86 CPU no less. Nobody had to be talked out of the desktop, because the phone was a new device category. But what won inside that new worldview was the app silo - the opposite of documents composed of parts. This is where Thom’s wealth extraction theory has its strongest evidence: a 30% store cut gives the platform an economic incentive to keep content inside apps.

1. Android Intents are the closest mainstream thing to BTRON’s handlers.

Well, maybe closest: “I have an image/jpeg, who can EDIT it?” and the OS offers a chooser. The handler model survived, just at whole-app granularity rather than parts-within-a-document.

1. Android popularized the verb × typed-data model.

ACTION_VIEW, ACTION_EDIT and ACTION_SEND against a MIME type, with an “Open with … Always / Just once” chooser, made handler selection everyday UI for the first time. Most flows are VIEW or SEND though - EDIT rarely surfaces.

The idea was old. Prior art:

• Unix mailcap (metamail, Bellcore, ~1991 (?); RFC 1524, 1993 (?)) - a view command per MIME type, plus optional edit=, compose= and print= fields. Possibly the first view/edit split per MIME type (?). Mutt and pine users configured it; edit= was rarely filled in.
• OLE 1.0 (1990-91 (?)) - per-class verbs for embedded objects. A sound object’s primary verb was “Play” and “Edit” was secondary. The one place desktop users visibly met the idea.
• Windows registry (3.1’s REG.DAT 1992 (?), routine by Windows 95) - shell\<verb>\command per file type, keyed on extension rather than MIME. Right-click “Edit” on a .bat or .reg opened Notepad instead of running or importing it; on XP, “Edit” on an image opened Paint.
• Mac OS X Launch Services - apps declare themselves Viewer or Editor per document type. Architecturally explicit, but largely invisible in ordinary UI.

In ordinary desktop use, users overwhelmingly interacted with one cell of the matrix: Open. And that cell became a battleground - media players and browsers hijacking associations on install, “make X your default?” nags, and eventually Windows 10 hash-protecting defaults so apps couldn’t grab them silently. Nobody fought over the Edit slot. Vendors fought fiercely over the one slot that decides whose app you live in. Whatever the motivation, that’s at least compatible with Thom’s wealth-extraction argument: the economically valuable position wasn’t “editor for this type”; it was “default place where this type opens.”

The Web nevertheless supplies the most universal escape hatch: when an app has a public Web representation, sharing a URL exports a reference that virtually any destination can preserve, even if it understands none of the app’s internal data model. Deep links and universal links are apps adopting URLs after the fact. The graceful-degradation row still holds on phones - it’s just the Web providing it, not the platform.

And in closing, the hot race today is a fight over navigation master control. Apple’s App Intents (since iOS 16) and Google’s equivalents on Android let apps expose typed actions that an OS-level assistant or agent can invoke across apps. That’s a layer above the apps that the user - or their agent - drives: browser chrome again. Architecturally, it rhymes with BTRON/OpenDoc composition: applications expose typed capabilities that a higher-level orchestrator can combine, with apps as verb-handlers stitched together by an orchestrator. The open question is the same one as 1993: who owns Back, and who owns the layer above the content? Platform vendors are increasingly putting an OS-level assistant/orchestration layer above apps. The Web put that layer in the user agent.