Up until now it appeared that Google’s strategy has been “throw a bunch of shit at the wall, and see what sticks.” But I believe that a much more onerous, classic Microsoft like ‘land-grab’ is ocurring - which should not startle you, since so many of Microsoft’s evil cabal have now moved over and started working at Google.
Here’s the way this land grab has played out over the past three years:
1. First of all make sure that Blogger - your first piece of the puzzle, does NOT support RSS and XML-RPC or the Metaweblog API. Make sure it demands that developers support some proprietary protocol - the so-called ‘Blogger API’.
2. Then when it comes to reinventing RSS, go for it. Provide support, resources and even house the meetings on your campus for Atom - the so-called next generation protocol. So far so good. No one is gonna complain about that - right?
3. Now launch a whole bunch of stand alone apps and services - each with ‘open APIs’ and get the whole mashup thing happening big. VCs start to fund mashup companies - entirely dependent on the mother Google’s tit for life and existence.
4. Now start to move into the UGC (user generated content) world with Google Base and Google Video - but don’t announce any API access to this data - which is OUR data. That’s when I started to smell something stinky.
5. Now read Chris Messina’s post on Google and their GData strategy. I was gonna originally name this post “building a Google wall” but Chris came up with the mousetrap metaphor, so we’ll stick with that. In this post Chris points out the subtleties of lock-in.
How Google is on one hand is building a nice integrated suite of apps and services and inter-connecting them together with open………………………. ooooops - not OPEN standards, but their own ‘bastardization, extensions to Atom’ - which they’re calling GData.
6. Using GData is encouraged now, as Blogger and Base now can be accessed ONLY via GData. Oh gee, so let me get this straight - eveything is fine and open as long as we use your PROPRIETARY protocols. Hmmmmm.
7. It gets better. The GData protocols include everything - authentication, microcontent, ways of inter-connecting apps together, in other words - ALL the dogma, specifics and meat behind creating an inter-connected meshed web - except - OOOOOOOOOOOOOOOOOOOps - its based upon proprietary Google protocols. And as long as you use THEIR services, you’ll be required to use THEIR protocols.
8. For any young people out there - this is EXACTLY how Microsoft won in the 1980s. How Excel won, how Word won, how the Windows platform came into being. This is called ‘lock-in’. It worked for Microsoft and unless we do something about it, it looks like it’s gonna work for Google.
9. The recent news that Google’s Base would finally be accessible,but ONLY through GData was the closer for me on this strategy. They actually think they can create a quilted fabric of inter-woven apps and services - driven by THEIR proprietary protocols. As Chris points out “where does that leave us”?
The problem that I see is Google’s ability to shut out third party services once you’ve imported yourself into the proverbial gLife. No doubt there are feeds and the aforementioned GData APIs but it’s not an open system; Google decides which ports it wants to open and for whom. Think you’ll ever be able to cross-post calendar items from 30boxes to your Google Calendar? Only if Narendra strikes a deal on your behalf — even though it’s your data. Think you’ll ever be able to share your Picasa Albums with your Flickr account? Don’t bet on it. Or — or — how about sharing your Google search history with your Yahoo account? Or merging your buddy list between Orkut and Flickr? Not a chance.
10. Sounds like a bunch of ex-Microsoft guys went to work for Google. Oh yah, they did.
Chris’ argument is that by deploying authentication with GData, Google can really lock us all in - for good.
But there’s a new trend, seen in Google’s spreading account authentication that foretells of the inevitable Passport-like lock-in that sunk Microsoft the first go ’round. You see, Google’s Account Authentication API makes it easy for you to add more and more of Google services by simply using your Gmail credentials. For Google, this leads to huge network effects, because they can essentially merge behavior data from across its entire network of services to build out a better picture of you — leading to a kind of competitive advantage that no one else can touch.
The moment Dave Winer first heard of GData he says to me “why? Why do we need different data handling protocols - and….” - its their lock-in coming out.
Google would argue that by building a better user mousetrap they’re leveraging their superior cross-product integration via an integrated authentication system. Uh huh - that was called Passport.
We’ve learned from Apple and Microsoft that lock-in strategies only benefit one player. We’ve seen over and over again Microsoft taking some burgeoning standard and twisting it to suit their own means. Apple does it - as well.
What we WANT are scenarios like what’s happening wiht Ma.gnol.icio.us. Here a supposed copycat service (or at least one that’s in the same area) is supporting the first comer’s APIs - which turns those APIs into an ‘open standard’. Magnolicious is utilizing the de.licio.us APIs. So now those delicious APIs are the industry ’standard’ for bookmarking sites. Not need to debate - you start with a harded wired effect and you get out of it - a standard.
That’s what Google should be doing.
You gotta wonder why Google thinks that RSS and XML-RPC aren’t “good enough for them?” Probably the same reason why Blogger has never really supported those protocols. They didn’t invent them.
But Google has been square behind APP (Atom) since its inception - and that strategy is now playing out with an entirely NEW set of data protocols - proprietary to Google. As long as you accept and use those protocols - you can get to Google’s data (which is really our data BTW.) But support open standards - FEH!
I can just see Larry and Sergey flying in their 747 jet over Silicon Vallery - laughing……… each with their $2B in cash stashed away in the bank.
Chris follows up with a clarification to his original post:
Apparently I could have been more clear in my post on the Google Authentication mousetrap, so here’s some additional summary points:
- It’s not so much about lock-in as it is that Google can steamroll over independent competition because of their ability to integrate and cross-promote services. In the first bubble, they called this synergy and it’s not necessarily a bad thing. It’s better for users, but worse for upstart competitors.
- As web apps become the norm, being able to move your data between them will become essential, and since almost all web apps require some form of authentication, you need to be able to share your credentials between these web apps to transfer the data.
- Microsoft Word already runs on OSX and so you already can copy and paste data between it and Appleworks. My point is that that’s not the case on the web today. Because commercial use of APIs are restricted, you have to wait for companies to forge business deals before you get the kind of interop that you already have between different company’s desktop-based applications.
- I feel that my view is squarely looking at reality — looking at what will happen if we don’t open up data formats and authentication protocols. I am placing my hope on microformats and OpenID — not because I care so much about the technology, but because until we have open standards for transferring data and open protocols for authenticating, it’s going to continue to be a disempowering situation for your typical end user. Like me.
And to that I say - right on brother! I agree!
