Open APIs Don’t Equal Open Knowledge

Kragen Sitaker recently posted an essay about the equivalent of free software for online services. Kragen is always interesting and this is no exception. He points out that the movement to use online services rather than local applications greatly increases the possibility for vendor lock-in.

This is Microsoft Office on steroids and I’d guesstimate that the ‘lockin-strength’ of data exceeds that of a user interface (or even an API) by an order of magnitude (compare the effort involved in converting all your documents from Word’s .doc to another format such as Open Document to the effort involved in learning the new interface). As Ross Anderson has repeatedly emphasised the value that a vendor can extract from users is roughly equivalent to the total switching cost. With control of your data that switching cost is going to be much, much higher than with control of the user interface alone.

This focus on data brings me to a related and, in my view, even more important point. Associated with the move to online services there’s been a proliferation of web 2.0yy ‘open’ APIs. While an open API is certainly better than a closed one I think we need to understand clearly the way in which the ‘open’ in ‘open’ API is different to other forms of ‘openness’:

1. The ‘open’ in open API is very narrow. Usually all it means is that the API is publicly documented and that access is free (though even this doesn’t seem to be necessary — quite a few ‘open’ API’s are pay per use)
2. The API cannot be freely changed or adapted by someone other than the service provider
3. There is no guarantee that the API will remain free (as in cost) to use or even that it will remain fully documented
4. Freedom to reuse or redistribute the information you obtain from the API is often limited (e.g. Google/Yahoo/… maps). As a consequence the reuse chain is extremely short (usually just one step).
5. Because the data is not openly available the ability for the community to find bugs, provide ‘patches’ etc is greatly curtailed

Open knowledge consists of three freedoms: the freedom to access, to reuse, and to redistribute. As we’ve just seen an open API however guarantees none of these (at most it attempts to deliver on the first but even here there are various limitations on full ‘open’ access ranging from charging to the imposition of usage quotas). Thus we should always be clear that an ‘open’ API actually delivers very little ‘openness’ and the distance that separates ‘open knowledge’ from the ‘knowledge’ behind an ‘open’ API is very large indeed.

Related posts:

1. The Four Principles of (Open) Knowledge Development [Further discussion and elucidation of the ideas in this piece can be found in the follow-up: What Do We Mean by Componentization (for Knowledge)?] Introduction Open knowledge means porting much more of the open source stack than just the idea...
2. Knowledge Packaging (for Content) Late in the afternoon at the Free Culture UK meetup back in April there was a discussion of the analogy between code and content in relation to open production models. This came up as an aside to the main discussion...
3. Dead knowledge: why being explicit about openness matters When I think of the amount of knowledge that is ‘dead’ because of a lack of explicitness about its ‘openness’ I am always surprised by the number of examples. Consider the following two: Example 1: Everything2 and h2g2 Years ago,...