Original URL: https://www.theregister.com/2010/08/20/google_wave_lessons_learned/

Google's Wave flop: Spare us the warm fuzzies

Behemoth acting alone is suspicious

By Matt Asay

Posted in Software, 20th August 2010 14:02 GMT

Open...and Shut Google's Wave has crashed, but the trick for Google is to learn the right lessons from its failure.

Some suggest that Google Wave displays Google's willingness to innovate at the risk of failure, which likely gives the search giant warm fuzzies. Instead, I believe it reveals the ways in which Google can improve its third-party developer engagement.

In 2008 Google began reaching out to open-source developers in earnest. As part of that outreach, Google has fixated on the mantra of "speed to build and deploy" applications on its infrastructure, without forcing developers to become mired in the details of that infrastructure.

This is where Google Wave went wrong. It didn't abide by Google's developer playbook.

Sure, Wave attracted developers. Six thousand of them signed up, though far fewer actively developed code for Wave. But not with the same intimacy that developers collaborate on Apache projects or the Linux kernel. Or even in the same way that developers participate in Google's Android project. Wave was Google. It was hard for anyone else to get involved.

Going solo wasn't a good strategy, as Dana Blankenhorn writes:

An individual or small group going it alone is courageous. A behemoth going it alone is suspicious. Without allies, without external support, a Google project run by Google alone is in trouble.

Getting significant outside involvement was always going to be hard to attain, however, given that Google Wave wasn't merely a matter of diving into a new code base and learning some APIs. It required a complete refactoring of how one thinks about communication. That's a tough proposition for leading an open-source development project, as Alex Williams argues:

Google Wave also required people to change how they use the Web and interact with each other. It represented a melding of technologies. Developers do not like to have to adapt to big changes in behavior. Developers can not afford to take on that kind of challenge, especially with a technology as complex as Google Wave.

So why didn't Google start smaller, rather than opting to promote a rip-and-replace approach?

Consider: e-mail reaches 1.4 billion people, according to Radicati, and took 39 years to hit that penetration. Nearly four decades. Given how long it took to embed itself in our business and social processes, e-mail is unlikely to be unseated in developers' or consumers' minds with the "wave" of Google's hand (bad pun intended).

This isn't to suggest that Google shouldn't try to change how we communicate. After all, SMS is "only" 17 years old and reaches three times the number of email users, while MMS is only eight years old and has 1.9 billion active users.

Clearly, there's room for new entrants in the communications market.

"Mind bending" is not a plus point

But the difference between what SMS and MMS do, and what Google Wave sought to do, is that these technologies complement existing modes of communication - voice, email - rather than seeking to replace them. A Google Wave service that allowed developers to keep what communication methods they have, and bolster them with Wave, would likely have gone farther.

As Adina Levin of SocialText opines:

Wave attempts to mash up email threads, documents, and streaming communication. Each of these is familiar and not that hard to understand. The combination seems a bit mind-bending.

"Mind-bending" isn't necessarily the right approach when you're trying to foster a developer community. While it's critical to appeal to developers with an interesting initial code base, as Joel West and Siobhan O'Mahoney's research details, boring things like clear purpose and comprehensive documentation weigh as heavily for developers. Gartner research vice president Brian Prentice argues that had Google been more interested in its external community than in satisfying internal goals, "there would have been significantly more design work, user analysis and testing upfront" to pave the way for outside involvement.

This might have lowered the barrier raised by Google's ambitious break with the past. While Google thought this a positive, it was a huge negative for its development community. As much as we may want to forget the past and look to the future, the reality is that developers and consumers alike have huge investments in the past, as Ryan Paul suggests:

The developers who created Wave felt that they needed a clean break from the past in order to move messaging into the future. One consequence of that design philosophy is that Wave has no built-in support for the existing communication services that are ubiquitous today. Wave users can really only use Wave to communicate with other Wave users but can't serve as a bridge to conventional e-mail and instant messaging...

[T]he service's lack of support for existing messaging protocols precluded the possibility of pulling it out of the browser and using it with existing messaging tools and workflows. If the developers had found practical ways to make it interoperate with Gmail and Google Talk, it would have been much more useful right away.

It's interesting that Google's big attempts to change the way we think and work - projects like Wave and the Nexus One direct-to-consumers store - have failed. Pretty much completely. But Google's incremental advances - search and Gmail, for example - have done exceptionally well.

Perhaps there's a lesson in this for Google?

Much as it may want to radically change the world for users and developers, radical change generally happens over time, through a series of incremental, unexceptional edits to existing technology and processes.

The hugely positive news, however, is that the Wave code is open source. I suspect we'll see its radical techniques find their way into less radical software: incremental advances on existing technologies. In this, Google's Wave may yet prove to alter the communications landscape, even as it teaches Google the right way to work with its development community.

Slowly, but surely. ®

Matt Asay is chief operating officer of Ubuntu commercial operation Canonical. With more than a decade spent in open source, Asay served as Alfreso's general manager for the Americas and vice president of business development, and he helped put Novell on its open-source track. Asay is an emeritus board member of the Open Source Initiative (OSI). His column, Open...and Shut, appears every Friday on The Register.