Report from OpenSocial Meetup at Google
Update: Facebook pulls a Microsoft and embraces and extends by opening their platform to other social sites like Bebo. Very smart and unexpected. More info at Facebook to let other sites access platform code.
This month's regular Facebook Meetup was held at Google and the topic of the day was OpenSocial. For those of you with real lives, OpenSocial "provides a common set of APIs for social applications across multiple websites." Over 200 excited people, hoping to do very exciting things, and dreaming of making an exciting pile of money, watched an OpenSocial presentation put on by a couple of appropriately knowledgeable evangelists. I could feel my social graph being more successfully monetized with each passing minute.
Normally the meetings are much smaller, but Google puts on a very nice spread, so I think people may have showed up to dine :-) Or they could have showed up to learn why and how they should code to the new uber social API. By the looks of the full plates and the sounds of energetic chatter, it was likely a bit of both. The crowd seemed skeptical, yet interested. The Facebook world is somewhat self satisfied and that comfy world was being disturbed. It might get ugly I thought, but unfortunately it stayed quite civil and informative. With my bread I had hoped for a bit of circus.
My take on OpenSocial: code social application once, run anywhere.
Code your social app using Google's gadget model and the social API and it will run on any conforming social network container. It's kind of like a concurrency model based on mobile threads instead of the more traditional message passing model. So your friend's profile app will work just as will on Ning as Orkut. Interestingly, there's a layer of indirection the social network container has to locally interpret what things like friends are. So your friends in SalesForce could mean people you've email once and friends in Ning could mean people you've marked as friends.
There's a fairly minimal API of verbs and nouns at this point, but that will undoubtedly grow. They are taking a "do the simplest thing" approach. Or they could have simply needed to get something out to compete with Facebook. Important features like a security model, authentication model, sharing model, and advanced data types are TBD. Lots of tricky things still have to be specified. How do you establish identity across services, who can share what information, how do apps deal with different terms of services, and how they deal with different social network models?
OpenSocial is a group of companies so you hear a lot of things like "we'll have to meet and decide that. Joe has a lot of good ideas on how that might be done." The same sort of stuff you hear with all the complex Java standards that everyone hates. Maybe some group will Spring into action and fix some of the problems that develop.
What I don't quite understand is how social networks will distinguish themselves from each other with a common API? Using the standard your app will run anywhere so why should I choose a particular social graph provider? So services will have to differentiate by adding nonstandard features which leads to a horrible complex mess of a system. They were already talking about using reflection so you could discover what capabilities a container had. Oh boy. Sounds like a hard road for developers.
From a scalability POV you must still host your own applications. So that's no different from Facebook. If you get a million users overnight you have to figure out how to make them scale. On the bright side there was a properties like data store you could use to store data in. The amount of data, types, query model, transaction model, locking model, SLAs, etc seemed open, but not managing state is a big win. From a scalable development POV, I can't help but think the drive towards differentiation will require special coding for each target container and you'll have to pick just a few containers to develop for (think browser wars times 100), but we'll see.
