First off, let’s get some prelimary affirmations out of the way: OpenSocial is a step forward in the social networking/digital identity ecosystem. We’re better off for having it available. It was fairly inevitable that a framework of kind would emerge in this area in reaction to the Facebook juggernaut, and in some significant ways, OpenSocial is well suited to achieving its basic goals.
It’s those basic goals that are underwhelming, disappointing. It shouldn’t be surprising to hear that we at JanRain digest developments like this with a keen interest on how this fits in with OpenID. And OpenID — or any namespace component — is conspicuously missing from OpenSocial. From initial passes at the APIs, OpenID will integrate quite nicely with OpenSocial, but the fact that OpenSocial has limited itself to interop and exchange between walled-gardens and silos severely limits its value to the user.
For example, consider a team of developers who want to develop a “social-network-aware travel calendar” - something a friend and ex-colleague of mine is actually working hard at right now. OpenSocial represents a step forward in reducing the burdens and headaches for this developer. By leveraging the OpenSocial APIs, the developers can expect to deploy their travel calendar apps inside the participating online communities in a much cleaner, standardized way; getting the social graph and attributes from the “host” has gotten much easier for the developer with OpenSocial.
But the key word there is “inside”. The disruptive, value-generating improvements for the user are realized in the “mashability” of the travel calendar app, not in its “embedability”. What benefits the user is that ability to log in to the travel calendar app and pull in the relevant social network data from all the appropriate sources. Tim O’Reilly makes a similar point with this example:
“Imagine what would have happened to Google maps if instead of supporting mashups, they had built a framework that allowed developers to create mapping applications across Microsoft, Yahoo! and Google as a way of competing with MapQuest. Boring! That’s the equivalent of what they’ve announced here.”
It’s no mystery why OpenSocial is structured this way: it’s designed to let other walled-gardens compete with Facebook, the runaway leader in walled-gardens in the social network ecosystem. It would be a design flaw for OpenSocial to integrate OpenID and expose the data isolated in those walled gardens. The mashups would be fantastically rich and useful for the user, but would displace the “location” of the user — an OpenID is a portable, autonomous identity, after all. It breaks down the walls of walled gardens.
It shouldn’t be a surprise, then, to see OpenSocial appear in the form it has. I’d frankly have been shocked if it had been designed around a unified namespace and portable identity — OpenID, in other words. Ecosystems evolve, and while OpenID is growing fast, and accelerating its growth as we near the release of OpenID 2.0, its disruptiveness is problematic for the parties involved in putting out OpenSocial. Over time, I believe the momentum and disruptive nature of OpenID will force a re-orientation of relationships between users, social networks and service providers, but for now, OpenSocial is just the next skirmish in the war between the walled gardens.
| By Brian Ellin | May 16th, 2008 | Comments [3]
