Dead End: Google Wave

Zusammenfassung

On May 28, 2009, Lars Rasmussen walked onto the stage at Google I/O and delivered an 80-minute demo that the audience watched with the particular attention reserved for something genuinely new. Google Wave was a communications platform that combined email, instant messaging, collaborative document editing, and social networking into a single object — the “wave” — that could be searched, replayed, extended with bots, embedded in websites, and federated across servers via an open protocol. The technical execution was remarkable: real-time collaborative editing powered by operational transformation allowed multiple people to compose simultaneously, character by character, visible to all participants without conflict. The audience gave it a standing ovation. Fifteen months later, Google announced it was discontinuing Wave, citing insufficient user adoption. The product never found a mass audience because, for most users, it was impossible to explain what it was for — and a communications tool that requires explanation is a tool that requires everyone you communicate with to learn something new before you can use it. Google Wave died not from technical failure but from the impossibility of replacing email one user at a time.

The Rasmussen Brothers and the Map Problem

Lars Rasmussen and Jens Rasmussen arrived at Google in October 2004 when the company acquired Where 2 Technologies, the Sydney-based startup they had co-founded. Where 2 Technologies had been building what became Google Maps: a web-based mapping interface that loaded map tiles dynamically using early AJAX techniques rather than requiring full page reloads. The acquisition was rapid — Google moved within weeks of seeing a demo — and the brothers moved to Sydney to join Google’s new Australian engineering office, which became one of the company’s largest engineering centers outside the United States.

By 2006, Google Maps had become one of the highest-traffic properties on the web, and the Sydney team was looking for the next problem to solve at the same scale. The Rasmussens’ interest converged on communication — specifically, on the question that Lars later articulated publicly as their starting point: “What would email look like if we invented it today?”

The question was provocative because it surfaced how much of email’s design was path-dependent legacy. Email had been designed in 1971 by Ray Tomlinson for a time-shared computing environment where messages traveled asynchronously between users on different machines. The message format — RFC 2822 header fields, MIME attachments, the immutable message object — was built for store-and-forward delivery, not real-time exchange. Email was asynchronous by assumption. It could not show you that a reply was being composed. It could not let two people edit a shared document in the same message thread. It kept conversation history in each recipient’s mailbox separately, making the thread diverge the moment anyone received it.

The Rasmussens concluded that if you started over, knowing what computation and networking could do in 2006, you would not build email. You would build something more like what they proceeded to build.

The Architecture of Wave

A wave was the central object: a persistent conversation thread stored on a server, editable by all participants, fully versioned, and replayed from any point in its history. Unlike an email thread, a wave was shared state — there was one canonical copy of the conversation, not a copy in each participant’s mailbox. Unlike a chat session, a wave was persistent and searchable. Unlike a collaborative document, a wave was also a conversation, with the social context of who wrote what and when.

Each message within a wave was a blip — a unit of content that could be a text paragraph, an embedded image, an inline reply, or an output from a bot. Blips could be arranged hierarchically, so inline replies nested inside the blip they responded to rather than appearing at the thread’s bottom. The resulting structure could represent complex multi-threaded discussion without losing track of which reply responded to which point.

The defining technical feature was real-time collaborative editing. When two people were looking at the same wave, their edits were visible to each other immediately — not after submitting, but character by character, as they typed. This was implemented using Operational Transformation (OT), an algorithm originally developed in academic research in the late 1980s for the Grove collaborative editing system. OT worked by transforming concurrent edits so they could be applied in any order while producing the same result: if Alice deleted a character at position 5 while Bob inserted a character at position 3, OT would adjust Alice’s operation to account for Bob’s insertion before applying it. The result was coherent simultaneous editing without locking.

OT at the scale Wave required — potentially hundreds of participants in a single wave, running over real internet connections with variable latency — was a significant engineering achievement. The Wave team’s implementation was later open-sourced and influenced the development of Google Docs real-time collaboration (which adopted OT when it was redesigned in 2010), Etherpad (the open-source collaborative editor), and several subsequent real-time collaboration systems.

Extensions — called gadgets and robots — allowed third-party developers to add functionality to waves. A robot could participate as a wave participant, responding to content in the wave programmatically. A gadget could embed interactive content — a poll, a map, a game — directly in a blip. The Polly polling robot and the Rosy translation robot were early examples. The extension model was ambitious: developers could build, in effect, collaborative applications inside a wave without building their own real-time sync infrastructure.

