- The OpenSocial standard is being woven into enterprise collaboration applications, promoting both interoperability and extensibility.
- OpenSocial is not yet complete or reliably employed, requiring careful screening by would-be consumers.
For decades, enterprise IT departments have sought out and experimented with component development models that would both allow for application interoperability and speed development. Throughout that time, ORBs, Beans, and portlets have all had their turn and played influential roles in shaping how applications are built and interoperate. However, a small standard created by Google in 2007 may put all of those efforts in its rear view mirror, at least within the collaboration platform marketplace.
That standard is OpenSocial, and it was initially built as a set of APIs by Google to regain a strategic advantage over its rival, Facebook, by forcing Facebook to open up to other social networking platforms such as MySpace, Ning, okurt (Google’s rival platform), hi5, Friendster, and others. The idea was to allow two platforms to exchange basic information such as profile data and activity feed posts. In that initial endeavor, OpenSocial was unsuccessful, partly due to Facebook’s disinterest in bending to Google’s will and partly due to the immaturity of the standard itself.
However, OpenSocial (now at version 1.1) has matured greatly both in capability and in its intended scope. Many collaboration players currently utilize this standard not just as a means of exchanging user profiles and activity stream feeds (the social graph), but also as a standard application model that will allow third parties to extend and customize a given platform. Jive Software, for example, has architected its enterprise social networking platform to function as an OpenSocial container, which can host third-party applications built using the OpenSocial standard. Even for staid collaboration tools such as IBM Lotus Notes, OpenSocial is becoming the preferred method through which IBM partners can embed functionality within the Notes interface. In this way, OpenSocial is becoming a central architectural substrate of collaboration software. Telligent is actively deconstructing its software into OpenSocial components, which partners and customers can drag and drop into other OpenSocial containers.
What these efforts are leading to is a corporate landscape of highly modular applications. As with most standards, however, OpenSocial is no Shangri-La. It is a work in progress that still has many questions to answer in terms of both what it does and how it protects and secures data. For example, it has only recently begun to embrace important related standards such as OAuth and Activity Streams (both are addressed with the emerging OpenSocial 2.0). More importantly, because each vendor has the freedom to build unsupported extensions to the standard or leave select facets unsupported, OpenSocial holds unsuspecting traps for enterprise customers looking to use OpenSocial widgets within their own containers. Even Google itself is guilty of this, adding as-yet unsupported capabilities to its suite of iGoogle Gadgets. Enterprise customers should therefore approach OpenSocial-savvy software products very carefully, assessing which version of the standard is being employed, how fully that version is supported, if there are any extensions at play, and whether or not that application is a full OpenSocial container.