Last week Google announced OpenSocial with an impressive set of partners including Orkut (as expected), MySpace, iLike, Flixter, Oracle, .... There were companies that had their own social network, others that offered applications through the Internet and even companies that provide services and infrastructures. There's been a lot of blogging about whether this is Google's checkmate to Facebook platforms or it doesn't make such a difference, among other reasons because Facebook could actually jump in into OpenSocial too.
But I'm not that interested in politics. What I really care about is the technical side of OpenSocial and looking at that side there are a lot of things to be excited about.
Let's start from the beginning, what exactly is OpenSocial?
“OpenSocial is a set of APIs that an application can use to access social network related functionality. Including accessing information about the user and his/her network of friends, modifying this information or generating activities based on what the user does in the application that his/her friends will receive.”
This API is targeted to applications that run in social networks. Those applications do not usually run by themselves but are accessed through a social network container that executes it either locally (as it's done with portlets) or remotely (as happens with Google gadgets). The fact that the application runs in a web page that acts as a container is key to understand OpenSocial.
The key innovation of OpenSocial
“Develop Once, Run Everywhere”
var req = opensocial.newDataRequest();
viewer = dataResponse.get('viewer').getData();
owner = dataResponse.get('owner').getData();
ownerFriends = dataResponse.get('ownerFriends').getData().asArray() || ;
There are several things to note about this example:
- The access to the API starts through an object called 'opensocial'. That object is not part of the application, it just assums that it's going to exist when it's executed within the social network container.
- Each opensocial request contains several petitions for functionality. That allows reducing latency and network bandwith, because each application only needs to make one remote request.
- The request is asynchronous (uses AJAX), so the user can interact with the parts of the site that do not need to wait for the response.
From an application developer perspective that really means that they can develop their social application once and deploy it in several distinct containers. The application will use the social network of the container where it's deployed.
But what if some social networks have some functionalities that others don't?
Standarization vs Innovation
OpenSocial defines three functional modules:
While those modules cover much of the functionality needed in social networks, it doesn't cover all. Because the truth is no fixed standard will never be able to cover the functionality that is very specific for a given social network. So, faced with this situation what should an OpenSocial application developer do? I see two options:
- In more complex cases, where using the functionality or not makes a bigger difference or when it has to be decided in the client side, there might be a need to create different versions of the application for each platform.
When the second option is chosen, the sentence “Develop once, run everywhere” is not true anymore. For this reason, some say that Google is not that ambitious and they are in fact promoting an slightly different motto:
“Learn Once, Use Everywhere”
Which is still quite useful. There is still one more technical aspect that may make the developer decide to have different versions per platform: the technology used to develop the OpenSocial application itself.
What technology can be used to build OpenSocial applications?
So using OpenSocial within Google Gadgets is easy. But Google Gadgets are not the best solution for any type of application. So the question is, would it be possible to use OpenSocial with other technologies such as portlets?
How does Liferay relate to OpenSocial?
Liferay already provides basic functionality that can be used (and has been used) to build social networks. To be fair, that requires some development. For this reason, we had talked lately about developing and adding more functionality tipicaly of social networks in the default distribution (or as an official plugin).
Open Social makes this idea even more attractive. First Liferay would become one of the first products for executing open social applications (right now there are platforms, but you cannot download and use them yourself). Second, Liferay's social features would be exposed through an standard well known API, which is very useful to promote the development of extra applications that leverage it. Third, as Liferay already supports Gadgets, any open social application developed with this technology may even run unmodified in Liferay.
So this is a case where reasonably little effort would yield a great amount of benefit to our users'
The dark side
To be fair, this is version 0.5 of OpenSocial and the engineers behind it are showing a lot of interest in hearing what the community has to say. I'm pretty sure these problems will be solved for version 1.0. Until then it should probably not be used in live environments, but this is a great time to start development around it. We will most probably do it :)