google_wave_logo-760260

I was just debating with a friend about the value and usefulness of Google’s Wave in the enterprise.

His argument is that Wave has 10 years of adoption curve ahead of it and would not quickly replace email or wikis for enterprise staff.

I tweeted my response:

20% of enterprise users will be using wave in the first 12 months for more than 50% of their comms (replacing email and wiki)

Edit: To be clear, my 12 month time frame begins when Wave is publicly available.

That’s a big call to make on enterprises adopting a radically new technology. Enterprises move very, very slowly. So why am I so bullish on the adoption of Google Wave in the enterprise?

Here’s why…

Email is king

Everyone uses email right? Why would people swap? Because with Wave, they don’t have to.

First, with Wave’s API there will quickly and instantly (I mean in weeks, long before public launch) be integration between Wave and Email. Wave messages and events will  be funneled to email and back again as if the two were built from the same protocol.

Second, Wave will be viral. Users will quickly realize that their email inbox is only giving them a pale imitation of the Wave collaboration experience. It will be like working with shadow puppets while your friends are over having an acid trip of light, sound, fun and productivity.

If someone had told me that they were setting out to kill/replace email, I would have laughed in their face. Now that I see the Wave product and roll out strategy – I think it might actually happen.

Enterprise IT Departments

IT departments are slow to adopt and roll out new technologies right?

People forget that enterprises are just a collection of human beings. Social beings. Like IM, Facebook, LinkedIn, Gmail, Wikis and countless other applications, Wave will soak into an enterprise long before the IT department knows what the hell is going on.

The enterprise adoption curve of Wave, however, will make those other technologies look glacial. Everyone who ever picked up a Wiki, IM client, Facebook or Twitter (I think that covers 99.9% of the developed, working world) will latch onto Wave for dear life.

Everyone else will be forced to open a Wave client to find out what the hell is going on.

Too many tools

Enterprises indeed have many, many tools that already ‘own’ a large part of a given knowledge worker’s/enterprise user’s day.

None of them matter anymore. Again, with Wave’s amazing API and extensibility model, each of these apps, custom or not, will have a Wave bridge.

Official Wiki Pages, Sales Reports, Bug Tickets, New Blog Posts, Emails, Customer Records will all be available and accessibly from the Wave interface.

Who’s going to write all those bridges? Hacker employees, smart IT department engineers, new start-ups and the companies that own those other products hoping desperately to remain relevant and competitive.

Half Lives

Geocities, MySpace, Facebook, Twitter. What do these things show us? That technology adoption has a half-life. Geocities lasted as king of the heap twice as long as MySpace, MySpace twice as long as Facebook and so on. We are approaching a kind of singularity – although just like with the mathematical function, one can never achieve 0 of course.

Sure, enterprises move much more slowly, but when was the last time a really new enterprise productivity application hit the market? Do we even know what the current half-life is? My bet is that it’s pretty damn short – and Wave has the potential to be ahead of the curve.

Related link: Business Opportunities around Google Wave

Forget Facebook

May 16, 2008

Debating Facebook’s data portability move (Facebook Connect) is like debating AOLs web strategy back in the day. Their strategy is clearly to create a rarefied ecosystem where users (read: facebook) are in complete control of the ‘approved’ content and interactions. With this in mind, it is clear that Facebook is not the first, best platform in which to design, implement or debate Data Portability.

Debating Google’s data portability move (Friend Connect) is like debating the Netvibes universal widget platform. It is not data portability in the sense that the DataPortability project has defined it. It is a platform that translates existing proprietary implementations into it’s own unified proprietary implementation to enable social widgets to run in more places.

MySpace’s data portability move (Data Availability) is actually the closest play to data portability as defined by the DataPortability project. It proposes to allow 3rd party sites to access the users personal data using open standards extracted from the page (using microformats and a collection of full XML standards). The terms and conditions about caching, however, also bring it in conflict with the philosophies of the DataPortability project.

So as stated before, none of these plays are true ‘DataPortability’ implementations. But they are important first steps. They are the first shots across the bow to the industry that a data portability battle is coming. In fact it has started. Are we going to let it shake out like the IM wars? Or are startups, second tier players, standards groups, bloggers and users going to rally around and standardize to a totally open, grass-roots alternative?

Are the big players going to evolve their offerings to come in line with the rest of the world, or are they going to try to dominate (read: lose).

Further, data portability, and DataPortability is not just about social networking data or social networking scenarios. Certainly not social networking as defined by the social contract of Facebook. It might even be true that Facebook is a culturally bad fit for the DataPortability ecosystem. DataPortability is about a different social contract – a contract more closely resembling the one found in the email address book.

My address book is my own. When you email me, or when you communicate with me, you are revealing something about yourself. You define a social contract with me that means that I can use your information to contact you whenever and however I like – I could even re-purpose my address book for all manor of other things.

