Let me throw some things against the wall and see if anything sticks.
This week I confirmed Chris Messina (of OAuth, and now Activity Streams fame) and Jeff Lindsay (who gave an awesome talk on Webhooks last year) to speak at Gluecon. Simultaneously, I’ve been reading blog posts like this — where the punch-line is:
“Jump to the future when all of your favorite sites implement programmable hooks. The pipedream, holy grail, end result is that you no longer even need Twitter, because it’s become a protocol. Just like blogs happily send pingbacks, you can install a Twitter-speaking, open sourced package on a Slicehost account that is your own personal Twitter…It’s a decentralized, pluggable architecture, and it integrates with any site using web hooks. At your service.”
Further, we’re starting to see news around Twitter and OAuth Delegation. Add it all up and what do you get? The power lies in the API. Or maybe, more pointedly, in the terms of service that large players choose to impose on their API.
LinkedIn is famous in some circles (no names) for not playing so nice with their API. According to their terms, you can’t store anything other than a profile or ID –which is to say you can’t store the most powerful/useful thing about LinkedIn — the connections. Beyond that, their TOS says that you can’t use their API and “compete” (though it never defines what that is). And, to put the icing on top, they gain the right to “audit” you if you use their API.
Are these things reasonable? Do they compare unfavorably with Facebook, Twitter, etc? I don’t know. But it’s a conversation worth having.
You see, the goal of “the cloud” isn’t simply putting all of your stuff into some stored space for access. It’s connecting your “stuff” — your apps, data, networks, etc. The how, if, why, when and where of that connecting (you could call it, for lack of a better word, “glue”) is wholly dependent on the terms of service around APIs.
Here’s what I’m not suggesting: I’m not suggesting that companies don’t have to right to limit how you use their API (of course they do). I’m also not suggesting we build a “standard TOS for APIs” (although I have little doubt that some working group in some association somewhere is talking about just that). I am suggesting that it’s time to start digging into what all of this means for actually building things.
So while guys like Chris and Jeff are out building the guts of how to do callbacks and streams and whatever else, we also need to be thinking through what “terms of service” really means in a “post-cloud” world.
And we’re gonna do that at Gluecon.
