Open?

The nerdier nether-regions of blogland have been burning through the night with the news of the OpenSocial initiative spearheaded by Google and supported by what Chris so aptly calls the coalition of the willing.

Like Simon, I’ve been trying to get my head around exactly what OpenSocial is all about ever since reading Brady Forrest’s announcement. Here’s what I think is going on:

Facebook has an API that allows third parties to put applications on Facebook profile pages (substitute the word “widget” for “application” for a more accurate picture). Developers have embraced Facebook applications because, well, Facebook is so damn big. But developing an app/widget for Facebook is time-consuming enough that the prospect of rewriting the same app for a dozen other social networking sites is an unappealing prospect. That’s where OpenSocial comes in. It’s a set of conventions. If you develop to these conventions, your app can live on any of the social networking sites that support OpenSocial: LinkedIn, MySpace, Plaxo and many more.

Some of the best explanations of OpenSocial are somewhat biased, coming as they do from the people who are supporting this initiative, but they are still well worth reading:

There’s no doubt that this set of conventions built upon open standards—HTML and JavaScript—is very good for developers. They no longer have to choose what “platforms” they want to support when they’re building widgets.

That’s all well and good but frankly, I’m not very interested in making widgets, apps or whatever you want to call them. I’m interested in portable social networks.

At first glance, it looks like OpenSocial might provide a way of exporting social network relationships. From the documentation:

The People and Friends data API allows client applications to view and update People Profiles and Friend relationships using AtomPub GData APIs with a Google data schema. Your client application can request a list of a user’s Friends and query the content in an existing Profile.

But it looks like these API calls are intended for applications sitting on the host platform rather than separate sites hoping to extract contact information. As David Emery points out, this is a missed opportunity:

The problem is, however, that OpenSocial is coming at completely the wrong end of the closed-social-network problem. By far and away the biggest problem in social networking is fatigue, that to join yet another site you have to sign-up again, fill in all your likes and dislikes again and—most importantly—find all your friends again. OpenSocial doesn’t solve this, but if it had it could be truly revolutionary; if Google had gone after opening up the social graph (a term I’m not a fan of, but it seems to have stuck) then Facebook would have become much more of an irrelevance—people could go to whatever site they wanted to use, and still preserve all the interactions with their friends (the bit that really matters).

While OpenSocial is, like OAuth, a technology for developers rather than end users, it does foster a healthy atmosphere of openness that encourages social network portability. Tantek has put together a handy little table to explain how all these technologies fit together:

portabilitytechnologyprimary beneficiary
social applicationOAuth, OpenSocialdevelopers
social profilehCard users
friends listXFN users
loginOpenID users

I was initially excited that OpenSocial might be a magic bullet for portable social networks but after some research, it doesn’t look like that’s the case—it’s all about portable social widgets.

But like I said, I’m not entirely sure that I’ve really got a handle on OpenSocial so I’ll be digging deeper. I was hoping to see Patrick Chanezon talk about it at the Web 2.0 Expo in Berlin next week but, wouldn’t you know it, I’m scheduled to give a talk at exactly the same time. I hope there’ll be plenty of livebloggers taking copious notes.

Have you published a response to this? :

Responses

Ted Rheingold

In regards to Portable Social Networks, I’ve been looking at it a different way. OpenSocial is not the most awesomr as Chris M. would say, but it could provide us with some pretty decent transition capabilities that would not undermine, microformats, OpenID, OAuth, etc. as they can easily be included.

Overall, I think the whole embedding of apps simply because you can is a novelty phase that will play itself out. Zombie games and poke variants will wane in usage. What will become very used is when widgets become extensions or even better 3rd party software that on behalf of each of it’s users installs a ‘widget’ in a ‘container’ in each social network the person is involved in. The Widget could be considered more of an app extension or a direct socket connection that retrieves all news related to the person’s profile from that network, aggregates it with their others for you and shows you via one nice dashboard.

You could even have a private dashboard as a public one that shares the info you are comfortable with.

The way FriendFeed, Readr, Iminta and Flock1, suck in your friends actions by by each distinct API, the OpenSocial manner would allow for optimized direct plug-ins into those networks.

Then you could for example push a photo to a real-time selection of your networks on a case by case basis. Same goes with a microblog entry, or audio files, but just to your friends you’ve grouped as ‘music pals’

I know the APIs are no where near this type relationships, but they will be soon.

So though it’s not as good as directly inter-operating Widgets, it’s much better than what we have now. In fact, a clever person could take it a step farther and make a universal widget communicator. A sort of bridge language so widgets could be allowed to directly communitcate (whether widget-to-widget or through a communication channel)

To be honest it really feels like the Geni is out of the bottle on this one. And though it’s not an ideal platform, (and it could be much more awesomr ;) it will be a rather functional one that far exceed today’s methods of site-to-site, widget-to-widget, person-to-machine communication, at least until the better thing comes along, next.

t-

Ben Buchanan

I’ve said before that we need "walled garden" approach to die, so people can choose whichever social network tools they like. For example, I think MySpace and FaceBook can live happily side by side. Neither has to "win". The data users enter just needs to be portable.

So why Google didn’t attempt to make the contact list portable is beyond me - I would have thought that was the most important first step!

Still this seems to be a step towards recognising the design patterns evident in social networking, then developing for patterns instead of implementations.