The Federation Protocol extended Wave to a server-to-server network. Like email’s SMTP, the Wave Federation Protocol would allow waves to be hosted on any compatible server and to include participants across servers. An academic institution running its own Wave server could have participants in a wave alongside Google Wave users. The protocol was based on XMPP (the Extensible Messaging and Presence Protocol) extended with Wave-specific semantics. The vision was a decentralized Wave network where no single provider controlled the infrastructure — a structural commitment that differentiated Wave from the proprietary messaging platforms that would subsequently dominate.

The Google I/O Demo

The announcement demo at Google I/O 2009 is memorable in the history of product introductions, not because of what it accomplished commercially, but because of the gap it revealed between technical demonstration and user adoption.

Lars Rasmussen presented for eighty minutes to a developer audience that was following every feature with visible excitement. He demonstrated real-time co-editing; he showed a bot that translated Spanish contributions into English as they were typed; he showed waves embedded in external websites; he showed playback replaying a wave’s history. The demo had the quality of all great technology demos: it showed something that had not been seen before, and it was clearly real. The audience gave a standing ovation. Developer applications for the preview flooded in: Google issued approximately 100,000 preview invitations in September 2009 to developers and early adopters, and the invitations became coveted enough that they were being sold on eBay for $20 to $80.

The standing ovation was the warning sign that nobody read. Developer audiences at Google I/O are not representative users. They are people who understand what operational transformation is, who immediately grasp the architectural elegance of shared state over MIME messages, and who find eight simultaneous real-time editors on a single blip interesting rather than alarming. The question “what is this for?” never arises in a room full of people who can already see the technical answer.

That question would dominate the next fourteen months.

The Adoption Problem

Wave was available to the general public beginning May 2010. Google had resolved the invitation scarcity, produced documentation, and released mobile applications. The infrastructure was running at Google scale — millions of users could have used it. Most of the people who tried it did not continue.

The diagnosis was consistent across user reports, journalist reviews, and subsequent analysis: Wave was incomprehensible to most users as a communication tool.

The difficulty was not the interface’s usability — Wave was not poorly designed. The difficulty was prior to usability: it was the absence of an answer to “why would I use this instead of what I already have?” For any specific use case a user brought to Wave, existing tools worked comparably. For email correspondence with colleagues, email worked fine. For team chat, instant messaging worked fine. For collaborative document editing, Google Docs was simpler and already adopted. For social conversation, Facebook and Twitter were already where people were. Wave was better than each of these in theory — it unified them, added real-time sync and persistence, extended them with bots — but “better in theory” is not sufficient to move users away from tools that are good enough in practice.

The critical mass problem compounded the comprehension problem. A communications tool is only valuable when the people you want to communicate with are also using it. Wave required each user to recruit their entire network before it became useful. This is the same challenge every new communications platform faces, and platforms overcome it through some combination of viral mechanics, institutional mandate (an employer deploying it), or compelling specific use cases that justify the network-building effort. Wave had none of these at launch. The viral mechanics were gentle; there was no institutional deployment; the specific use cases that Wave served best — real-time collaborative writing, complex multi-threaded discussion — were niche enough that they did not justify the effort for most users.

The real-time typing feature, which had generated excitement in the demo, proved disorienting in daily use. Watching a message appear character by character while the sender composed it was cognitively demanding in ways that asynchronous email was not. Users reported feeling pressure to respond immediately and feeling observed while composing. The feature could be turned off, but it illustrated a general tension: the real-time capabilities that made Wave technically impressive were not necessarily features that users wanted in a daily communication tool.

Info

Lars Rasmussen’s retrospective: In interviews after Wave’s discontinuation, Rasmussen acknowledged the diagnosis directly: “We thought about the problems we could solve, rather than the problems users had.” The team had started from a technical opportunity — what modern computing and networking could enable for communication — rather than from a concrete user problem that people were frustrated by. Email users were not, in fact, loudly dissatisfied with email. They were adapted to its limitations. A solution that required them to change their behavior in order to get benefits they did not know they were missing faced a steep adoption hill.

The Discontinuation

Google announced on August 4, 2010 — fourteen months after the public launch, less than a year after the invitation-only preview — that it would discontinue Wave as a standalone product by the end of the year. The announcement cited “not having strong enough user adoption or traction to warrant long-term investment.”

The speed of the discontinuation was striking. Google had deployed significant engineering resources, announced Wave at its flagship developer conference with evident pride, and built infrastructure capable of serving many more users than it had. Fourteen months from public launch to discontinuation announcement was, even by Google’s standards for killing products, fast.

The message the speed sent to Google’s developer ecosystem was noted. Wave had recruited developers to build on its extension platform — robots, gadgets, the federation protocol. Those developers’ investments became worthless when Wave was discontinued. The pattern contributed to skepticism about building on Google platforms that would surface repeatedly in subsequent years, most prominently with Google Reader (discontinued 2013) and Google+ (discontinued 2019). Google’s willingness to shut down products that had built user and developer communities became a reputational liability.

