Tag Archives: Google

Why I Am Ignoring Google Buzz

Note: This post is purely personal opinion based on my preferences and work style. If your are looking for an analysis of Google Buzz based on methodical primary research, abort now.

I have heard many people say that their email inbox is the mother of all social networks. For me, however, email is  the antithesis of a well-built, functioning social network, because it is a communication channel, not a collaboration enabler.

I value my social networks because I can work with members of those communities to get things done. When I worked at IBM, a very large company, my email inbox was more of a proxy for the organizational hierarchy than an instantiation of my social graph. Too much of my email activity was about low value (or value-less) communications and interactions imposed by command and control culture and systems. When I needed to communicate something up or down IBM’s or a project’s chain of command, I used email. When I needed to get something done, I contacted collaborators on Sametime (IBM’s instant messaging product), the phone, or BlueTwit (IBM’s internal-only, experimental microblogging system). In short, the contacts in my large corporation email address book were more reflective of the organizational structure than of my collaborative networks.

That is precisely why Google Buzz is a non-starter for me. The Google Contact list on which it is based does not represent my collaborative network, on which I rely to get work done. Very few of the people with whom I collaborate are represented, because I don’t interact with them via email. At least not often. A quick analysis of my Google Contacts list shows that Google Voice usage contributes more actionable, valuable additions to the list than does Gmail. My Gmail inbox is filled with communications, not action items, and most of them are low-value messages from application and service vendors whose tools I have downloaded or use online.

Google’s design of Buzz demonstrates ignorance of (or disregard for?) the reality that many social interactions happen outside of email. Had I wanted to use my Google Contacts list as a social network, I would have imported it into FriendFeed months ago. Strike One.

I just mentioned FriendFeed, which was my primary social network aggregator for several months. One of the reasons I backed away from heavy usage of FriendFeed was because it became little more than another interface to the Twitter stream. Yes, it is easy to inject updates from other sources into the FriendFeed flow, but, in reality, the vast majority of updates cam from Twitter (and still do.)

I see the same thing happening with Buzz. Too many people have linked their Twitter accounts, so that everything they tweet is duplicated in Buzz. And Buzz doesn’t allow for integration of the vast number of information resources that FriendFeed does. Talk about low-value. Strike Two.

I have not taken enough swings at Google Buzz yet to have recorded Strike Three. So, for now, I have not turned Buzz off. However, I am ignoring it and will not experiment again until Google provides integration with more external social networks.

In the meanwhile, I am still looking for a social tool that blends contacts and information streams from many sources, but lets me filter the flow by one or more sources, as desired. That would allow me to work both formal organizational and informal social networks from the same tool. Gist is promising in that regard, but needs to be able to capture information from more sources with corresponding filters. Hopefully, someone will read this post and either point me to an existing solution or build it. Until then, I will have to continue using multiple tools to communicate and collaborate.

Advertisements

Observations from Gilbane Boston 2009

The 2009 version of the Gilbane Boston conference was held last week. It was the second one I have attended and my first as a track coordinator (I designed the Collaboration and Social Software track and made it happen.) The event was well attended (c. 1100 people) and the number of sponsors and exhibitors was up significantly from last year’s Boston conference. Many of the sessions I attended offered valuable insights from speakers and audience members. All in all, I would label the conference a success.

The Collaboration and Social Software track sessions were designed to minimize formal presentation time and encourage open discussion between panelists and audience members instead. Each session focused on either a common collaboration challenge (collaborative content authoring, content sharing, fostering discussions, managing innovation) or on a specific technology offering (Microsoft SharePoint 2010 and Google Wave.) The sessions that dealt with specific technologies produced more active discussion than those that probed general collaboration issues. I am not sure why that was the case, but the SharePoint and Wave sessions spawned the level of interactivity that I had hoped for in all the panels. The audience seemed a bit reticent to join in the others. Perhaps it took them a while to warm up (the SharePoint and Wave sessions were at the end of the track.)

Here are some other, high level observations from the entire Gilbane Boston 2009 conference:

Twitter: Last year (and at Gilbane San Francisco in June 2009) attendees were buzzing about Twitter, wondering what it was and how it could be used in a corporate setting. This year the word “Twitter” was hardly uttered at all, by presenters or attendees. Most audience members seemed to be fixated on their laptop or smartphone during the conference sessions, but the related tweet stream flow was light compared to other events I’ve attended this quarter. The online participation level of folks interested in content management seems to mirror their carbon form patterns. Most are content to listen and watch, while only a few ask questions or make comments. That is true across all audiences, of course, but it seemed especially pronounced at Gilbane Boston.

SharePoint 2010: This topic replaced Twitter as the ubiquitous term at Gilbane Boston. If I had a dollar for every time I heard “SharePoint” at the conference, I would be able to buy a significant stake in Microsoft! Every company I consulted with during the event was seeking to make SharePoint either their primary content management and collaboration platform, or a more important element in their technology mix. Expectations for what will be possible with SharePoint 2010 are very high. If Microsoft can deliver on their vision, they will gain tremendous share in the market; if not, SharePoint may well have seen its zenith. Everything that I have heard and seen suggests the former will occur.

Google Wave: This fledgling technology also generated substantial buzz at Gilbane Boston. The session on Wave was very well attended, especially considering that it was the next-to-last breakout of the conference. An informal poll of the session audience indicated that nearly half have established a Wave account. However, when asked if they used Wave regularly, only about 20% of the registered users responded affirmatively;. Actual participation in the Wave that I created for attendees to take notes and discuss the Collaboration track online underscored the poll results. Most session attendees said they see the potential to collaborate differently, and more effectively and efficiently, in Wave, but cited many obstacles that were preventing them from doing so at this time. Audience members agree that the Wave user experience has a long way to go; functionality is missing and the user interface and features that are there are not easy to use. Most attendees thought Wave’s current shortcomings would be improved or eliminated entirely as they product matures. However, many also noted that collaboration norms within their organization would have to change before Wave is heavily adopted.

Open Source: This was the hot topic of the conference. Everyone was discussing open source content management and collaboration software. An informal poll of the audience at the opening keynote panel suggested that about 40% were using open source content management software. Many of the other attendees wanted to learn more about open source alternatives to the proprietary software they have been using. Clients that I met with asked questions about feature availability, ease of use, cost benefits, and financial viability of providers of open source content management and collaboration software. It was clear that open source is now considered a viable, and perhaps desirable, option by most organizations purchasing enterprise software.

My big take-away from Gilbane Boston 2009 is that we are experiencing an inflection point in the markets for enterprise content management and collaboration software. Monolithic, rigid, proprietary solutions are falling out of favor and interest in more lightweight, flexible, social, open source offerings is rapidly growing. I expect that this trend will continue to manifest itself at Gilbane San Francisco in June 2010, and beyond.

Google Wave Protocols: Clearing the Confusion

wavelogoToday is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on.

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

Andy1

To which I replied:

Larry1

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

Jevon1

I am not a technologist. I seek to understand technology well enough that I can explain it in layman’s terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Larry2

Larry3

Jevon2

Larry4

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

wave_protocols

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

  • XMPP for server-server communication
  • HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
  • HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
  • Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee’s question, I would unequivocally state that Google Wave is a “concept car” at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.