Yesterday Dave Winer wrote in a post about cloning the Google API Dave Winer wrote

Let's make the Google API an open standard. Back in 2002, Google took a bold first step to enable open architecture search engines, by creating an API that allowed developers to build applications on top of their search engine. However, there were severe limits on the capacity of these applications. So we got a good demo of what might be, now three years later, it's time for the real thing.

and earlier that
If you didn't get a chance to hear yesterday's podcast, it recommends that Microsoft clone the Google API for search, without the keys, and without the limits. When a developer's application generates a lot of traffic, buy him a plane ticket and dinner, and ask how you both can make some money off their excellent booming application of search. This is something Google can't do, because search is their cash cow. That's why Microsoft should do it. And so should Yahoo. Also, there's no doubt Google will be competing with Apple soon, so they should be also thinking about ways to devalue Google's advantage.

This doesn't seem like a great idea to me for a wide variety of reasons but first, let's start with a history lesson before I tackle this specific issue

A Trip Down Memory Lane
This history lesson used to be is in a post entitled The Tragedy of the API by Evan Williams but seems to be gone now. Anyway, back in the early days of  blogging the folks at Pyra [which eventually got bought by Google] created the Blogger API  for their service. Since Blogspot/Blogger was a popular service, a the number of applications that used the API quickly grew. At this point Dave Winer decided that since the Blogger API was so popular he should implement it in his weblogging tools but then he decided that he didn't like some aspects of it such as application keys (sound familiar?) and did without them in his version of the API. Dave Winer's version of the Blogger API became the MetaWeblog API. These APIs became de facto standards and a number of other weblogging applications implemented them.

After a while, the folks at Pyra decided that their API needed to evolve due to various flaws in its design. As Diego Doval put it in his post a review of blogging APIs, The Blogger API is a joke, and a bad one at that. This lead to the creation of the Blogger API 2.0. At this point a heated debate erupted online where Dave Winer berated the Blogger folks for deviating from an industry standard. The irony of flaming a company for coming up with a v2 of their own API seemed to be lost on many of the people who participated in the debate. Eventually the Blogger API 2.0 went nowhere. 

Today the blogging API world is a few de facto standards based on a hacky API created by a startup a few years ago, a number of site specific APIs (LiveJournal API, MovableType API, etc) and a number of inconsistently implemented versions of the Atom API.

On Cloning the Google Search API
To me the most salient point in the hijacking of the Blogger API from Pyra is that it didn't change the popularity of their service or even make Radio Userland (Dave Winer's product) catch up to them in popularity. This is important to note since this is Dave Winer's key argument for Microsoft cloning the Google API. 

Off the top of my head, here are my top three technical reasons for Microsoft to ignore the calls to clone the Google Search APIs

  1. Difference in Feature Set:  The features exposed by the API do not run the entire gamut of features that other search engines may want to expose. Thus even if you implement something that looks a lot like the Google API, you'd have to extend it to add the functionality that it doesn't provide. For example, compare the features provided by the Google API to the features provided by the Yahoo! search API. I can count about half a dozen features in the Yahoo! API that aren't in the Google API.

  2. Difference in Technology Choice: The Google API uses SOAP. This to me is a phenomenally bad technical decision because it raises the bar to performing a basic operation (data retrieval) by using a complex technology.  I much prefer Yahoo!'s approach of providing a RESTful API and MSN Windows Live Search's approach of providing RSS search feeds and a SOAP API for the folks who need such overkill.

  3. Unreasonable Demands: A number of Dave Winer's demands seem contradictory. He asks companies to not require application keys but then advises them to contact application developers who've built high traffic applications about revenue sharing. Exactly how are these applications to be identified without some sort of application ID?  As for removing the limits on the services? I guess Dave is ignoring the fact that providing services costs money, which I seem to remember is why he sold weblogs.com to Verisign for a few million dollars. I do agree that some of the limits on existing search APIs aren't terribly useful. The Google API limit of 1000 queries a day seems to guarantee that you won't be able to power a popular application with the service.
  4. Lack of Innovation: Copying Google sucks.


 

