OpenSocial: It’s a programming model, not a federation, for now
To say it has been amazing to watch OpenSocial come together in recent months is an understatement. OpenSocial isn’t a product that Google came up with, it is a standard. At first you have to get a large number of groups at Google to agree to the core ideas, and then came the partners. Working with the partners has been a real trip too, and the speed of development as well as decision making is truly astounding to me.
I knew that the press will jump on this as “a Facebook killer” or “Facebook vs. Google”, but that is b.s. Applications that are social can be better and we have only seen the beginning. F8 has opened up a lot of eyes, and many companies are going to innovate in this space.
Take a look at what OpenSocial really is. Check out the APIs. Understand that this is the beginning of something. The first set of APIs mesh closely with Gears, as I talk about on the podcast with Patrick Chanazon. There are a few core services (people, storage, activity stream) that have GData endpoints that you can access, including the core JavaScript library which is how development is generally done at the moment. The libraries will look especially familiar to Google Gadget developers, as they are similar in philosophy. To me, this isn’t about some huge new platform, but rather a set of components that people can use. Gears is the same way. You have three key components (as of now): WorkerPool, Database, and LocalServer.
As a Java guy Patrick and I even joked about how it felt a little like some of the Java standards in that this isn’t about “write once run everywhere” but is rather “learn once use everywhere”. OpenSocial has the concept of “containers” where these APIs run. This is where container partners such as Bebo, Ning, Hi5, a ton of others, and, oh MySpace come in. opensocial.newDataRequest() everywhere.
The API is at a point where there is value to using it, and having one API that containers implement allows a developer to develop against it, knowing that they can move their app around. On the other hand, containers can add to the API to give specific information that you may want. For example, if your container has a lot of music information you can share that, and if you are building a music app, that could be a good thing. There is a core set of APIs, and containers will add their value on top, just as WebLogic did through deployment descriptors :)
Back to Facebook. I actually don’t think this is a bad thing for Facebook. It validates the market, and will grow the entire pie. Now even more developers will think about developing social applications. Facebook has a lot of users hanging out on that network, and they are the kind of users that are used to installing applications at this point, so I think that a lot of developers will write applications than run across FB and OpenSocial and beyond. Having MySpace along for the ride is big, and maybe Facebook could join in too and we could create a true standard that the community pushes forward.
It has probably stirred up the FB folk too. They have known that this is coming. Competition is obvious, and I hope that OpenSocial can help push Facebook into getting increasingly open too. They sometimes get a bad rap there, and we keep forgetting that they opened up F8 only *months* ago, and are still working out what it means to open up a platform like this. It will take time and there are a lot of hard problems. As great as collaboration is, there is also a PC vs. Mac debate here. Facebook can run like the wind in their own direction. This could end up being a fantastic product. On the other hand the group could also run quickly as they have been doing, and instead of being stuck in standards hell, they could produce something just a great, across many containers.
Should Facebook implement OpenSocial? I personally think so. Why?
- It will be a lot easier to grow the developer pool on OpenSocial as you can just get new partners and hitwise grows
- If people developer cool apps on top of OpenSocial, why wouldn’t you want them to run as applications in Facebook? It could also allow developers who aren’t fans of FBML to use different methods of building their applications.
- Facebook can still innovate as a top notch container that has a huge amount of users
- It would negate “us” versus “them” talk.
It is going to be an interesting ride, and I hope that people don’t get sucked into the press too much and really check things out. With everyone jumping on board, I wonder what is next. Can we get to the world that Brad talked about? Will we get a federated world? There are some hard problems to solve.
Resources
