Google Wave Book

By now chances are pretty good that you've heard of Google Wave, Google's new real-time communication and collaboration platform that incorporates several types of web technologies, including email, instant messaging (IM), wiki, online documents, and gadgets.  If you're still coming up to speed, you can check out my Introduction to Google Wave article on oreilly.com. In the process of writing Google Wave: Up and Running, I've been fortunate to have multiple opportunities to discuss Google Wave with a variety of folks, including techies and non-techies alike.  In this introductory post, I'd like to briefly discuss Google Wave at a macro level, and in particular touch on the fact that Google Wave is more than a product, but an uber-platform comprised of three layers. Google Wave is not just an app. You read that right.  Most folks think of Google Wave as a web app, but in fact the app is just one of the layers of Google Wave, albeit perhaps the most visible of the layers.  The other two layers are the Google Wave APIs (commonly referred to as the platform layer) and the Google Wave Federation Protocol (commonly referred to as the network protocol layer). Despite the fact that Google made this distinction early on, the breadth of the Google Wave "platform" inherently makes it a little bit more difficult to get the point across to a diverse audience.  Here is how Google describes these three layers:

• The Google Wave product (available as a developer preview) is the web application people will use to access and edit waves. It's an HTML 5 app, built on Google Web Toolkit. It includes a rich text editor and other functions like desktop drag-and-drop (which, for example, lets you drag a set of photos right into a wave).
• Google Wave can also be considered a platform with a rich set of open APIs that allow developers to embed waves in other web services, and to build new extensions that work inside waves.
• The Google Wave protocol is the underlying format for storing and the means of sharing waves, and includes the "live" concurrency control, which allows edits to be reflected instantly across users and services. The protocol is designed for open federation, such that anyone's Wave services can interoperate with each other and with the Google Wave service. To encourage adoption of the protocol, we intend to open source the code behind Google Wave.

Why is this distinction important?  For one, the overall game-changing implications and potential of Google Wave cannot be fully understood if one simply thinks of Google Wave as a web app.  The app itself is important, yes, as it represents Google's current effort to provide end users with a way to utilize the protocol and extensions developed with the APIs.  But the other two layers are just as important.  The fact that the open APIs can be used to extend, enhance, and improve communication and collaboration are just as important.  And the fact that the protocol is open source and allows for federation (i.e., multiple providers) is also extremely important, as other parties will be able to set up interoperable wave servers. Not everyone needs to understand the three layers at a technical level, but I do think it's valuable for just about everyone to understand that Google Wave is more than the web app.  My mother, for example, will never write a line of code for the APIs, and the only protocol of which she's aware relates to dining etiquette.  Still, I am proud to say that she "gets" it.  She understands that developers can program cool extensions that can be used in the app, and she's aware that in the future other service providers like Yahoo!, AOL, and Microsoft could provide their own wave accounts (and maybe even apps). Now, getting her to wave with me about topics other than why I don't call her enough is a different story.