Better mousetrap or a new form of lock-in?
An important issue of “what the hell is Google’s strategy” is starting to unfold.
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!
August 24th, 2006 at 6:28 am
I’m not an API expert, but wasn’t Microsoft bad because they wouldn’t share their APIs with anybody? And as far as I know Google is sharing their APIs but making them up as they go. So, Google is trying to lock us in by making everybody want to use Google’s “Open” APIs. Anybody can develop with those APIs and the documentation is provided for them.
Am I wrong about that? If that is really the situation, and I may very well be wrong, then it seems that Google is trying to get the world to use their APIs, not necessarily lock them into their products like Microsoft tries.
Now whether delicious’ open APIs or Google’s open APIs are better is a topic for a different discussion.
August 24th, 2006 at 6:33 am
Marc, i have some hope for the opening up of Google’s auth:
http://factoryjoe.com/blog/2006/08/22/follow-up-on-the-mousetrap/#comment-14645
August 24th, 2006 at 6:44 am
Calling GData proprietary is a bit disingenious when it is just APP with custom namespaces. Granted, they should have reused more of the existing RSS namespaces (events and georss come to mind), but APP itself, as well as Atom *are* open standards, unless I am missing something? At the same time, it is disingenious of them to call it GData when it really is APP.
They are at a crossroads, for sure: They can take what they have, and add open authentication, and thus allow others to play, or they can play the old lock-in game. History would suggest approach two, my link above has some evidence for approach one.
August 24th, 2006 at 7:14 am
[…] Marc Canter notes what we’ve also been noting. Google’s development strategy looks more and more like the one that got Microsoft in so much trouble in the 90s. We gave them perfectly good ways of moving data around, so developers could use any company’s infrastructure. Google reinvents it so you can only use theirs. I recommend going some other way, for now. And Google, we want to ride up front, with you, not locked in the trunk, with uncertain air supply. […]
August 24th, 2006 at 8:51 am
Sorry Marc, you might be right about your conclusions - where Google is heading - but you’re wrong in a lot of your details. There are two aspects to this, Google’s “space”, and the protocols with which developers/users interact with that space.
With the apparent exception of identification and authentication, their approach to protocols has been remarkably good. RSS 2.0 and the XML-RPC based APIs (including the original Blogger API) have well-known flaws. The Atom format and protocol come from a community effort to fix those flaws. GData is an extension of Atom, but arguably it’s a reasonable extension given the nature of Google’s stores. To provide the same capabilities similar, almost certainly more extreme, extensions would have been needed from RSS and existing XML-RPC APIs.
There’s little doubt Google are trying to control the horizontal and the vertical of the web in the same way Microsoft did on the desktop. What is in question is the basic access and ownership of the data and services in their space. Any lock-in relates to their identification and access policies. That’s got very little to do with the protocols they use for shifting data around.
Your quote from Dave Winer is quite funny under the circumstances: “Why do we need different data handling protocols”. RSS is delivered directly over HTTP, XML-RPC is tunnelled procedure calls, i.e. Winer promotes two totally different paradigms for data interchange…
XML-RPC is reinvention of the facilities already offered by HTTP (in the RPC paradigm on top of HTTP). Ok, at the time it came out it did seem like a good idea, but developments since then have demonstrated it really is a clunky way of doing intersystem communication, and it’s inherently not very web-friendly because it demands applications are tightly coupled. By contrast, the Atom protocol uses a simpler, more loosely-coupled approach throughout.
Your point about standardisation from existing practices is well made, but times change. ASCII was *the* format for text, but it had significant failings. Should we have stuck with ASCII as the standard, irrespective of the needs of the non-US community?
So although I agree entirely there is a lot of danger in what Google is doing, I think your argument is weakened significantly by the red herring of their choice of protocol.
August 24th, 2006 at 9:59 am
Aren’t RSS 2.0 and XML-RPC proprietary formats?
August 24th, 2006 at 10:00 am
[…] Share this post: Email it! | bookmark it! | digg it! | reddit! Posted: Thursday, August 24, 2006 6:58 PM by Jesse Ezell Filed under: General SoftwareDevelopment, Google, GData, Proprietary Protocols […]
August 24th, 2006 at 10:17 am
Dugg… http://digg.com/tech_news/Google_Masterplan_Unfolds
August 24th, 2006 at 10:22 am
[…] Marc Canter has an interesting post where he talks about houw Google is building a moustrap and trying to force its programming model on developers(kinda). […]
August 24th, 2006 at 10:46 am
The important issue is not the APIs but the T&Cs. Can we use and copy the APIs in commercial offerings without getting a license from Google? If we can then their APIs are just a basis to build on. If we can’t then it’s lock in.
So what happens when I use Google’s Maps ability to geocode an arbitrary address into Lat/Long? Yup, I get bitch-slapped. Then they produce a Geocoder service but it doesn’t include the UK. I know that issue’s only partly about APIs. But it highlights the problem. And the solution, which is don’t use protocols and APIs with onerous T&Cs.
August 24th, 2006 at 10:58 am
[…] Lots of ruminating over whether Google is attempting a Lock-In, 2.0 strategy and the (de)merits of lock-in in general. Chris started the party off with a long broadside against Google’s ability to create a one-sided context through its expanding user authentication system. Marc then piles on by pointing to specific data protocol choices Google has made (though Danny Ayer seems to slap those arguments down a bit.) […]
August 24th, 2006 at 11:02 am
Don’t neglect the future role of Google Payments in all this, either. Why didn’t they just interface to PayPal, which has open APIs and which integrates easily into all sorts of web services? Well okay payments is a place to make money, but I wonder after reading this litany if that was the only reason. Perhaps another proprietary Google-only protocol, coming up?
August 24th, 2006 at 12:07 pm
[…] 5. Ole Euchorn points out how important this all is - when you look at something like Google payments. How come they can’t support PayPal. Well we all know why - right? […]
August 24th, 2006 at 12:28 pm
Google Payments didn’t interface with Paypal because Google pay was supposed to be a replacement for paypal. It was supposed to fix things people don’t like with paypal especially concerning fraud. Google I find makes their own way of doing things, and for the most part they do things better.
As far as geocoding goes, Google is an american company and everything is based in america. Stuff will get to the UK eventually, like more data for all of the UK was added to google maps. If Google gave everyone the ability to make their API’s as good as the google.local maps, everyone would create their own maps site and no one would use Google Maps anymore. I like how they give you the ability to use their maps and their API’s and you can tie in all sorts of other things php,flash etc to make them better.
August 24th, 2006 at 1:22 pm
VonKraut, you’re missing the point. And you have an admirably American-centric view.
- Google release Google maps
- They release an API for Google maps with T&Cs that are a problem for commercial and intranet use
- I work out how to scrape their pages and use their geocoding ability to present a REST based Geocoder.
- Google send me the Cease and Desist. Fair enough, I was breaking their T&Cs
- Google release their own Geocoder service for the USA, much of Europe and a few other countries round the world but not the UK. Because the data for the UK is owned and licensed by somebody else. Largely the UK Ordnance Survey and Post Office.
That was the second time I’ve had this run in with them. I also wrote code to turn Google News Search into RSS. The problem with that one that resulted in another Cease and Desist was somebody else using my web service to republish Google News text on their website. Again, I’d broken the T&Cs, so fair enough.
So what’s the problem here? Not Lat/Long standards, Marc, or the quality of the Maps data, VonKraut. The problem is the T&Cs around the data and your use of the API. There really is nothing wrong with Google creating a new “Standard” and perhaps this “Standard” becoming de facto, THE “Standard”. In fact, I welcome it. And if they succeed in doing ID, Single Signon and Authentication better than Passport, I’ll welcome that as well. Just as long as I’m not prevented from extending their standard, using their standard elsewhere, being able to get at what I think of as my data, and being able to repurpose that data elsewhere without asking Google and getting permission first.
I’ll try and say it one more time. If the T&Cs are open and don’t have undue restrictions, I don’t care if the standards aren’t open.
Of course it would be nice if they actually listened to criticism of the developing code as well. Sometimes they do, sometimes they don’t.
August 24th, 2006 at 1:36 pm
[…] Marc Canter lays out how Google is “locking in” developers more every day. But, what I find interesting is the lack of conversation from Google itself, particularly senior strategists. Where’s MarkL??? That’ll end up being what bites Google in the behind in the end game (does anyone notice they aren’t getting quick adoption outside of search and email? This lack of attention to influencers is the reason. They should have learned that from Microsoft’s Hailstorm experience. The kinds of things that Google is trying to do are massive — and scary, if we don’t trust Google anymore, and developers tell me they are headed toward believing Google is the new Microsoft). […]
August 24th, 2006 at 2:54 pm
You’re missing out on one thing.
GData is open. It’s not an “open standard” necessarily, but all documentation on how to interface with it is totally open. And anyone would be free to build something else that could use it.
August 24th, 2006 at 4:02 pm
Mike, I don’t think Microsoft refuses to share APIs. msdn.com has a wealth of apis. Passport was an shared API (or protocol/system, or whatever) that was available for any site to use. For various reasons it failed to achieve MIcrosoft’s vision, so it ended up being just use for Microsoft’s own web services (although I think it’s still open for others to use, but nobody does).
MS did refuse to share their ActiveDirectory protocol (the EU case), but that was always meant as an internal protocol for WIndows networks, and isn’t really the same thing as Passport, GData, or Windows APIs like Win32, .NET, COM, DirectX, et al.
August 24th, 2006 at 11:21 pm
Brutus, the Passport protocol was never open. And the Passport API was only ever available as a working system using Microsoft technology. Which meant that the entire LAMP world of websites were locked out from using it. And, Passport was licensed and access to the API was controlled so that only the largest sites could use it. Microsoft locked out the lower end of websites even if they were hosted on MS technology. No surprise then that it didn’t take off and ended up being used only by MS Properties.
Which brings us back to Google’s Authentication. Will they be inclusive and let anyone use it and use a technology that anyone can use? Will they allow anyone to build their own Identity provider using the same protocol and API. Or like Passport will it be hemmed in by restrictions (both legal and technical) that mean it ends up being used on Google properties only?
Marc, you’re going to have to turn off trackback…
August 25th, 2006 at 12:25 am
[…] Marc Canter notes what we’ve also been noting. Google’s development strategy looks more and more like the one that got Microsoft in so much trouble in the 90s. We gave them perfectly good ways of moving data around, so developers could use any company’s infrastructure. Google reinvents it so you can only use theirs. I recommend going some other way, for now. And Google, we want to ride up front, with you, not locked in the trunk, with uncertain air supply. […]
August 25th, 2006 at 12:30 am
[…] Marc Canter notes what we’ve also been noting. Google’s development strategy looks more and more like the one that got Microsoft in so much trouble in the 90s. We gave them perfectly good ways of moving data around, so developers could use any company’s infrastructure. Google reinvents it so you can only use theirs. I recommend going some other way, for now. And Google, we want to ride up front, with you, not locked in the trunk, with uncertain air supply. […]
August 25th, 2006 at 11:02 pm
No, GData is not a closed api. It’s an open specification. And Google releases a hell of a lot of code back to the open-source community. Microsoft does not pay people just to work on open-source; Google is the primary cash-cow behind Mozilla/Firefox, paying most of the money to develop it. Lkewise, it employs Guido von Rossum, paying him, and allowing him to spend 50% of his time doing python! Which Microsoft employee is alowed to spend HALF their time wokring on their pet project?
September 10th, 2006 at 5:38 pm
jonny
December 5th, 2006 at 6:22 pm
Greetings%21..d
December 8th, 2006 at 2:09 am
%
December 8th, 2006 at 3:06 am
Hi all!
Impressive webpage[url=http://christmas-gifts.nessne.org]![/url] I like it a lot! I’m looking forward to the next update
G’night
December 8th, 2006 at 9:44 pm
I you all love!e
December 9th, 2006 at 11:08 am
Hi, good morning to all of you… Nice Guestbook
!!!u
December 12th, 2006 at 4:43 pm
Fascinating site and well worth the visit. I will be backv