Fork me on GitHub

One topic that drives a lot of pageviews and discussions on a blog post, is sunsetting or deprecation of an API. I’ve written a lot about this with APIs Are Forever, Wait No...They Can Go Away at Any Time!!! and Building Your Business Around Google or Any Other APIs.

I wanted to write another post on this, in hopes of understanding it a little more and generating discussion, and of course be somewhat of a pageview whore.

When it comes to deprecating an API, from the perspective of the API owner, what can they do to alleviate the pain of the API going away:

  • Never Deprecate an API - Support the grandchildren of your current developers, creating an API dynasty.
  • Deprecation Policy or SLA - Set expectations with developers through a deprecation policy, and service level agreements (SLA)

From the perspective of an industry or API developer community:

I don’t think we can count on API owners never deprecating an API or always having SLA and depreciation policies, and I’m not sure if API standards or unified APIs will win out. So my suggestion is encouraging API owners to open source their API upon deprecation.

Open sourcing a deprecated API, would allow anyone to step in, and run with the API either taking in a new direction and / or supporting the existing customer base and opportunity. One example of this was when LinkedIn acquired IndexTank, then open-sourced the core technology enabling other companies to step in and support existing API developers and take advantage of the indexing technology.

Even beyond supporting existing API developers, open sourcing a deprecated API would establish an “open” precedent for a technology, and even upon the demise of its parent company, would prevent copyright and patent trolls from buying up legacy companies, only with the goal of stifling innovation.

So consider adding an open-source clause to your API deprecation policy.




comments powered by Disqus