Thursday, 03 November 2005 16:08:48 (GMT Standard Time, UTC+00:00)
Dare:
Wouldnt it be nice that MS or Yahoo add their own specific functionality in the API's apart from having all of the Google functionality. It sounds that MS is still cloning Google but thats how softwares are developed. There is an unpatented idea and there are improvements to that idea. Call MS's API as an improvement over Google API
Pronob
Thursday, 03 November 2005 16:33:25 (GMT Standard Time, UTC+00:00)
The REST-like apis and RSS feeds are particularly useful for Javascript developers. Constructing a SOAP envelope in JS is just cumbersome.
Thursday, 03 November 2005 16:45:29 (GMT Standard Time, UTC+00:00)
Copying sucks, but when the market leader has something like 90% of the market there's very little choice you have. I'm sure the Firefox and OO guys feel the same way ;-) ... I'm not very happy about the 'clone the google api' meme myself, but I dare say MSN Search could clone some _interface_ ideas from Google instead of their API.

Just like Excel supported 123 /-commands and IE and Word went out of their way to support Navigator and Wordperfect users, I'd like to see MSN Search make switching from Google easy. Things like:

* search term highlighting (the lack of this makes MSN Search results an order of magnitude more difficult to scan). In fact, MSN could take a hard look at its result pages vs Google's -- Google's emerges as much more readable, beats me why MSN haven't wised up.

* operator compatibility with Google, so that diehard Googlers who use ~ and numranges give MSN a try

* (Important) a 'Try your search on Google' link on its search pages, so that new users can try out MSN Search with the reassurance that Google is never more than one click away.

* A fast-loading home page with a short, easy to type/say name (search.msn.com or msnsearch.com don't qualify, live.com would but its not only about search)
Thursday, 03 November 2005 16:56:10 (GMT Standard Time, UTC+00:00)
Dare, nice story, but not the truth.

I jumped on the Blogger API and supported it as soonas it was announced, not after it was successful. I dare say my support may have had somethign to do with its being successful. (I would have implemented it the same day it came out but I was on a rare vacation when it was announced.)

And I always said we would put in an appkey if Evan would support the MetaWeblog API. So that wasn't the issue, even though that's what he *said* the issue was (and you repeat it here).

Further, I didn't flame them for creating a new incompatible API, but I did disagree. I guess in your world everyone has to agree with everyone else?

That's where I stopped reading Dare. This is a fictional account. The archives are all on the web, there's no excuse for making this stuff up, and smearing people's reps. If you don't want to compete with Google, fine, you have a lot of company at MSN. But don't make it personal, and don't lie about it. Not cool.
Thursday, 03 November 2005 19:09:41 (GMT Standard Time, UTC+00:00)
Prasenjeet,
That is all good feedback and I've passed it along to the Search guys on our side. With regards to short domain names, I believe that was the point behind live.com. Why don't you like it?
Thursday, 03 November 2005 19:17:27 (GMT Standard Time, UTC+00:00)
Amen Dare, especially number 4.

The archives are indeed on the Web, including Evan William's "Tragedy" post:

http://web.archive.org/web/20041011135623/http://www.evhead.com/archives/2003_05_10_archive_default.asp
Thursday, 03 November 2005 19:29:27 (GMT Standard Time, UTC+00:00)
Danny,
Thanks for the link.

Dave,
My words match my recollection of the events. Folks can read Evan's post from two years ago and draw their own conclusions. If they decide I'm lying, so be it.
Friday, 04 November 2005 03:09:13 (GMT Standard Time, UTC+00:00)
Your recollection is wrong Dare. And so is your logic.
Friday, 04 November 2005 11:10:21 (GMT Standard Time, UTC+00:00)
live.com's current form is nice from a portal/services POV, but it's not about search. For example, hit live.com on a not-very-fast connection and what you get _first_ is a search box with no caret, so you can't type anything in. You've got to twiddle your thumbs while the rest of the UI loads before you can search. Compare that with typing google Ctrl+Enter.

I'm sure some HTML hackery can fix this specific problem, but I'm guessing most people go to google.com instead of yahoo.com or msn.com (which is actually easier to type) simply because google.com doesn't distract them from what they're trying to look for.

Of course, I do realize what Google does with their homepage is hard to do when you're not solely a search company.
Friday, 04 November 2005 13:07:13 (GMT Standard Time, UTC+00:00)
I agreed with your article up to the point where you said "The Google API uses SOAP. This to me is a phenomenally bad technical decision". What???

Ok, so javascript and maybe php developers should be given A REST alternative, but I for one ONLY want to work with a SOAP API...extremely simple to use if your development tools support them...and most of the "big" ones do. For a company doing a lot of web-service development, SOAP is the answer and Google, like they have done on almost everything else, have nailed this one as well.

MSN offers SOAP, and Yahoo and anyone else who wants to play in the real SOA world should be offering SOAP services.

Mike
Comments are closed.