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
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
Pyra is that it didn't change the popularity of their service or even
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
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.
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
- 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
Lack of Innovation: Copying Google sucks.