Open APIs Don’t Equal Open Knowledge
September 4th, 2006
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’:
- 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)
- The API cannot be freely changed or adapted by someone other than the service provider
- There is no guarantee that the API will remain free (as in cost) to use or even that it will remain fully documented
- 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).
- 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.
September 5th, 2006 at 1:09 am
[...] Chris Messina considers Gdata, particularly its API, which appears to be Atom with some extensions, and Blogger’s adoption of this Gdata API, Tim O’Rielly takes up the issue in reference to Chris’s article, making the observation that “a platform beats an application” (which the history of the web demonstrates pretty well - it’s seen off eWorld, MSN, Compuserve, AOL - by which I mean all the proprietary web competitors that emerged in the early 1990s, some of which have morphed into ISPs or portals) while today, over at the Open Knowledge Foundation blog Rufus Pollock observes “open apis don’t equal open knowledge”. Rufus refers to a recent article by Kragen Sitaker, on the implications of software as a service for users, also well worth reading. [...]
September 10th, 2006 at 9:41 pm
[...] open data, APIs, and data formats - lots of small pieces and a platform When I see a couple of related posts within a few days, and it coincides with some things I’ve been thinking, maybe it’s time to post something on the matter. One of the trends we’ve seen over the last 20 years or so, which seems to be accelerating, is the idea of “opennessâ€. Open Source software, open document formats and APIs, and a consequence of particularly the latter, open data and knowledge itself. Of course, there is a yang to this yin. Established players in particular aren’t necessarily thrilled with open source, open document formats, open APIs, and open knowledge. That makes sense. Big established software companies and publishers, to name a couple of players, stand to lose an enormous amount of market share, and perhaps as importantly, will need potentially to go through extraordinary internal upheaval to adapt to an environment where all software must be interoperable though published standard document formats, and where online walled gardens of data and services are replaced by much more distributed and interoperable systems. If we look to how networks are implemented, there are two basic models, which new generations of network tend to oscillate between. At one extreme, the intelligence of the network is concentrated at the center of the network, with the devices at the edge of the network being “dumbâ€. At the other extreme, the network intelligence is in the devices at the edge of the network, and the network itself is dumb. This latter model is in the ascendance at present. It seems that this model, which is reasonably well understood in network theory, applies at least by analogy to web content and services. The traditional model, of concentrated services and data, exemplified in services like massive job boards such as monster.com, represents “data at the centerâ€, while new, albeit somewhat experimental services like edgeio (the name tends to give it away) represents the “data at the edges†concept. At the end of last year I “predicted†that one of this year’s big trends would be a transition to “data at the edgesâ€, but that was a typically end of year glib prediction. In reality, I think we are seeing the beginning of what may be a paradigmatic shift, with all the pain these tend to entail, toward distributed knowledge and data. Of course, this may fizzle out in no time at all, because it does present some serious technical, and user oriented challenges. In the last week or so, three articles which touch on this issue in one way or another have been published, all well worth reading. Chris Messina considers Gdata, particularly its API, which appears to be Atom with some extensions, and Blogger’s adoption of this Gdata API, Tim O’Rielly takes up the issue in reference to Chris’s article, making the observation that “a platform beats an application†(which the history of the web demonstrates pretty well - it’s seen off eWorld, MSN, Compuserve, AOL - by which I mean all the proprietary web competitors that emerged in the early 1990s, some of which have morphed into ISPs or portals) while today, over at the Open Knowledge Foundation blog Rufus Pollock observes “open apis don’t equal open knowledgeâ€. Rufus refers to a recent article by Kragen Sitaker, on the implications of software as a service for users, also well worth reading. There is a lot to be played out here - in theory and in practice. From a business point of view, a technical point of view, and a users point of view. But I think its one of the really interesting things going on with the web, despite not having an interesting acronym, and despite being largely invisible to users. Microformats come into this by providing a simple interoperability layer for all kinds of data, some of which we already have microformats for (like contact details) but a lot of which we don’t yet. That’s the microformats way, develop the formats as and when they are needed. The web is itself a platform, and if Tim O’Reilly is right (which he often is), web based platforms, small pieces loosely joined will beat out monolithic apps. I’m certainly hoping he’s right. This entry was written by Blake Elshire and posted on September 4, 2006 at 6:08 pm and filed under Microformats. Bookmark the permalink. Follow any comments here with the RSS feed for this post. Both comments and trackbacks are currently closed. « Microformats (plus much more) developer job hCalendar » [...]
March 22nd, 2007 at 9:26 am
[...] http://blog.okfn.org/2006/09/04/open-apis-dont-equal-open-knowledge/ Posted by Rufus Pollock Filed in Open Knowledge, Musings [...]
August 30th, 2007 at 7:00 pm
[...] There has been a recent surge of chatter about “open services“. The current focus seems to have two branches: 1) attempts to define the term “open service” and 2) discussion of the impact of closed services to the larger Internet public good. This surge was probably triggered by Luis Villa’s recent work for the GNOME Online Desktop project. Luis takes care to catalog excellent references to earlier work as well. There’s a healthy conversation on the Open Knowledge Foundation’s okfn-discuss mailing list, where Rufus Pollack just posted a draft of an open service definition. [...]