OpenSocial is to Google as OpenGraph is to Facebook. Some might say that’s all you need to know about OpenSocial 2.0. But as leading technologists and innovators takes sides for and against it, there is much more to the story.
Making Way for OpenSocial 2.0
Ratified in August, the final version of the OpenSocial 2.0 specification was officially released in an attempt to become more relevant to the world of social application development. It adopted elements of other interoperability specifications being used for social software development, like activity streams and OAuth 2.0.
Such broader social specifications might make you think that OpenSocial has been welcomed with open arms in to the social enterprise. And though it has been implemented in more places than gets reported, there is still a pretty significant segment of Silicon Valley that refuses to accept it. A line has been drawn. You’re either for it or against it. And each side makes a convincing argument.
In his August article on The Brain Yard, David F. Carr writes that
Since Google introduced the first version of OpenSocial in 2007, it's been positioned as a counterweight to Facebook's Open Graph protocol and the dominance of Facebook's de facto standards for social applications. Because Facebook does not support OpenSocial, the creators of consumer applications have paid less attention to it.
Three months after OpenSocial 2.0’s release, many are still none closer to accepting it. This week, David F. Carr reported that Aaron Levie, CEO of Box.net, in a further attempt to separate himself from other well-known and oft-implemented enterprise social applications (ahem, SharePoint), is in search of more innovative open web standards. Carr writes:
Though Levie sees the need for better social software, he rejects many of the social software standards other companies such as Jive Software are embracing. He bemoans that Jive Software, Yammer, and Salesforce.com's Chatter have different approaches to social message streams, but he doesn't think the Activity Streams specification is the answer.
If OpenSocial 2.0 aims to be a better choice for social software it needs to get out from under the shadow of Facebook. While developers have flocked to Facebook and adopted its standards for social application development, OpenSocial has an ally in Apache developers. Apache Shindig, an open source implementation was developed in parallel with the OpenSocial 2.0. Shindig 3.0, while not yet available for download, will deliver support for OpenSocial 2.0.
With serious support from enterprise software vendors such as Jive, SAP, SocialText, IBM, Nuxeo, Atlassian and others, OpenSocial is being adopted by organizations who need to bridge social content and corporate content management systems. Just as CMIS has accelerated its adoption across ECM applications due to developer contributions to the open source Apache Chemistry project, so is OpenSocial finding critical mass with the open source Apache Shindig project. Shindig streamlines the creation of OpenSocial applications. It provides a reference implementation that can be used by developers, simply by downloading existing code. As collaborative efforts, open source projects such as Shindig and Chemistry include contributions from software developers working for vendors, consultants and end user organizations alike.
Agree to Disagree? Or Agree to Innovate?
The future of OpenSocial looks bright, if you talk to the right people. But two years ago we would have believed that Google had an edge over Facebook. If the choice is between OpenGraph and OpenSocial, both of which have our online identities extended beyond a single social network, perhaps our options are limited when it comes to the open web.
Earlier this year, Tantek Çelik, an independent technologist wrote on his blog about the 10 Practices for Good Open Web Standards Development. He talked about the importance of examining the emergent patterns and anti-patterns involved in developing standards. He writes:
There's a whole spectrum of ways to develop open web standards that's expanding over time as we learn new practices both good and bad. We can and must always strive to be better at it.
When we look to adopt open interoperability standards, we must not take sides based on who’s using it, but rather how we can build off of it and strive to make it better than it is today.