Update: check this for a clarification on a seriously flawed assumption in this post.
Initially, I spent a lot of time thinking about OpenSocial in terms of Widgets/Apps/Gadgets, which is I think where people want us looking: it’s in the big graphic on the Google documentation and it’s what made Facebook so sexy to developers.
But I think Widgets are an artifact of closed website borders. The data that’s available via OpenSocial, the data that powers those Widgets, is people data. What’s striking to me about the blog commentary to date is that they seem to take it for granted that users will stay put while apps float around. Here’s a sample headline for Jermiah Owyang:
Using mini-applications, companies can now efficiently extend their website experience to existing communities on popular social networks
Boo. Forget about extending your website experience, let the users float freely!
I’m no developer, but a quick review of the People Data API seems to indicate that if you have a user’s credentials, you can grab all their profile information. So we could envision a flow like this:
- Member has a ton of profiles on social networks all over the web.
- Member browses to a new, OpenSociable online community.
- Ooh, she’s hot! Member wants to join!
- Member clicks the “Join” link
- Instead of the usual form, member sees that he can simply enter his MySpace, Orkut, Bebo, etc. usernames and passwords (OpenID would make this faster) and all of his profile info from all those other sites gets pulled into his newly-created account.
This is like the Slide.com experience, except it’s so much more than photos, it’s everything you got. That means that rather than waiting for the apps to fit inside the Host site’s box, the user can go to the apps.
I strongly believe that online communities are one part same old social media infrastructure (message boards, friends, UGC, etc.) and one part “gravity” – that special feature, configuration, or population that makes it most appropriate to a specific audience. OpenSocial helps standardize that first part and mobilize users, which means they can float to the gravity that best fits them.
This is also very scary for big sites that are still dependent on switching costs to preserve user loyalty (instead of, oh say… a good product offering). I think Marc’s fears are bound to come true, at least in the short term:
What happens when some of the alliance members don’t adhere to ALL of the APIs and thwart or warp the APIs? What happens if they DON’T let their users more their data around – but only SUCK IN external data?
Look out paw! The cattle done busted out of the corral!
I’m not sure how, but it’s important to identify incentives for letting your users run free. I think this means cash, and I’m not sure how to make exit doors profitable, but we know they’re good for users, so there must be a connection to dollars somewhere.
Next up, I want to see the first developer who starts *extending* the OpenSocial APIs! I hear murmurs of fear that Google is secretly going to do bad things at the helm of this project. Who leaves them at the helm? Why are we content to chew on what Google’s dishing out when we could be looking for ways to extend it? This seems like an exciting beginning. Marc’s already making demands. Just as Flickr and Yahoo extended the core RSS schema, I think we’ll know OpenSocial has made it when people start building, and using extensions.