Does OpenSocial Live Up To the Hype?

Earlier this week, Google released their new social network API called OpenSocial. The tech media has dubbed it a Facebook killer. Does it live up to the hype?

After spending about three weeks with the platform, I think it falls significantly short of the hype. Dare Obasanjo gives a great overview of how to evaluate a social networking platform. I’m going to re-iterate some of his points and add a few more.

If you haven’t looked at OpenSocial you can think of it as basically a widget platform. It is based heavily on Google Gadgets. It is currently a javascript only platform. Let me say that again. OpenSocial is currently just a browser based platform. There are no server side APIs. OpenSocial also has no messaging primitives. Finally, it has no UI layer. When you strip away all of the hype, all you really get is an iFrame and an insecure way of storing data.

To help illustrate the problems with the API, I’m going to use an application that has been written many times for Facebook, Poke. Poke is a simple messaging application. When you “poke” a person, you send them a little message which they can either view or ignore. Poke applications often display the most recent pokes on a user’s profile.

Let’s pretend that I’m viewing profiles and see somebody with a really cool poke application on their Orkut or Plaxo profile and I want to give it a try. On Facebook, I would just click on the application and be prompted to allow the application access to my information. I could then install the application if I wished. OpenSocial has no equivalent. By default, an application can view quite a bit of information about a viewing user including name, friends and any other public information. OpenSocial also includes no standard method for requesting a user to install an application. That means there is no way for your application to spread when other users discover it. I’m sure this will change at some point, but it is a significant miss.

If I were to figure out how to install the application I run into another significant problem. OpenSocial includes no messaging. That means that I have no way of notifying a user that they have been poked. Google has created an Activity Stream API, but that doesn’t address the issue. Activity streams are used to broadcast my actions. For instance, I just updated my status or added a new friend. There is no way to send a message to another user. That doesn’t sound very social, does it?

OpenSocial does provide a data storage javascript API. That gives us a way of storing the fact that I sent a poke to a friend. Well, it almost does. The data API lets me store information either on a user or in a general application storage pool. If I store application in the general pool, every user will have access to every other user’s data. That doesn’t work. The other option is to store the fact that A poked B on user B. That means that user A will need the ability to read and write data on user B. Of course, since the API is javascript based, that also means that any user will be able to use their browser to view any information stored for their friends. Isn’t that a little scary? Anyway with a javascript debugger can view and modify our entire application state.

What about storing the information on the server? Good idea! OpenSocial gives you a way of making cross browser AJAX requests. Unfortunately, there is no authentication in place. That means our server has no way of knowing who the viewer is on a given request. Facebook works around this by using an OAuth like authentication scheme where all requests from their servers include a signature that is made with a shared secret. There is no equivalent in OpenSocial. This may sound like an academic problem, but is has already led to the hacking of an application.

Finally, once all of these other issues are resolved, we still have an integration issue. Facebook gives you the ability to integrate your UI with theirs. They go so far as to give you UI tools that will help match their look and feel. OpenSocial gives you an IFrame. That means that you’ll need to build a UI that matches the UI of the container if you want to provide a seamless user experience. That would be okay if you were targeting only one container, but if you want the cross network benefit that is being touted, you’ll need to re-skin your UI for each container.

I know this is an early release so I won’t continue to beat on OpenSocial. My main point is that this new toolkit isn’t the panacea it’s being made out to be. In fact, I’m recommending that my clients don’t start using the platform until at least the messaging and security issues are resolved. I’m hoping that happens quickly, but the last three weeks haven’t given me much hope.