If, however, you violate that trust, either directly or indirectly, you break the social contract and I will tend to not deal with you again. We can not perfectly engineer these sorts of contracts into systems – we can try, but in the end social behavior will be the last mile in enforcing user rights.

Also, the dichotomy between who ‘owns’ the data is false. In my mind there is shared ownership. While you use a service, it has a shared custodianship of the data. By giving the service your data you’re getting something else in return – utility. In many cases free utility.

You personally, however, have shared (and overriding) ownership over your data. This has been declared as universally true by all the vendors I’ve spoken to.

The question is not one of ownership though, it’s one of control. If you own your data but can’t control it as you choose then ownership is a moot point. Further, the question is not one of if you own it, but rather how much of it you own.

For example, do you own your friends profile data since you have access to it via the social tool you are using? Or have they only granted you access within that social context and under that social contract. These considerations blur the analogy of the purely personal address book.

In this case, there is no correct, default answer. The answer must come from an old saying – “Your rights end where my rights begin”. That is, your friends need an additional options when ‘friending’ you. A checkbox will probably be required that states ‘Allow this contact to use my data elsewhere’.

The act of ‘friending’ will also need to take on more meaning and ‘grouping’ friends will become important. It will evolve, for most of us, and in most applications, from a popularity contest to a carefully curated address book of people we actually care about.

MySpace has officially joined the DataPortability project and will work with us to turn their ‘data availability’ push with the DataPortability Best Practices

Check out the news

David Recordon has a very clever observation over on the O’Reilly blog about the Google App Engine potentially marginalizing both OpenSocial and Facebook Platform.

I think he might be right. Long term, the goal of most App developers should not be to develop gadgets in containers, but rather to build first class applications on the ultimate platform of all, the Web.

With tools like Amazon Web-Services and Google App Engine reducing infrastructure and scale costs even further, an emerging data interoperability layer via DataPortability and an increasing desire to add social functionality to most apps and services, the future looks bright.

I look forward to the day when I can use my best-of-breed applications (such as Flickr for photos – and now video!, Twitter for status updates, Ma.gnolia for Bookmarks and Google Docs for document collaboration) all backed by my personal, universal address book. My personal social network.

Combine everyone’s address book together and you get what you get is what Tim Berners-Lee calls the Giant Global Graph.

The opportunity for Myspace, Facebook and other large social networks? Continue to provide a simple user experience for the mainstream in the mean time, and evolve quickly into an Identity Provider and social hub of the future.

In the last couple of weeks there have been a number of very positive steps forward for Data Portability in general and the DataPortability Project specifically.

These include wins by the OpenID Foundation, the IC report, the DataPortability Report and others.

A couple of trends, though, are causing me a little concern and may require a slight course correction before they spin out of control and fragment, rather than standardize, the ecosystem.

1. Tightly coupled OpenID Implementations

On Plaxo right now there is a ‘Sign in with YahooID’ button. This is effectively an OpenID login mechanism, except to remove the user experience complexity of OpenID, Plaxo has worked with Yahoo to make it easier by creating a direct relationship.

This seems antithetical to the promise of OpenID and could ultimately create another mess of tightly coupled vendor relationships that defeat the purpose of a single sign-on identity that any provider can provide and consume.

A more long term solution must be to improve the generic OpenID user experience or devise an education campaign to help users learn the new login process.

2. Google’s Social Graph API

While revealing an enormous usefulness in the existing XFN and FOAF data out on the web, Google’s Social Graph API also reveals a weakness in current XFN and FOAF implementations. Many users are not aware when XFN data is included around URLs they enter, much less when the URLs are marked as rel=me.

For example when Twitter asked me for my homepage, I didn’t understand that I was asserting a semantic link from Twitter to my blog that Google would later document and carve into stone as part of its implicit global social network in the sky.

As it stands, there is a real concern for user backlash as these APIs start being implemented and users find themselves presented with eerily accurate information about themselves magically appearing on websites without their ‘consent’.

Some sort of best practice text and/or iconography is required around fields that will be marked up with XFN – particularly if rel=me will be used to that users can make informed decisions about the type of data they provide and how it might be used. Perhaps even an opt out checkbox is appropriate.

This is probably a job for the Microformat community to dig into and solve. They should probably solve it quickly though.

3. OpenSocial++

As OpenSocial implementations role out, it’s becoming clear that there is no such thing as a pure OpenSocial container. Each container includes proprietary APIs and extensions that widget developers may choose to use.

Presumably these exist to differentiate each network and encourage developers to write enhanced apps for the environment.

The problem, though, is that developers need to write defensively for each custom API leading us to a place similar to browser compatibility hell. App developers will need to write and test their apps across every Container and will either have to hard code support for special APIs or keep their apps generic and ordinary.

Is this sustainable? Is there a better way?

If OpenSocial is going to be the Write Once, Deploy Many model for widgets, then the OpenSocial team at Google need to find a way to address this concern quickly.