Apache Wave and the Open-Source Continuation

Google released the Wave server software as open source in 2010, and it was accepted as an Apache project — Apache Wave — in October 2010. The federation protocol was documented and available for independent implementation.

Apache Wave ran for eight years, with varying levels of activity. At its most active, a small community maintained the server code and experimented with the protocol. At its least active, the project had few contributors and slow progress. Apache Wave was retired in 2018 — moved to the Apache Attic, the retirement home for projects with no active development community.

The federation protocol, which had the potential to become an open standard for real-time collaborative communication in the way that XMPP became an open standard for instant messaging, found no significant independent implementations. No major organization built a Wave-compatible server. The protocol died with the project.

What Survived

Wave’s technical legacy is more durable than its product legacy.

Operational Transformation as Wave implemented it became the basis for Google Docs’ real-time collaboration system. The Wave team’s work on OT at scale — handling thousands of concurrent users with real-world network conditions — was valuable research. Google Docs today serves hundreds of millions of users with real-time collaborative editing; that capability traces directly to the work the Wave team did.

Etherpad, an open-source collaborative editor developed independently of Wave, was acquired by Google in 2009 (the same year Wave launched), open-sourced by Google in 2009, and has since become the basis for collaborative editing in numerous open-source projects. The Etherpad codebase’s OT implementation is independent of Wave but parallel to it. Etherpad instances run in thousands of organizations and are used in activist networks, academic settings, and hackathons worldwide.

The conversation thread model Wave proposed — threads as shared state rather than collections of copies — influenced subsequent thinking about team communication. Slack (launched 2013) achieved in a simpler form some of what Wave attempted: persistent searchable conversation channels, shared across a team. Slack did not use Wave’s technology, but it solved the same underlying problem of “email is not the right tool for team coordination” — and it solved it by being simpler rather than more capable. A Slack channel is less powerful than a wave in nearly every technical dimension. It is also immediately comprehensible to a new user.

The collaborative document use case that Wave’s real-time editing addressed best was served, ultimately, by Google Docs itself evolving to handle multi-participant simultaneous editing. The functionality Wave demonstrated in 2009 — multiple cursors, real-time conflict resolution, named participants — arrived in Google Docs by 2010 and has become the expected baseline for collaborative documents.

Why It Failed

Wave’s failure was not technical. The underlying problem it addressed — that communication tools designed for 1971 network conditions were inadequate for 2009 team collaboration — was real. The technology to address it was built and demonstrated. The OT implementation, the federation protocol, the extension model, the persistent thread architecture — all of it worked.

The comprehension failure was fundamental. A communications tool needs to be explicable in a sentence. “Email: send messages to people by address.” “Instant messaging: real-time text chat.” “Google Docs: collaborative word processing.” Wave had no such sentence. “A shared, persistent, real-time-editable conversation thread with bot support and federation” is not a sentence that recruits users. The team understood what Wave was technically; they never found the framing that made it obviously valuable to someone encountering it for the first time.

The cold start problem was insoluble given Wave’s launch strategy. A communications tool requires a network. Wave launched without a network. The path to building that network required users to convince their contacts to adopt a tool those contacts could not explain and had no reason to use. The invitation-based launch, which generated artificial scarcity and enthusiasm among early adopters, created false signal: the users most excited about Wave in 2009 were engineers and early adopters who were already sold on the technical vision. Their enthusiasm did not propagate to the mainstream users who constitute a communications network.

Timing worked against the federation vision. The most technically ambitious part of Wave — the open federation protocol that would make Wave a decentralized communication network like email or XMPP — required significant implementation effort by third parties who would only make that effort if Wave had an established user base. The user base never appeared, so the federation protocol was never implemented by third parties, so the network effect that federation might have provided never materialized. The protocol arrived too early for its own adoption conditions to be met.

Wave is, in retrospect, an example of a class of failure that appears regularly in the history of communication technology: the technically superior system that requires network-wide migration and fails because it has no mechanism to achieve critical mass. XMPP (Jabber) was technically superior to AOL Instant Messenger, MSN Messenger, and Yahoo! Messenger — and was largely irrelevant to mainstream users until XMPP-based Google Talk integrated with Gmail’s user base. Wave had no Gmail. It had to build its own user base, which meant it was competing not just with the inertia of existing communication tools but with the inertia of the people using those tools.

The lesson Wave teaches is that the technical answer to a communication problem is never sufficient. Communication tools succeed when they have a community that wants to use them to communicate — and that community must exist before, or independently of, the technical elegance that makes the tool worth building.