As of a month ago, the Apache Wave project is “retired”. Few people noticed; in the seven years that Wave was an Apache Incubator open source project, it never had an official release, and was stuck at version 0.4-rc10 for the last three years.

Before being handed off to Apache in 2011, Wave was a Google product, first announced in 2009. Google made Wave fully accessible to the public in May of 2010, but announced they would no longer be developing it just three months later.

2017 was a year of rapidly growing interest in federated communications tools such as Mastodon, which is an alternative to Twitter that doesn’t rely on a single central corporation. So this seems like a good time to revisit an early federated attempt to reinvent how we use the internet to communicate with each other.

Responding to the announcement that Wave is now officially retired, my friend Getty Ritter wrote in a private Slack (quoted by permission):

I was one of about four people who thought that Wave would have been a good project if only they didn’t oversell it and also if it had been, like, not Google.

We used Wave for project planning in creating a video game back in the day, and it was perfect for that, but not for any of the reasons they advertised or were proud of. We didn’t care about the cool live editing algorithms, but having this sort of nice rich media environment that permitted a hybrid messages and collaborative editing environment was great. We’d start sending messages with lots of diagrams, sketches, and stuff cribbed from Google Images, and then be able to turn those sort of longer-than-IM-shorter-than-email messages into actual design documents gradually.

In fact, I’d argue that even having a system that’s a messaging system designed for “a paragraph or two” was on its own worthwhile: even Slack isn’t quite geared toward that, and contrariwise, email […] felt more heavyweight than that. Wave felt like it encouraged the right amount of information per message.

Getty’s description gets at some of the issues I have with existing tools when trying to collaborate on a project with other people.

  • I desperately want tool support for taking unstructured thoughts and ideas, and incrementally and collaboratively transforming them into coherent documents. I believe every task in a group project follows this pattern.

    For example, in a software project, any bug report starts with scraps of information, posted in IRC or on Twitter or buried in the middle of a seemingly-unrelated mailing list message. I see the process of resolving the bug as mostly about collecting all those pieces of evidence into a coherent story.

  • Human communications is literally not one-size-fits-all. When someone wants to explore a problem or a new idea, they need an easy way to just start chatting with potential collaborators about it; at that stage, short messages like in Slack or Twitter or IRC are perfect. But if the idea goes anywhere, those short messages need to coalesce into larger units of thought: first “a paragraph or two”, and eventually whole blog posts or design documents or other artifacts whose purpose is to convey the most important parts of the idea to people who weren’t involved in the original conversation.

    No one technology today spans this range. Instead we switch between instant messaging and email and Google Docs and wikis and git, none of which really play nicely with each other, and we lose history at every step. Wave was explicitly an attempt to unify all those tools.

To me, it’s pretty clear why someone might want a tool like Wave just based on the above points. But wait, there’s more!

From a technology perspective, Wave was built around two key ideas that it’s hard to imagine Google, as we know it in 2018, would pursue.

  • Wave acknowledged that communications via the internet can be delayed enough that humans will notice.

    These days every Google product seems to assume that your internet connection is always on, that you’re close enough to the nearest Google server that your brain won’t notice the speed-of-light delay, and that you have practically unlimited bandwidth. These assumptions are barely true in Mountain View, let alone in most of the rest of the world.

    The first key technology underpinning Wave was “Operational Transformation” (OT), and it allowed people to edit documents together in real time even though their connections to each other might be slow and unreliable.

  • More surprisingly, Wave was explicitly designed to keep Google from being the sole central authority.

    They released sample implementations under open source licenses, encouraged others to run their own Wave servers independent of Google infrastructure, and defined a federation protocol (on top of Jabber/XMPP) so that people on different servers could still talk with each other.

    This seems weird, a decade later, when Google and Facebook are each trying to get everyone into their walled gardens so they can serve ads to you.

I often find myself disheartened when I see situations like this: that the Wave project tried to tackle these problems almost a decade ago, and failed. But rather than giving up, let’s try to learn some lessons from that failure. Why aren’t we all using Wave today?

The day after Google announced they were ending development on Wave, staffers at Ars Technica wrote “Google Wave: why we didn’t use it”, a post-mortem which reads much like the analysis of many other failed technologies. To summarize:

  • The initial implementation was a JavaScript-heavy web application in an era when people weren’t used to that. Browsers weren’t optimized to run so much code and so the user experience was terrible: one Ars staffer reported that he gave up when Safari ground to a halt trying to load the Wave site.

  • Google’s interface design aesthetic for Wave was the old-school “Multiple Document Interface” (MDI), rarely seen these days (for good reason). An Ars staffer wrote that this “made it ugly and initially confusing for even the savviest of users.”

  • Both of those would have been recoverable problems, especially because Google’s web interface was intended to be just one of many. If a variety of Wave-compatible apps had materialized, people could have just chosen the ones that worked better. Unfortunately, the Wave protocol was complex, so the few implementations that eventually appeared came from big companies like Novell and SAP, who only cared about the enterprise market.

  • Assuming you could stand Wave’s interface, it’d still be useless unless the people you wanted to communicate and collaborate with were also using it. Wave was intended to completely replace existing systems like email and chat, so it had no provisions for interoperating with those systems. To succeed, Wave required a revolution, a critical mass of people switching to the new way and dragging the rest of the world with them—and those haven’t worked out very often.

  • Making the revolution even more unlikely, initially Google offered Wave accounts by invitation only, so the people you wanted to talk with probably couldn’t even get an account.

In the end, Wave failed because it was designed assuming everyone would agree to switch to it, but at its launch it had too many issues keeping it from getting enough momentum to reach that critical mass.

