One of my self-appointed roles in the API industry is to shed light on, and discuss the business of APIs when many other API owners and evangelists tend to keep their strategy and business closer to their chest.
Many API owners don’t discuss their roadmaps, either because they feel they will be giving away their secret sauce, or quite possibly because they don’t have a clue where they are going with it. I think it’s more the latter, as we are all making this shit up as we go along.
One subject you don’t hear API owners discuss often, is when their API will be deprecated or shuttered, leaving developers and tech bloggers to speculate on the subject. Because of this you tend to hear just the extreme views on the subject. Popular perspectives on API life-span tends to be:
- APIs Are Forever - Once you put an API, you have to support it forever
- APIs Can Go Away Anytime - There is no stability whatsoever when it comes to APIs
I’ve written on this subject several times including What Happens to Instagram API Developers After Facebook Acquisition and Building Your Business Around Google or Any Other APIs.
Even with my stance on the subject I fall prey to the hype sometimes. I saw the post from Google today called Changes to deprecation policies and API spring cleaning, and I immediately thought oh no, here we go again. After reading deeper I realized they are updating their API deprecation policy for many popular APIs. As they state:
The new policy simply states that we will strive to provide one year notice before making breaking changes.
Google is setting a clear window, for which they will make sure and give developers a heads up before deprecating an API. This allows you to know that you can count on an API being around, until you hear otherwise, and then, you still have a year to figure out what you are going to do.
I know this is something other API owners do, but it rarely is something you hear any news about, giving the API extremists free range to use page view grabbing headlines about APIs owners being no better than satan, and eat their developers for dinner.
I’m going to work on a more formal post about API deprecation policies, and how API owners can put them to use, setting better expectations around API life cycles.
