Google yanks APIs, developers caught with pants around ankles

Thinking of the intertubes like a programmer

In 21st century Intertubelandia, everything's connected to everything else. From the perspective of a web-oriented or mobile-oriented software developer, that often means that some part of what gives value to the software one builds is the available and accessible software that someone else is running elsewhere in Intertubelandia.

Examples on the web: If you've ever visited a web site that offers the option to click a button that translates the page into another language -- perhaps one you can understand more easily -- you're likely seeing a link to the Google Translate web element. If you've set up a iGoogle or a My Yahoo! page, and populated it with widgets that show you the weather in your city, or a scrolling feed of what your Facebook pals are up to, or the latest news from the New York Times or CNN, you're taking advantage of services being run someplace other than the company or organization whose URL you're visiting.

Examples on mobile devices: If you own or have test-driven an Android-platform mobile phone, or an iPhone, or an iPad, and have fiddled with apps that allow you to discover what movies are playing nearby, or to check in on foursquare, or to tweet, or to update your Facebook status, or to check stock market prices -- you've taken advantage of somebody's server running someplace, somewhere, that's communicating with an app on your device.

How does all this technomagic work?

The devil's in the details, but the short answer is via exchange of data through a set of consistent patterns of request and response that programmers call an API -- an application programming interface.

When a programmer creates software that relies on somebody else's service being available and accessible, she strongly prefers that the relied-upon service be stable.

Stable means that the API -- the patterns by which data is exchanged -- won't change radically or frequently, so she won't have to rewrite her software over and over again. Stable also means that the service will continue to be available, so that her software continues to work.


When reliable services prove unreliable

There are a lot of programmers out there in Intertubelandia who count on Google services to remain stable. On its face this seems like a reasonable expectation. Google is a very large company. They employ a lot of talented engineers, and their server farms are ginormous. They are as popular, powerful, and highly-valued as they are in large part because their stuff works consistently and is pretty much always there (except when it breaks, as things do).

Caught up in its ubiquity, it's easy to forget that Google has its own agenda. And that having an agenda means that the company might shift directions for reasons that aren't obvious, or at times that aren't predictable.

Like last Thursday.

Google announced on the Google Code blog this past Thursday afternoon that they'd be doing Spring cleaning for some of our APIs. Here's a pullout quote:

[...] some of our older APIs have been superseded by bigger and better things and others may not be receiving the necessary love. As the web evolves and priorities change, we sometimes deprecate APIs – that is, remove them from active development – to free up resources and concentrate on moving forward. Today we're announcing a spring cleaning for some of our APIs.

The blog post's author was Adam Feldman, Google's product manager for the company's APIs. He went on to list twenty APIs that Google would deprecate, including a number that will be shut down later this year -- not just "remove[d ...] from active development," but killed outright.

Some of the APIs that are being shut down are pretty popular. That is, a lot of developers have relied on those APIs to make their own software interesting or valuable. These software developers are confronted with two choices. They can find another way to obtain the functionality offered by the marked-for-death Google APIs, or they can give up on their obsolete software.

Oh well. "As the web evolves and priorities change..." (Or, as some might translate, "When our business model changes, without regard to yours...")


How developers are taking the news

How are developers taking Google's news of last week? It's a mix. There's a juicy string of comments on the Spring cleaning for some of our APIs blog post. They range from pissed off to disappointed to restrained to disgusted to pleading. Here are a few examples:

idndomains: "I guess A LOT of webservices will be hurt. Your new APIs are either pure bullsh[*]t or specially aimed to promote your own affiliates."

Franz Enzenhofer: "i have a question: why should any developer, any company which wants to build a valuable product for the long term use any of your APIs ever again?"

elmar: "I'd also like to voice my disappointment with the shutdown of the Translate API. It was a really cool tool for experiments in the language learning space."

Paul Dixon: "This news makes me sick."

Shortseller: "This is a pity. Is there any option to let the translate api live on a paid basis?"

Alexu: "Charge for Translate API, don't shut it down!"

In a very odd coincidence, on the very day it was announced, I discovered the Translate API was going bye-by as I wrote a blog post for Project Bamboo, in which I am involved through my job at UC Berkeley. My post announced a service that a colleague has just made available. That service relies on the very same Google Translate API that is now deprecated and set to shut down in December. Though we announced our service to project colleagues on the day Google Translate was slated for the dust-bin of intertube history, we're fortunate that our service is meant only as an example and an experiment -- a pattern for other services our project is slated to produce. We only needed Google Translate as an example of a remote service that our services can call. There's not a lot we invested in hooking up to Google, and by the time the Translate API goes away we won't need it anymore.

But.

The larger lesson is clear: you can't count on 'free' or 'experimental' services. If you do, you're going to be disappointed or worse.


Is it really Google's fault?

Did Google do wrong in deciding to shut down some of its APIs? I don't think so. Harm, perhaps, but not wrong.

The thing is, there's nothing surprising about Google deciding to shuffle its portfolio of service offerings. They never promised otherwise. They're a for-profit company -- with shareholders, even. What else could anyone reasonably expect? The company exists to make money.

One commenter on the 'spring cleaning' blog post noted, "It doesn't seem like Google is being honest regarding the reason for shutting down these APIs" (Amos Benninga). I'd have to agree. "As the web evolves and priorities change..." ... I mean, puh-leeze. On the other hand, that's not surprising either.

"Don't be evil"? Remember those three famous words? Wikipedia calls them "the informal corporate motto (or slogan) of Google, originally suggested by Google employees Paul Buchheit and Amit Patel at a meeting." The key word there is "informal." Google's "philosophy" states something a little bit different: "You can make money without doing evil." The key word there is "can."

It's silly to expect a for-profit company to continue to offer a service just because you like it or want it or even need it.

Software developers, beware.



Related posts on One Finger Typing:

Breaking technology: Google's Blogger outage
Moving one's life to the cloud
Safeguarding cloud ephemera Part I: the big picture
Safeguarding cloud ephemera Part II: keeping your blog alive




Thanks to Adam Crowe for his copy of "The shape of the online universe," an image available on Flickr and credited to the Lanet-vi program of I. Alvarez-Hamelin et al., via: www.technologyreview.com/Infotech/18944/