At the 2006 O’Reilly Emerging Technology conference, Cal Henderson, then of Flickr, gave a long session called “Launching and scaling new Web services.” As I recall, among the many things he explained well were some principles behind the Flickr API. One of those principles was user access to data. The API should be one that allowed the user to haul all of her data out of the system, even if it was to federate that data into a competing system. That’s because Flickr believed that user data is the user’s first, and not just the company’s. Another principle was keeping the API stable, so as not to disrupt users and other services that depended on the API.
Cal left Flickr a couple years after that, but Flickr’s API remains a model of stability and utility — so much so that Dave Winer this morning suggested it be declared a national treasure.
Many of us depend in large ways to the APIs of companies great and small — and more get added to that collection every day. For a good picture of what’s going on with APIs, check out ProgrammableWeb.com. Between Dave’s respect for durable APIs like Flickr’s, and ProgrammableWeb’s roster of current and future dependencies, we start to see a matrix of APIs that Craig Burton compares to a city filled with buildings and relationships. Each API provider, like each building, exposes the provider’s core competencies in ways that can be engaged.
But what happens when we each have our own APIs — when our own core competencies become exposed in ways that can be engaged? And when we start managing our lives through relationships between our APIs and those in the rest of the world — especially in ways that are live and full-duplex (two ways at the same time, like a phone call)? And where each of us, or a trusted agent, can do the required IF, THEN, OR and other programming logic, between our own personal clouds and the clouds of others? What will we have then?
There is lots of blogging out loud about this, about both the downsides of dependency (as both Phil Windley and I have, toward Flickr in particular). But I think the upside deserves more than equal consideration, especially as companies begin to realize the importance of direct and engaged relationships with customers and users, which is what we’ll have when VRM and CRM (along with allied functions on both sides) fully engage. The result, I believe, will be a matrix of useful dependencies, based on APIs everywhere, thick with accountability and responsibility. The result will be far more opportunity, and boundless positive economic and social externalities based on the Net’s and the Web’s founding virtues. What will end, or at least be obsoleted, are Matrix-like worlds where users and customers are held captive.
Thus our goal for VRM: to prove that free customers are more valuable than captive ones — both to themselves and to everyone and everything else with which they engage.
It’s going to take me much more time and reading (of blogs like this) to appreciate how this space is going to evolve. I keep thinking that we will need some combination of our own, personal, technologies that combine with a somehow-semantic web.
Solving for the “brittleness” of the API method is what we need to do, at least at some level. Maybe it’s another layer that combines simple formats like JSON with semantic constructs. Applications work at that level and we allow for programmatic structures between that layer and the mechanical API layers for content, platform, location, and all the other more implementation-specific services.
The “landmark” status is fun to ponder. It hints at something we want which is at least some permanent definition of an interface to a of from a with these and capture the and that will work for all time.
The underlying API might be more granular and subject to change but we want to build some dictionaries of things that will always be true and mean what we agree they mean.
thanks info friends.
thanks for information , regards