Slashdot Mirror
Google Wave and the Difficulty of Radical Change
cedarhillbilly writes "An article by Matt Asay in the Register takes on Google Wave from the perspective of visionary change versus incremental change. He suggests that visionaries should focus on smaller transformations of our day-to-day lives rather than leapfrogging. '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.' Perhaps Google sensed this when they famously said they were worried about having too many geniuses. Asay revisits the point that the open source development model necessarily builds on a community of contributors and users, and not the mad scientist in an ivory tower."
No, it doesn't, at least according to this rule: "Any software in this century that reinvents the scroll bar deserves to fail" - http://www.scottberkun.com/blog/2010/lessons-from-wave-and-kin/
Google Wave was a collaboration tool, and that made it nearly useless during its limited preview. It was available generally for less than three months before Google killed it. That would be a ridiculously short time for any new service, let alone for one that actually requires network effects to become useful.
I don't know whether Google Wave would have replaced E-mail or chat; it had the potential to do that, but that was far off. But it was an excellent collaboration tool. It could have been Google's replacement for Sharepoint, Lotus Notes, and systems like that, and it looked like it was on track for that. Incremental changes to GMail are not going to cut it.
With killing Wave, Google killed something that could have become quite important for them in the future. And they also killed the good will and trust of a lot of developers and users.
Google should have given Wave three years, not three months, of general availability.
I think this is one instance where Google's limited release method failed spectacularly. When they started to release Wave, I had a bunch of people in mind to collaborate with, but only one or two of us had it. By the time it was available to the majority of us, we had already gone back to using other means of communication, including Google's own docs. For all its potential, we ended up only having two active waves of substance. Hopefully they'll be able to incorporate some of the more interesting concepts into Gmail or Gtalk, and I think Docs already has some simultaneous editing features. So wave may live on, just not as wave.
Be quick to listen, slow to speak, and slow to anger.
Probably was being too radical more than the initial stability problems and bugs what hurt the grow that KDE was having by the time the version 4 was introduced. Still, as was basically "the" direction to follow with the entire platform (you could leave it going to gnome, stay with kde 3.x while all the apps move forward, or adapt to the new approach) it survived, and now is growing (not having hard numbers of gnome, kde and other linux desktops, but i think it went that way)
I don't see any benefit to integrating email into the Wave system - I wouldn't want to interactively create an email message,
That's not the only thing you could do with it. Since it had extensions, you could easily embed, say, a map, a calendar meeting, or a survey into a Wave. Tools to embed these things into email are cumbersome, nonstandard, and not necessarily secure. Having the concept built-in has some advantages.
It's also useful in that if someone's not online, it can behave like email, much better than IM offline messages for the same purpose. But when someone is online, it simply and naturally flips to IM. It's nice that Google Talk is in Gmail, but it's not truly integrated -- I can't immediately continue an email conversation as IM, or vice versa.
Don't thank God, thank a doctor!
Google did a great job creating an open protocol. But they made two mistakes:
1. They were not open enough. Although they had suggested that people would be able to build their own clients (and demoed a curses based client) they never opened an API for writing a wave client. They wanted it to be a flagship web application - but just as people like all sorts of different clients for email (even if many now like web clients), they would probably have liked client choice for wave - especially if 3rd party clients had shown waves along side email and the like.
2. They were too open. Their programming model for wave (web-hosted applications with read and write access to your wave) had huge security implications. It was not clear from the UI who would have access to your data and when.
Both of these were things that slowed adoption of wave.
In regards to the original topic, "Revolutionary" change, especially in software, is often remarkably... effective in sweeping away the ghosts of the past which weigh upon the minds of the present.
As example, a gem from the days of Wang which I just came across:
As an example of this strategy, a frustrated developer wrote Wang’s second generation e-mail system (Wang Office) over a long weekend. In his view–and he was right–the official spec meetings were taking too long. So he decided to cut through the bullshit and just code the thing (he’d designed Wang’s first generation e-mail system, Mailway, so he knew what he was doing). He sent out the new code to several large accounts, they loved it, and started calling headquarters asking, “We have the checkbook out–how do we buy this great e-mail system?” Back at headquarters, everyone (except for Steve) was going, “Huh, what are you talking about?” Once management realized that (1) customers wanted to buy it now and (2) doing it the “official” way would take another 18 months, they swallowed their pride, shot the official project, and gave Steve a small official slap while privately lauding his initiative.
/me files Matt Asay in the [bullshit|?|clueless|lost|confused] category.
Promise your existing customer base ('everyone') a miracle (vaporware) product that will do everything that they ever wanted. Promise it next year. That way, when your competitors come out with a real product that does most of what your customers want -- or even all of what they really need, you can convince their CxO to "just wait until next year when our miracle product comes out -- then you won't have to deal with migration issues, etc.".
Then you can slowly move the target -- both what your 'miracle' product does and when it will be out -- until your promises and reality jive. By then your competitor's product will be easy to pooh-pooh as 'only slightly better than what we've got' and needing all of that migration work, etc.
Rinse, repeat.
Microsoft took a big hit with Longhorn -> Vista because Vista turned out to be such a massive dud. Now, MS is going to have a hard time convincing people to believe any of their long-term promises about much of anything.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
I spend 8+ hours a day programming in front of 3 screens with about 10 tabs open in each and I've never even heard of it. Maybe, just maybe, that's why it failed.