Okay, I think that’s actually quite a hopeful conclusion! Because here’s the good news:

Wave’s failure didn’t have anything to do with the ideas that went into it.

Those ideas and goals are sound, and this failure even provided good evidence that there’s a real need for something kind of like Wave: fifty thousand people signed a petition to “Save Google Wave” after Google announced they were shutting Wave down. Like so many petitions, it didn’t help (obviously), but if a mediocre implementation got tens of thousands of passionate fans, what could a good implementation do?

I’d say the single most important lesson to take away here, for a technology project at least, is that interoperability is key.

  • Assume that no matter how amazing your new tech is, people are going to adopt it slowly.
  • Give your early adopters every chance you can to use your offering together with the existing tools that they will continue to need in order to work with people who haven’t caught up yet.
  • And if you’re building a communication tool, make it as simple as possible for others to build compatible tools, because they will expand the network of people your users can communicate with to populations you haven’t thought of and probably don’t understand.

As a final thought, I’d like to briefly describe three projects I’ve worked on that I think embodied this principle well.

My most widely used open source project, XCB, was initially intended to be revolutionary. XCB completely replaces Xlib, a C library dating back to 1987, which had accumulated so much cruft that at one point it had an entire color management system which was literally unusable because if you ever called its initialization function, it would immediately crash—and nobody noticed that bug for six months. XCB is in no way compatible with Xlib: initially we thought that people would be excited to rewrite their code rather than deal with Xlib any longer. That has actually been kind of vaguely true, which mostly goes to show how much of a mismatch Xlib is for modern use cases. But XCB really only took off after we rewrote a core part of Xlib to use XCB internally, and allowed developers to mix and match calls to both libraries in the same application. Now the XCB-based Xlib is used in basically every X Window System installation, on every OS—Linux, BSD, Solaris, Windows, etc—which means that odds are good that you’ve used software that I’ve written.

Comic Rocket is a site my friends and I built for helping people discover, read, and follow their favorite webcomics. One of my early design decisions was that Comic Rocket would not host any comics itself; instead it acts more like a feed aggregator or a search engine for webcomics. I knew that no matter how good of a job I might do at building tools for creators to publish their comics, I’d never convince everyone to switch to my platform. Through careful architecture decisions and a very clever web-crawler (if I do say so myself), Comic Rocket is able to provide bookmarking and update notifications for comics no matter where they’re hosted on the web. Because its features enhance readers’ experience without any effort from the creators, it has become popular enough among webcomic readers to in turn be a significant source of traffic for creators, and everyone wins.

Mozilla’s Rust is sometimes put on a pedestal as a revolutionary programming language, with a few over-zealous proponents pestering all sorts of projects with arguments that they should rewrite all their software in Rust. (It’s unfair to call Rust revolutionary, though, simply because they’ve put so much work into compatibility and FFI.) To be honest, I’m fully in favor of that idea: I would love to see all the world’s C and C++ software rewritten in Rust, using Rust’s compiler-enforced safety features to discover and fix many lurking bugs and crashes. Of course, as I’ve written about before, there are plenty of reasons why people shouldn’t rewrite everything in Rust. One major reason is that a by-hand rewrite is error-prone and likely to introduce new bugs. That’s why I started writing Corrode, a fully automatic C to Rust translator. Building automatic tools to migrate from the old way to your awesome new way significantly reduces the barriers for getting people to switch. If Corrode (or any of the other similar tools people have written) were complete, then developers and managers could no longer object to using Rust solely on the grounds that all their existing code is in C. They’d be left with other good reasons, like that none of their team knows Rust, or that their static analysis tools only work on C, but each of those objections can be addressed given time. Creating a solid transition plan makes adoption significantly more likely.

To sum up: Google Wave tackled real problems, but failed because it relied on a revolution that never happened, which is the outcome you should expect for any technology project that expects everyone to switch to it right away. Would somebody please try again but with less hubris this time?

Follow-ups

Edit: In response to the above, Samer Hassan told me via Twitter:

FYI, we forked Wave, dropping its terrible interface & rebuilding it into a backend-as-a-service to build collaborative apps relying on its decentralized protocol: https://en.wikipedia.org/wiki/SwellRT & now @pablojan working on http://jetpad.net on top of it

I haven’t looked very carefully at SwellRT but I took a quick glance through its documentation and it sure looks… er, swell! If you’re interested in building real-time collaborative applications, check out SwellRT.

Also, there was remarkably good discussion of this post over at Hacker News. A few brief responses:

  • Arathorn commented, “A lot of Matrix.org is inspired by what Wave could have been”, which seems plausible; keep at it, folks!

  • peoplewindow commented, “There seems to be some historical revisionism here. … no, when Wave came out people were very much used to crappy web apps.” I was trying to summarize what people at the time said were Wave’s problems, so it certainly wasn’t intentional historical revisionism, but I may well have mis-characterized them. I did link to the original piece if you’d like to read what some of Wave’s users actually said at the time.

  • The author of Why We Fail: Learning from Experience Design Failures says he included a case study of Wave’s failure. I haven’t read the book but if you’re looking for more perspectives on this story you could check it out.

  • sam_goody commented, “Careful what you wish for, you may get it… Mail AMP is a Google controlled superset of email.” Funny you should mention that! I was already considering how to approach a follow-up about the AMP project’s recently-proposed amp4email, why I think it’s a bad idea (like many other people who have already written insightful things about it), and what I would propose instead. I just haven’t quite got a grip on how to frame that post yet.

Thanks for the good feedback, folks!