Media Influencer

helping people break out of pigeonholes since 2003

OpenSocial – more social than open

TAGS: None

So, been watching all that excitement about Google’s OpenSocial and I couldn’t hear over all that cheering how much do I get to ‘own my data’ and take it with me until I read Tim O’Reilly’s post OpenSocial: It’s the data, stupid:

My disappointment with OpenSocial was crystallized by an exchange between Patrick Chanezon, Google’s developer advocate for the program, and an audience member at the OpenSocial session at Web 2.0 Expo Berlin. The audience member asked something about building applications that can remix data from the participating social networking platforms. Patrick’s answer was along the lines of: “No, you only have access to the data of the individual platform or application.”

That is rather disappointing. I do not just want social network aggregators. As a user I want to take my information, profile, contacts and context with me wherever I want and can. If I am to invest my time into creating profiles and gathering contacts (thus making my friends to invest theirs), then spending time building context, which is actually more important than data. Data has become a commodity, it can be replicated and distributed without the physical constraints data faces offline. What is now rare is context because that still a) has to be created by humans and b) is not machine readable. So to elaborate on Tim O’Reilly’s

…two key principles of Web 2.0:

* It’s the data, stupid. (Formerly “Data is the Intel Inside”)
* Small pieces loosely joined.

…a principle of social web

* It’s the context (and control over it), stupid.

If all OpenSocial does is allow developers to port their applications more easily from one social network to another, that’s a big win for the developer, as they get to shop their application to users of every participating social network. But it provides little incremental value to the user, the real target. We don’t want to have the same application on multiple social networks. We want applications that can use data from multiple social networks.

Such applications would have to be based and designed around the user, not another platform and its growth and maintenance. Which is what every social network to date has been. And if you design for the individual, the distributed is definitely the way (see Small pieces loosely joined). At a VRM meeting in London last Friday, among other things, how to design an architecture around increasing control over our data. Alec summed it up:

…should we consider making a VRM pilot and simplify our lives by making the assumption that the database would be wholly centralised; the answer to that was an emphatic NO; the reason being that working from a perspective of “the data is centralised in a fortress” will lead to thinking that will never be able to accommodate a distributed architecture; whereas there is nothing to prevent an architecture which is capable of distribution in a wholly or partly centralised matter, as a convenience. In short: the web-browser would never have been invented had someone elected to ignore the distributed nature of the Web; instead, they would have merely yet again reinvented the file-browser. So: DESIGN IT DISTRIBUTED, TEST IT DISTRIBUTED, BUT IMPLEMENT IT HOWEVER YOU CHOOSE.

That’s the spirit. But Tim O’Reilly asks the crucial question:

Would OpenSocial let developers build a personal CRM system, a console where I could manage my social network, exporting friends lists to various social networks?

No, it doesn’t look like OpenSocial will, but VRM is predicated on that. Set the data (and their owners) free!

TAGS: None

5 Responses to “OpenSocial – more social than open”

  1. broadstuff
    on Nov 12th, 2007
    @ 10:57 am

    Gunpowder, Treason and….Pizza?…

    Its Friday night, and the weekend approaches – so what does a gentleman do in London Town? Thats right, he goes across town in the rain and dark, and approaches a dark dive deep in a basement – but not to partake of the sins of the flesh. No, dear read…

  2. alecm
    on Nov 12th, 2007
    @ 11:22 am

    oops, i must have made a slight typo; it should read:

    there is nothing to prevent an architecture which is capable of distribution [from being *implemented*] in a wholly or partly centralised matter, as a convenience.

  3. Roland Turner
    on Nov 18th, 2007
    @ 15:04 pm

    I’m a little late to the party on this one, but a read of the OpenSocial API suggests that user access to “their” data, at least the ability to export their graph adjacencies, is exactly what the People Data API portion of OpenSocial provides.

    Obviously access is subject to access-control by the site operator, and no doubt extensive graph duplication would get noticed (most existing site operators aren’t likely to permit access by unregistered applications) and may get stopped, but the rudiments are there; there’s enough API to gain realistic control, at least where site operators will permit it.

    The “site operators” can, of course, be bloggers (in the broad sense; anyone with a account…); why shouldn’t WordPress, MoveableType, etc. implement OpenSocial?

    (Once that’s happened, and setting aside a chicken and egg problem, there’s data there for vendors – who aren’t affiliated with site operations – to be granted controlled access to as part of commerce. Baby steps.)

  4. Who Owns You? : Tomas Kohl
    on Apr 28th, 2008
    @ 2:34 am

    [...] comes in (if I understand it correctly). Whether it’s open enough at this time is rather another question. I appreciate the step in the right direction, and at the same time keep asking: how about our [...]

  5. Google local government event « News from a Nerd
    on Aug 10th, 2009
    @ 16:16 pm

    [...] The former lets you access your contacts and friends data across different social networks.  As Adriana Lukas has pointed out in the past there are limitations – Open Social still doesn’t allow me [...]

Leave a Reply

© 2009 Media Influencer. All Rights Reserved.

This blog is powered by Wordpress and Magatheme by Bryan Helmig.