‘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 – it 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 there is often not on either a technical or business level. Badly documented APIs with no guarantee of service is usually what you are dealing with. To rely on an ‘Open API’ is not to have transparency; it is to do 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 will discontinue the 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 is 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 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.