“What would email look like if we set out to invent it today?” – Lars Rasmussen, via Tim O’Reilly
In spite of substantial evidence that it’s at best a mixed blessing, the world outside of technology largely celebrates tradition. Even as humanity moves forward, we actively look for ways large and small to anchor ourselves to our past. For better and for worse, the answer to “Why do we do things that way?” is usually “Because that’s how they’ve always been done.”
The technology industry, on the other hand, is far less warm and fuzzy about that idea, even as it is similarly beholden to that which came before. Tradition and related terms like “legacy” are little but a pejorative in our world, spat out about products that have, in their antiquity, become the the very burden they were designed to relieve.
All of which is a long winded way of explaining just why I think Google Wave is so interesting: it’s not legacy. Rather than mimic the traditional channels like physical mail or telephony, Wave is a deliberate and clean departure from the past: it’s a complete rethinking of the way we communicate today. Which is why it should fail, but might not.
When I took a look at IBM’s Jazz product a few years back, I said the following:
If application development had been invented after Ajax, Bazaar/Subversion and instant messaging it would look a lot like Jazz.
Whether you agree or not with that assessment vis a vis the Jazz product is immaterial here, because it’s the concept we’re after: the idea that it may periodically useful to fundamentally rethink the evolution of one product in light of the development or invention of other seemingly unrelated products. While I personally both hate and fear them, if evolution worked differently, bats would be excellent examples of this: what happens if you rethink what a small mammal can be, in light of the invention of wings and sonar?
For perhaps a more useful example, consider mobile phones, which become dramatically more interesting – and different – once cameras can be shrunk to a certain size, touchscreens are available, wireless data networks become broadband-like in their bandwidth, suitable processors reach reasonable speed thresholds, and battery life will support all of the above. What is a phone in light of those external developments?
We’re beginning to find out. Meanwhile email is, like sharks and crocodiles, largely unchanged from an evolutionary standpoint. Which is why Wave was built, of course.
We don’t see a lot of dramatic leaps forward in software, I’d argue, both because it’s exceedingly difficult to develop and launch revolutionary products and because the economics act against it. It’s difficult, of course, to produce them: how many vendors can afford the indulgence of turning high quality resources loose on a multi-year project with no clear revenue plan in place? But it can be even more difficult to market sell them, because, well, they’re not what people are used to and they take some explaining.
As the task of explaining new technologies is kind of our job, as analysts, let’s do a quick Q&A on some of the questions we’re getting about Wave. Because I was unable to do San Francisco/San Francisco/Alaska in consecutive weeks, I couldn’t make Google I/O and thus don’t have a Wave account, but I’ve been through enough of what’s available to answer at least a few high level questions.
Q: For those that missed it, what are the basics of the Google Wave news?
A: The Google folks, in announcing Wave, consider the product in three pieces: product, platform, and protocol. I’d probably collapse the first two, in that the product itself is inherently a platform, with all of the attendant benefits (and cautions). The protocol, for many, is the really interesting piece, in that it’s open in the sense that it’s documented, if not from a participation standpoint. In a manner of speaking, it’s a new hosted collaboration server product with a new documented protocol.
Q: Is Wave vaporware?
A: That depends on your definition, but according to mine it is not. The product is not publicly available, but it does exist and is supporting alpha users at present. Further, the protocol is both defined and documented. So this is more than smoke, mirrors and promises at this point.
Q: What did that mean above, “new hosted collaboration server?”
A: That’s the tough part to define. To help, I’d recommend checking out either the Google Wave keynote from I/O, or more simply, Andy Ihnatko’s piece, “Google Wave is genius, but will it work?”. Both will give you a hands on look at Wave, which collapses the distinctions between IM, email, and documents seamlessly. Indeed, it challenges basic conceptions of what’s a document and how it’s worked on, hence the invention of the new term “Wave,” which I, for the record, don’t love.
Q: How does it challenge ideas of what a document is?
A: Even absent Wave, the definition of a document is evolving rapidly. Simply put, the traditional notions of what consititutes a document are rapidly becoming obsolete in a variety of settings. Here’s how I’ve described the transition in the past:
Documents today can have, as IBM’s Doug Heintzman noted last Wednesday at IBM’s annual analyst event, more in common with a web page than the document you or I might have authored a few years – or a year – ago. Parts of it might be static, parts of it might be dynamic, but each of those parts might arrive from separate, external sources of record. The days of static documentation are drawing to a close, thanks to innovation – finally – in an area that should have seen it years ago.
While we at RedMonk are so far out on the bleeding edge that we can’t even see the mainstream when it comes to our own work habits (though not our coverage, hopefully), it’s nevertheless worth noting that I really don’t create documents at this point. Customer, expense and other operational spreadsheets are kept in Google Docs, and frankly they’re more webpage – even database – than they are spreadsheet at this point. At no point in their lifecycle, generally, are they transmitted as ODF, OOXML, or PDF: I can’t honestly remember the last time I exported one for the purposes of sending. When we need to collaborate with an external party, we simply share the asset. Even the pieces I author for this space are documents only in a nominal sense. Each is composed in emacs, then pasted to WordPress. There, it is reforged as an entirely different asset, pulling in pictures, videos, or other embedded assets, all while collecting comments, trackbacks, and revisions to become something new and distinct.
Is that a document? I’d argue not.
Wave, in many respects, can be seen as aggressive embrace of this transition. The word “wave” itself can be considered, in a sense, as a drop-in replacement term for the increasingly archaic “document.” As Google puts it, “A ‘wave’ is equal parts conversation and document.”
By exploding the notion of a document and how it’s created, Google frees itself from some of the strictures that traditional office productivity vendors must adhere to in service of their respective markets. Whether that will lead to market success is yet to be determined, but it certainly gives them more flexibility in attacking an increasingly dynamic space.
Q: And what of the document creation process? How has Google abandoned tradition there?
A: Google and other SaaS vendors like Zoho have long enjoyed an advantage in this space, in that documents hosted online are easier to work on in collaborative fashion. Anyone who’s coauthored documents using Google Docs realizes this. But Wave takes this concept further by eliminating the barriers between collaborative channels around the document; documents can be collaboratively constructed in real-time or asymmetrically using instant messaging like presence and commenting, all of which is captured and becomes, effectively, a part of the document…er, sorry, Wave.
Q: Doesn’t that introduce tremendous versioning challenges? Constantly updated documents are, after all, potentially problematic in real world settings, not to mention compliance?
A: There is no question that we’re all going to have to adapt to the idea that the days of static documents are, for all intents and purposes, nearing an end. We’ve seen this coming for years, of course, which is why we’ve seen the rapid evolution of everything from distributed version control systems like git and Mercurial to syndication formats designed to alert us to changes in content. So yes, versioning is going to be a challenge.
But there are two things mitigating the issue. One, Waves can, of course, be snapshotted into particular documents or formats. So you can, for example, produce from a collaborative process a one time report, memo, whatever that will have a predictable and non-dynamic lifespan. More interestingly, however, Google Wave understands inherently the challenges of this process and offers a Time Slider-like ability to walk backwards through the history, revisisting not just the changes and change history, but the evolution of the Wave itself.
Q: Is this type of group collaboration and multi-artifact incorporation a new concept in the collaboration space?
A: Very few things are developed in a vacuum, and Wave clearly is no exception. We’ve seen similar efforts like this from Groove – since acquired by Microsoft – and more recently IBM’s Lotus, with its notion of Activity-centric Collaboration. Wave borrows heavily, in my view, from both Groove/Microsoft and IBM in its reimagination of what the collaborative process should look like.
Q: So what’s the difference between Google Wave and those efforts? Groove never hit the bigtime and ultimately exited via acquisition, while the Lotus’ Activity-centric collaboration hasn’t exactly broken the hold of email centric workflows either?
A: Maybe nothing. But in a couple of key areas, Wave has some advantages:
- The Cloud:
One of the difficulties, at least in the last version of Groove that I used, was that the technology was ahead of the hardware. The type of seamless, multi-party real-time collaboration Wave aims to achieve is (or was) computationally challenging; even on brand new Thinkpads, Groove was borderline unusable for me prior to its acquisition. Google, as it has in other arenas, offloads this workload to the server, ensuring that the client hardware is not a limiting factor (and cementing its business model simultaneously). - The Cost:
Unlike Groove or Notes, Google Wave will be free and therefore – by definition, will have the opportunity at addressing a wider market. - The Protocol:
While both the Groove and Lotus products spoke in standardized protocols like SMTP, the secret sauce of their collaborative ability was never – to the best of my knowledge – fully documented and exposed, thereby opening opportunities for third parties and allowing at least for the possibility of a surrounding ecosystem. Not to mention the ability for enterprises to host their own implementations that don’t sit on Google servers.More, as Joe puts it:
The difference is that the extension model with Wave is events over HTTP, which makes it language agnostic, a feature you get when you define things in terms of protocols. That is, as long as you can stand up an HTTP server and parse JSON, you can create robots for Wave, which is a huge leap forward compared to the extension models for Notes, Exchange and Groove, which are all “object” based extension models. [Note: Sam Ruby doesn’t necessarily agree].
Not that the protocol is perfect, of course.
Q: Let’s look at the protocol some more: is it really open?
A: The answer depends in part on where you’re coming from with respect to open protocols, but the short answer is no. It is open in the sense that it’s documented, but there are two primary issues which challenge that definition. First, there’s no external participation in the direction of the protocol at this point: “The committers for the Google Wave Federation Protocol project are currently all from the Google Wave engineering staff.” The plan is for that to change, apparently, but at the current time the development cannot be considered open. Second, there are – as is all too common – undocumented aspects to the API and the protocol itself. Much of the success or failure will depend on Google’s ability to make the entire stack as transparent as possible, top to bottom.
Those criticisms notwithstanding, is it a step in the right direction? I think so.
Q: Do you think that Google Wave is open enough to encourage third parties or competing vendors to participate?
A: It’s too early to say, and there are many variables that will play a role in the adoption of lackthereof of Wave beyond the Google firewall. But I did find Zoho CEO’s Sridhar Vembu’s comments from a piece talking about Google Wave and Microsoft Silverlight interesting:
That brings us back to Google: today, it is Google which is driving web standards forward. That is why we at Zoho are firmly aligned with them, even if they are our primary competitor. We believe in an open web, there is plenty of opportunity for all of us.
While not promising anything specific, they at least indicate a willingness to work with Google on the subject, which is quite the accomplishment, considering that Google aggressively competes with Zoho.
Q: What about the claims that Google Wave means that HTTP is dead?
A: Not sure I followed them, really, given that the Wave Javascript libraries, anyway, leverage HTTP pretty heavily, and that as Joe puts it, “the extension model with Wave is events over HTTP.” It’s true that XMPP is given a leading role in Wave, but as I have for some time, I see this as purely different tools/different jobs. And even if we forget all of the above, the fact is that HTTP is so fundamentally embedded into the fabric of the internet that its place is guaranteed for years to come.
Q: Is Google Wave open source?
A: Not yet, at least. As Lars Rasmussen told Tim O’Reilly, the intent is there: “To encourage adoption of the protocol, we intend to open source the code behind Google Wave.” But that hasn’t happened quite yet, so the answer at present is no.
Q: So considering all of the above: what does Google Wave mean for established office productivity vendors like IBM and Microsoft?
A: At present? Not much. Same for the near term. Considering how much pushback enterprises have had about a mere reskinning of an existing product in Office, the idea that Google will have substantial immediate success in pushing such a radically reshaped authoring proposition on a conservative market is laughable.
Over the mid to long term, however, it represents a potentially serious competitive threat. For years one or both vendors have effectively defined the office productivity experience, from collaboration to document authoring. And while, as discussed, both have experimented with radical reconsiderations of that experience, neither has had much success driving significant change into the mainstream. If Google Wave is successful, it will mean that Google will be the vendor defining the next generation experience for millions, potentially tens of millions of users, worldwide. Next to that prospect, the threat of Google Apps is but a trifle.
We’re already seeing enterprise collaboration vendors struggle to adapt to generational shifts in the workplace, as older retirees are replaced by young, tech savvy graduates. They’ve also grappled with the increasing importance of simpler, SaaS offerings and the threats that tools from Facebook to Twitter may pose. Wave, in many respects, is a far more grave concern than any of those, so fundamentally does it target what has traditionally been the province of high cost enterprise productivity tools.
So while there’s a long way to go between here and there, and success is far from guaranteed for Google’s latest product, Wave is one to watch.
Disclosure: IBM and Microsoft are RedMonk customers, while Google and Zoho are not.
