Clone the Google APIs: Kill That Noise: "
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 in 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
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 such overkill.
- 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.
Lack of Innovation: Copying Google sucks.
(Via Dare Obasanjo aka Carnage4Life.)