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.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

  • There is no easy answer to this. I think any API ecosystem is a constant battle between the interests of the API owners, partners, and the open developer community. They are all dependent on each other. API owners have to engage developers constantly and discuss the roadmap, how to evolve partnerships, what tools and resources are needed.

    API owners also need to constant look beyond their ecosystems and watch what other players are doing, competitors, and other industries.

    With some APIs developers will be able to just pick up and go elsewhere when things break or get hostile. Other APIs, this isn’t an option and there will constant battles to define the ecosystem, and how everyone makes money.

    This is all the beauty of the API economy.

  • This is a where commerce and utalitarianism collide….

    We’ve talked about this before, Cloud computings future is already mapped out… just look at history of any utility business … i’m not happy about it either

  • This tension between developers consuming APIs and building applications (and in many cases businesses) around open platforms predates the dotcom boom of 1995. Be it the latest examples of Twitter pulling back on new acceptable terms of use for their API in 2011 or Apple dictating 3.3.1 to developers in 2010, or even back to Skype Developers Program “eating their young” in 2005, or Apple “being a lousy lover” to developers in 1994, the key is to make sure no one party in the ecosystem — API developer or API provider or App consumer — is extracting all the value out of the ecosystem.

    If your company launches an open API platform, developers are a smart, opinionated, entrepreneurial new set of customers. They can provide product agility, innovation, velocity, and device/channel distribution.

    In exchange for this value from developers, API providers need to provide a generous Terms of Service, commercial opportunity, and services that are easy to get started with and a pleasure to use.

    Too many API providers only think of the API ecosystem merely as a means to extract value for their business. But developers are quick to move to new opportunities for value. With more than 3000 APIs available on ProgrammableWeb, developers have lots of options. It may be “developer beware” today as Sam so beautifully states, but history is long. Lousy lovers of developers in 1994 learn from their mistakes and win developer hearts and minds today. As long as the business model and market opportunity are healthy enough to provide value for the entire ecosystem, then API consumers and API providers will continue partnering in order to create value. Just as lovers inevitably quarrel, the successful long-term partnerships always find a way to kiss and make up.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.