I spend a lot of time talking about the amazing value that connected applications can bring. The thing that powers this value is the humble API – the little widget that sits between disparate applications and allows them to make magic. But all is not happy in API land, GigaOm told the story recently of Lendle, an eBook sharing service that had it’s access to the Amazon API blocked, thus removing it’s lifeblood. Ouch… indeed..
Basically Amazon shut down access to the API with zero warning. A similar situation that UberMedia suffered, this time at the hands of Twitter. In the GigaOm article, Matthew Ingram uses these examples to send a warning to developers;
Building your service on top of someone else’s API, no matter how “open” the API is supposed to be, is a very dangerous road
I love the concept of what an API can unlock – both functionally and from a business perspective – my friends at Apigee and Alcatel-Lucent are trying to build businesses based on the concept of marketing an API, or enabling an API economy to flourish. Stories like that of Lendle put that at risk. Sam Ramji, VP Strategy at Apigee addressed the previously discussed issues around the Twitter API in a post, also published on GigaOm. in his post he advised caveat structor or developer beware. In his post re rightly stated that;
What you need to plan for as a developer is that an API dependency is not the same as a dependency on a library. You’re depending on a service that can change, grow, shrink, or cease to exist. As a developer, if you don’t have a plan for this, you should. You’re getting tremendously more functionality than we ever got out of libraries – an entire service, with data, updates, users, and scalability that you don’t have to pay for. It makes sense that the risks are also larger and must be managed.
Which I entirely agree with but coming from a vendor that is trying to build a business out of enabling APIs, there’s certainly something missing here. I reached out to Alcatel Lucent, another organization that is trying to build a commercial model around API enablement. Laura Merling, SVP for Alcatel-Lucent’s Application Enablement Platform and Strategy rightly pointed out that;
…developer programs take a lot of time, money and resources – at some point the cost exceeds the value. At the Evans Data Conference today, IBM said they have 150 full-time people working on their developer program. That is what they do for a living. For most API providers, the API is a means to the end, not the end itself… Developers are valuable, but also costly if it’s not your core business
All good stuff, but again if I were a developer building tools atop an API, I’d be nervous at this talk, especially since this comes from someone enabling the very API economy to flourish. By way of moderating the response, Merling did add that;
..closing down a developer program when people have running businesses and not providing notice is just bad business practice. Communicating and giving substantial time for people to find other routes makes sense if the program needs to change
After talking to both Ramji and Merling, I was surprised that the API vendors didn’t have a really clear, concise answer to the concerns. This situation spurned me into diving into the issue further and so I’m stoked to announce that I’ll be moderating a session in a couple of weeks with both Ramji and Merling. The session, entitled “The API Economy, Building Value Through Open, and Securing That Value” is being hosted by Focus.com – you can sign up here.
I’d love to have feedback in terms of questions you’d like to see raised to these two – feel free to send me your thoughts in the comments below.