‘Open API’ is a well-known term that seldom gets challenged. It passes in conversation as an agreed-upon good. However, it should be recognised that there is no such thing as an Open API – the term is a euphemism for a specific kind of technical service offered with no contractual agreement to secure those services.
‘Open API’ trades off the term ‘open’ to imply some kind of transparency – which often is missing on both technical and business levels. Badly documented APIs with no guarantee of service are usually what you will be dealing with. To rely on an Open API is to lack transparency – it is doing business by relying on the kindness of strangers (as Blanche DuBois would say).
In other words, the Web 2.0 economy encourages us to utilise third-party services with no contractual agreements in place for these critical, and sometimes core, business processes.
This week there was a very interesting case in point. Lulu.com announced they are discontinuing support for their publishing API. In an email sent out early in the week, clients were informed:
We’d like to thank you for your participation in the Lulu API Program and share an important update. Over the last two years, we have made significant investments into building our APIs and making them useful to third-party developers, however they have not achieved the adoption which we had anticipated and we will no longer be supporting APIs.
We will discontinue support of our existing APIs on January 15th, 2013.
The Lulu API was, by the way, a very good API and very well documented. However, the above means that if you relied on the Lulu API for your business, then bad luck, you better find another way to do it.
Lulu, of course, is subject to its own business processes and they have obviously invested a lot in the development of an API for little return. Their approach has been very straightforward and they communicated to their clients well in advance that there was going to be a change in their API service. As far as things go, Lulu has done it pretty much by the book, however, my point is addressed to a wider concern: API providers should offer their clients a contract which guarantees the terms and conditions of technical services provided by their APIs. Without this contract, businesses are not in a position (and should not be tempted) to confidently build innovative models that leverage the powerful possibilities that these APIs can offer.
Originally posted on O’Reilly, 13 November 2012 http://toc.oreilly.com/2012/11/open-api-the-blanche-dubois-economy.html
