The Xanadu story is indeed a classic full of interesting lessons. Specifically "ship early" is now a platitude in web software development.
But I also have some sympathy for the developers who still dream of finishing Xanadu: From a purely academic perspective, it would be interesting what such a system would look like and whether it could work in any way. It appears to have anticipated some form of DRM (digital rights management) which is now routinely used for things like Netflix.
Xanadu reminds me of “Google Wave“ from 2009: A quite ambitious (though much less ambitious than Xanadu) project which tried to replace email with something much more dynamic and flexible. Wave didn't succeed, but I think not because Wave was too rigid and overengineered compared to email (it arguably wasn't), but because email was already firmly established. Any alternative didn't have the network effect on their side.
This leads me to think: Are there are any exceptions to the Xanadu lessons?
One case is perhaps the computer game "Star Citizen". It's an completely overambitious crowdfunding project which is in development for more than a decade. Apparently it is still nowhere near finished, and many think it will never be. But unlike Xanadu, Star Citizen did definitely "evolve" pretty much from the start with its users, who got access to the unfinished game very early on. But dynamically evolving development with the userbase seems not sufficient for a project not to get hung up in unrealistic platonic ideals.
Another case is, perhaps, the invention of the computer. I don't mean the actual invention(s) during the second world war, but Charles Babbage's Analytical Engine a hundred years earlier. He mostly just produced elaborate plans, since he didn't have the financial means of implementing them. So his visionary ambitions didn't get anywhere. He was mostly forgotten, and computers were set back for a century. But it seems plausible today that his project could well have succeeded at the time if he had access to a substantial engineering and research team. Some projects can apparently only succeed with a ton of antecedent effort, because they simply have (unlike Xanadu with the WWW) no small analogue.
But I generally agree: for most projects the Xanadu lessons seem applicable.
But it seems plausible today that his project could well have succeeded at the time…
I don't think so. Several computing machines were prototyped in the early 20th century, and none of them really took off until they were made fully electronic (ENIAC). Any system with moving parts is just too slow to be of practical interest.
Back then there was already significant demand for "human computers": https://en.wikipedia.org/wiki/Computer_(occupation)#Origins_in_sciences I think it is plausible than one of Babbage's steam powered machines could have been faster than quite a few people.
Well, as far as I can tell, even the electromechanical computers of the 1930s were not significantly faster than humans using mechanical calculators. That's why I don't think it would have worked in Babbage's day. More details in the middle of this essay https://rootsofprogress.org/epistemic-standards-for-why-it-took-so-long
My impression was that wave failed because it was slow and miserable to use. Maybe it would have failed later on for your reason as well, but this was the reason it failed for me.
The great and mighty Google didn't actually have the ability to make a fairly complex UI for the web that could scale to 100 items. As of today, the craft of UI programming has been lost to all but a few Qt programmers. Google are now gradually rebuilding the art, with Flutter, and I think they may succeed, and this will have a shocking quantity of downstream consequences.
The only thing I remember about Wave was that it was a collaboration tool, but it was in private beta, and when I got in, I couldn't invite others to the private beta to collaborate with them. So I poked around a bit and then never came back to it. I suspect many others had the same issue.
Sometimes projects are killed not for deep reasons but just from simple, basic execution failures.
What does Flutter do that various JS/CS frameworks don't? Does it give design advantages on web, or is the benefit that it brings web design to non-web applications?
It makes non-web applications possible. It has a better layout system, rendering system. Animates everything properly. Centers Dart, which seems to be a pretty good language: It can be compiled ahead of time for faster boots (although I'm not completely sure that typescript wont be basically just as compilable once wasm-gc is up), has better type reflection, will have better codegen (already supports annotations), has a reasonable import system, better data structures, and potentially higher performance due to the type system not being an afterthought (although typescript is still very good relative to dart).
Fun trivia: Arbital was internally called project zanadu pre-naming, as an attempt to keep awareness of these failure modes in mind.
Arbital was functional and fine. It only failed at the adoption stage for reasons that're still mysterious to me. I'm reluctant to even say that it did fail, I still refer people to a couple of the articles there pretty often.
It doesn't seem that way to me. As best I can tell Arbital failed at its own goals because we're not using it as a repository for knowledge about AI alignment, so by its own objectives it was not working fine.
I dread when I have to look something up in Arbital. It's slow, which is fixable, but also somewhat confusing to navigate. I actually agree with Tofly's sentiment that I think from the outside it seems like Arbital tried to bite off more than it could chew rather than trying to address problems incrementally.
I recall another over-ambitious project from way back, when USENET was the place to discuss everything and spam had not been invented. This was a time when email typically took anything from minutes to days to reach someone, depending on how well-connected both sender and recipient were, and USENET posts likewise. And there was nothing faster.
Unfortunately, I've never found any archive of USENET that goes back far enough to find this again, so the following is from memories that must be over 30 years old. I would be interested to know if anyone else remembers.
Someone had the idea of what we nowadays call an MMORPG: a massively multi-player online game of galactic exploration and conquest. Of course, this would not happen in real time. Nothing did in those days except your interaction with the machine directly in front of you, and not always then. No, this would be roughly turn-based. You would submit your moves, and a few days later you would see the outcome. Imagine Eve Online played by postal mail.
The global state of the whole game would be maintained using the same protocols that USENET itself used to distribute articles. (USENET had no centralised store, like a bulletin board would: every message was copied to every participating machine, each machine communicating with a few neighbours on the net to share new messages.) To save on memory, all of the assets would be pseudo-randomly generated, so the whole geography of a planet could be represented by its random seed, as would the distribution of stars across the galaxy. A huge discussion sprang up across several USENET newsgroups, and ran for months, with people posting idea after idea of what to put in the game and how things would work. It was awesome.
To the best of my knowledge, no code for this game was ever written.
I took from this a warning against continually raising one's sights and never firing through them, dreaming ever greater dreams but never rising from the opium couch, all exploration and no exploitation.
It is possible that some of the people involved might have been inspired by it to make their own games that did see the light of day, although I've never heard anyone say so.
Sounds a little like StarWeb? Recently read a lovely article about a similar but different game, Monster Island, which was a thing from 1989 to 2017.
But yes, my default assumption would be that the particular conversation you're referring to never resulted in a game that saw the light of day; I've seen many detailed game design discussions among people I've known meet the same fate.
In How Not to Network a Nation, Benjamin Peters points out that Soviet computer networking projects failed partially due to this same centralizing idealism. Soviet networking projects all saw the ideal network as a central nervous system, connecting productive outposts with the central "brain" in Moscow. By contrast, the developers of ARPANET envisioned their network as a brain with the individual computers as the neurons. The formulation of ARPANET was as a distribution of homogeneous elements, whereas the formulation of the OGAS (the largest Soviet project) was hierarchical and heterogeneous from the start. It's interesting to see the similarities between all of these unsuccessful networking projects.
I'm in this picture and I don't like it.
I've been trying for years to design (entirely inside my head and tons of disconnected notes, with no cohesion or organization or any clear idea of how to build prototypes) a... thingy, that is very kitchen sink ish (it's a social media network! it makes people rational by prompting them to think about things in ways! it's a prediction market! it's an effing MMO!!), never settles down into a specific defined form... etc.
This is a perennial failure mode of my cognition - I've done it with other things too - when I was a young teen and into New Age stuff I tried to build a grand unified theory of everything as modes of vibration in cosmic consciousness! And then there's my tendency to try to fit every story idea I have into the same fictional universe...
Oh, but that last one could be fun...
The obvious thing to do, of course, is to figure out why you are trying to design one thing that is all those things, and see if a simpler thing to do becomes obvious at that point. The reason could simply be that you like to plan complicated things, in which case settle on a problem that is genuinely complicated and doesn't need any complications added, or it could be because your interests change rapidly, in which case you focus on a simple but expansive framework so that you can hit the ground running on whatever your new interest is, and achieve something (even just a beautiful thought) in that area before your interests change again. More interesting is if there is some commonality between all the things you switch between, and you can just focus on that part, because that is where your true interest lies.
Obvious, boring but surprisingly difficult to follow advice. Practice taking notes, organizing things, building working projects (which could be as simple as fixing a door that doesn't close quite right, or a floorboard that squeaks, or as complicated as learning a new programming language to write a short program that does one thing.), and so on. Planning things successfully is a big deal for people that currently don't. (I should take my own advice...)
I can't agree with your proposals for what to learn from this failure, which honestly read like cached thoughts to me. The actual issues outlined are hubris, which is perhaps the oldest known human bias, and an immense focus on centralized coordination with all the immense failures that has caused throughout human history not being solvable by fiat.
The lessons aren't 'evolve' and 'ship'. They are 'pick an achievable goal' and 'let the people coordinate amongst themselves'. The former are simply methods aimed at achieving 'pick an achievable goal'. Sometimes they are the right methods, and other times, they are not. The achievable goal of the web: 'follow links'. The web is also obviously not centralized (no matter what the people complaining about social media tell you.). Local centers of coordination will pop up organically, without having to solve the hard problem of planning them in totality.
We tend to 'learn' what we want to learn, and that mix of hubris and lack of new thought makes it hard to learn when we fail due to our hubris.
One of my all-time favorite articles is “The Curse of Xanadu,” by Gary Wolf, which ran in WIRED Magazine in 1995. On the surface, it’s a piece of tech history, a story of a dramatic failure. But look closer, and you can find deep philosophical insight.
Xanadu was a grand vision of a hypertext system, conceived long before the Web, that at the time of this article had been “under development” for three decades without launching. The visionary behind it was Ted Nelson, one of the originators of the concept of hypertext. Here’s how the article describes him and the project:
The project had many of the earmarks of other failed or long-overdue efforts. As a product, it was over-designed:
In contrast to the later Web, links in Xanadu did not point to entire documents, but to any arbitrary range of characters within any document. Links were to be bi-directional, so they could not be broken. And there was an advanced feature in which “parts of documents could be quoted in other documents without copying”:
The vision for the application of this technology was nothing short of utopian, based on delusions of technological solutions to social and epistemic problems:
The design also blithely ignored the realities of computer performance, developing as they were on minicomputers and early workstations:
The project suffered from infighting and a lack of good management:
There was never a realistic schedule: the team perpetually believed they were six months away from completion. The project was so badly conceived and managed that it couldn’t ship even after being acquired by Autodesk and given a full budget:
There are too many good quotes in the article to include them all here—read the whole thing.
What struck me most deeply, however, was the response of some of the Xanadu team to the rise of the World Wide Web. You would think that the web would be an object lesson for them—a slap in the face hard enough to wake them from their pie-in-the-sky reverie and bring them back to Earth.
Indeed, one junior programmer on the later team, Rob Jellinghaus—who was born after the Xanadu project had begun (!)—did have such an awakening:
But here was the reaction of Mark Miller, one of the original developers:
And what about Nelson himself?
Miller, Nelson, and the rest of the Xanadu team might have benefitted from reading another one of my all-time favorite articles: Clay Shirky’s “In Praise of Evolvable Systems”.
Shirky begins by pointing out several ways in which the fundamental standards of web technology have seemingly absurd limitations and inefficiencies: HTTP doesn’t use persistent connections and incurs the entire overhead of a new session for each file transferred, web servers have no built-in load balancing, HTML uses one-directional hypertext links that are easily broken, etc.:
Contrasting the “evolvable system” of the web with centrally designed protocols such as Gopher and WAIS, he concludes:
The Xanadu project still exists. I was able to quickly learn its current status, because it has a homepage on a global hypertext-based information system: https://xanadu.com.
“With ideas which are still radical, WE FIGHT ON. We hope for vindication, the last laugh, and recognition as an additional standard…” It complains that “everyone is hypnotized by the Web browser,” which is “basically crippled.”
The project is no longer entirely vaporware. There are two demo viewers of Xanadocs: “XanaduSpace is our best-looking viewer, our flagship demo—but alas, it’s a stuck demo and can’t go further.” The “new working viewer”, xanaviewer3, makes it “possible (but not easy) for anyone who is determined enough to create a xanadoc, and send it to others, who may open and use it.” One supposes that, in order to view it, the recipients of the document must be equally determined.
“With our limited resources,” they explain, “we can only go slowly, unlike today’s Red Bull–fueled young teams.”
The WIRED article describing Xanadu as running for over 30 years is now 27 years old, meaning Xanadu itself is nearing 60. If its “record of futility” was difficult to surpass back then, it is doubly so now.
The lessons of Xanadu can be learned at multiple levels.
On one level, the lesson is to scope projects realistically and to strive for simplicity of design.
On a deeper level, the lesson is to ship continually. Doing so keeps the schedule honest, forces difficult scope decisions, and allows for feedback from real users.
On a still deeper level, the lesson is to learn from failure, which the vast majority of the Xanadu team does not appear to have done: thirty years of missed deadlines did not cause them to fundamentally question their schedule, project management, or design scope.
But the deepest lesson, I think, is to value real-world results. Nelson and Miller didn’t fail to notice the Web, they failed to care about its success or even to recognize it as a success. Its epic, world-changing status in the history of technology is meaningless to them beside the fantasy system they had dreamed up.
In the end, despite the title of the WIRED article, Xanadu was not, in fact, cursed. It achieved exactly what its originators wanted: theoretical perfection in a Platonic realm of forms so idealized that it can never quite be brought to Earth.