OpenSocial

It's Open. It's Social. It's up to you.

Enterprise OpenSocial Whitepaper


Enterprises are collections of people, and thus inherently social. Employees of any organization benefit from social connections, group affiliations and relationships both within their own business and between other businesses. As a result, social networking capabilities have become increasingly popular in business-to-consumer, business-to-business, and internal enterprise collaboration applications. New technologies and standards such as Web 2.0 and OpenSocial [1] are helping software providers better model relationships between people, allowing end-users to benefit from such relationships in day-to-day business processes within their own enterprise, and across business networks.


OpenSocial emerged from the demands of consumer-facing social networking sites, including MySpace, LinkedIn, and Ning. Well before the specification was complete, those sites went live with OpenSocial implementations, proving that OpenSocial is ready for both Internet scale web communities and enterprise applications. The rise of online social networking, and the changing nature of the consumer web, have both made OpenSocial increasingly relevant to business and enterprises. Beyond social capabilities for accessing and sharing user profile, relationship and activity data, OpenSocial can also be used as a general purpose web application integration technology, providing open standards for browser-based components known as Gadgets.

 This paper discusses general requirements for enterprise social systems and describes how OpenSocial can be used by enterprises today to address them. Not all requirements are met today, however, so the paper also outlines the current gaps and discusses how the specification might evolve to meet them. Naturally, no paper that focuses on working transparently in an open community would be complete without a call to action. The paper concludes with an introduction to the companies driving enterprise requirements for OpenSocial, provide guidance to resources to learn more and encourages you, the reader, to become actively involved.

Who should read this document?

This document is intended for IT professionals, development managers, and Chief Technology Officers (CTOs) who are leading organizational changes through social computing by embracing standards and Web 2.0 approaches.

OpenSocial Defined

A brief history of OpenSocial 

Before diving into how OpenSocial can benefit the enterprise, it is helpful first to understand OpenSocial's history, especially the evolution from its Social Networking Site (SNS) roots into a broader platform for social interaction and application interoperability. As social networking became more popular, there was increasing pressure on these sites to add differentiated capabilities and attract more users. A business model was also emerging where vendors wanted to offer their services into these social networks. Before OpenSocial, the notion of deploying an application into a social network was strictly a proprietary exercise. What's worse, if they had applications for each platform, they had to maintain them, account for programming model dissimilarities, translate each one, and so on. 


OpenSocial provided a solution to these problems by serving as an open, community-driven, set of specifications that standardized the construction and deployment of social applications. It provided a common programming and deployment model for Web 2.0 user interface components, for accessing social graphs, and for working with activities. Applications built to the OpenSocial specification could be deployed into any social network that complied with the specification.


In November of 2007, OpenSocial was launched. Independent developers finally had a framework they could use to build applications that would run in any OpenSocial compliant site. OpenSocial was quickly adopted by many traditional social network sites including MySpace, Orkut, hi5, and Ning. The population of end-users - the people running OpenSocial applications on various OpenSocial container sites - began to grow exponentially. In addition to a strong upsurge in the overall population of end-users, the OpenSocial global developer community also blossomed and quickly provided numerous new applications for these new OpenSocial containers to plug into their sites. The benefit to the community of social network providers was immediate - they now had a vast pool of OpenSocial developers from which to draw from in order to enhance their application offerings. Similarly, developers benefited by being able to deploy their applications to a variety of social network, and not just one targeted specifically.


As OpenSocial continued its fast paced growth in the first year, so did its evolution. In the early days of OpenSocial, its primary focus was consumer social networks. In mid 2008 however, an architectural enhancement known as the "REST APIs" was introduced in version 0.8 of the OpenSocial specification. [2] The REST APIs [3] provided a programmatic mechanism for integrating back end systems, a common requirement within enterprises. In 2009, as version 0.9 [4] was released, OpenSocial's overall end user population had reportedly reached approximately 800 milion. This number is based on the self reported end user populations of containers that now support OpenSocial. [5]

OpenSocial Architectural Concepts

Broadly speaking, OpenSocial defines two concepts. The first is gadgets, a component model based upon HTML, Cascading Style Sheets (CSS), and JavaScriptTM, that describes how content gets managed and rendered inside a Web browser. If you use sites like iGoogle, then you are already familiar with gadgets. The second is a set of APIs for accessing and working with social data. These APIs define how you access information about a person, their relationships, and their activities. These APIs are made available for use in gadgets, via a set of JavaScript APIs, as well as programmatically via REST. OpenSocial applications can take the form of gadgets that can be embedded into any container that supports the OpenSocial specification or traditional SOA services for integration. Taken together, the gadget component model, social APIs, and REST interfaces, provide a programming model that enables the creation of standards-based social applications.

OpenSocial Gadgets

Briefly, gadgets are small, pluggable "mini-applications" that are extremely easy to install in any Web page. In one form or another, the concept of gadgets has been around for some time. Portlets, as an example, have been part of the JEE programming model [6] for several years. In the Web 2.0 space, the OpenAjax Alliance has a component called a widget that is similar to OpenSocial's gadgets.
One of the most attractive qualities of gadgets is that they are a lightweight pluggable Web application components which are extremely easy to develop and can be employed in a multitude of ways. However, OpenSocial gadgets lend themselves extremely well to the social nature of the Web. It is very easy to share these applications via gadgets among connected people. Additionally, the OpenSocial specification defines basic lifecycle events that allow the provider of the gadget to understand and track how their application is moving among people. 

 OpenSocial gadgets are sometimes confused with Google Gadgets. This is due, in part to the term "gadgets", but also because they have a shared history. Google Gadgets have been in use by Google for several years, beginning with iGoogle. Because they were easy to build and deploy, Google Gadgets became widespread with thousands of third party authored applications quickly becoming available for install. With the launch of OpenSocial, Google donated the entire gadget technology to the community and a reference implementation to open source. The community naturally evolved Google's original contribution into what is now OpenSocial gadgets and added social APIs. [7] The combination of these social APIs and pluggable gadget architecture is what has led to the widespread adoption of OpenSocial technology in social networks around the world.


The core social APIs

One of OpenSocial's key goal is to enhance communication among people that are connected via a "social graph". In the traditional sense, a social graph merely consists of the "friend" connections that people already have. In an enterprise this could be people working on projects together or who have dependencies on one another to achieve certain goals or accomplish tasks.  For example, application developers need to work with database administrators (DBA) and systems programmers to get things done.  A developer cannot often promote an application change until the DBA has made database changes or the sys prog has made system or policy changes. Or alternatively, the developer can make changes without talking to the DBA that can have negative system impacts that are only discovered over time.  The patterns of collaboration codified in the OpenSocial specification greatly enhance communication within the connected social graph.  The DBA's and application developer's tasks can be achieved more efficiently and in a timely manner via collaboration built into the application.  The social graph in this instance offers specifics benefits to the business by mitigating potential performance impacts to the system. 


A simple example, in a business context, might be a managemer/employee relationship. Such business relationships (unlike the non-business types) could be 1-to-many and many such relationships are also asymmetrical (A could be the manager of employee B, however, the reverse is not true).


Figure 1: OpenSocial's Core APIs
Architecturally, OpenSocial enables this social graph by providing a set of social APIs that enable communication between people in three core areas:
  • People - allows for the retrieval of connected people from a specific person's point of view. For example this allows you to fetch a list of friends (connected people) of a specific person. 
  • Activities - allows for the passing of small messages to connected people. A common example is a status update. 
  • Data - is a multipurpose data API that allows for the sharing of data between connected people.

 Although relatively simple, these three APIs for social communications can be utilized in a wide variety of powerful ways - both in traditional social networking sites as well as in an enterprise's business contexts (see references for more detailed information on the APIs). The specification chose to be agnostic to the "kinds" of relationships. Additional semantics are left to the discretion of the implementor. This decision allows the industry to define these relationship types independent of the specification. Therefore, the OpenSocial programming model is just as applicable when accessing doctor/patient relationships as it is accessing those between manager/employee.

The REST APIs

As OpenSocial began to be widely deployed in consumer facing social networks, several new use cases emerged - the need to leverage and share the social data in other web sites, for example. A second use case involved incorporate existing services that provided social data through similar, albeit proprietary, APIs. Finally, supporting back-end business processes, automation, and management required a programmatic way to access this information systematically and declaratively, by using standard integration practices such as Web services.  To address these scenarios, OpenSocial introduced a set of RESTful services, which are referred to as the "REST APIs" or more precisely, the OpenSocial REST protocol. 

This new protocol was created to allow server-to-server communication of social data between different OpenSocial hosts or containers. This meant that OpenSocial applications no longer had to specifically run as gadgets, but instead could be created from any server-side Web technologies such as JavaTM, Ruby, Python, and so on. The primary benefit to the enterprise is more flexibility to leverage their existing server-side infrastructure to build and deploy standards-based social applications. For example an OpenSocial application can now be built following the best practices defined by Service Oriented Architectures, and implemented with existing JEE technology, including Java Server Pages (JSP), Java servlets, or other server-side technologies. The server-side technology simply uses the REST protocol to communicate with the OpenSocial container to fetch people data, to post activities, and to perform other OpenSocial functions. 

Another positive outcome of the investment in REST APIs within OpenSocial was a series of client libraries created and released as open source software. These utility libraries, which were published in most major server-side languages, including Java, PHP, Ruby, and Python, greatly simplified the process by which a developer could communicate with an OpenSocial container. The REST API also enabled access from mobile devices such Android [8] based smart phones. For secured communications to the server, OAuth, the dominant open source technology/specification for providing secure access to protected data on the Web, was integrated into the utility libraries.

OpenSocial in the Enterprise

Most enterprises host a heterogeneous mix of software from a wide variety of vendors, often pieced together to form working solutions. Even though many leverage standardized portal technologies, "on the glass" aggregation of content from multiple, disparate sources remains largely a programmatic task. Complicating matters is the fact that although many of the same concepts are represented, each product has its own unique API.  Because of this, cross-vendor portfolio integration is difficult at best, and at worst, nearly impossible. Irrespective of how they're developed, almost all enterprises are trying to achieve the following goals:


  • Aggregation: the ability to pull in content from other systems and applications. 
  • Customization: the ability to manage and control how information is generally organized and displayed. 
  • Personalization: the ability for the displayed content and applications to be further customized based on the user's personal profile and preferences, role and security privileges and other factors. 


Web 2.0 technologies have become popular in part because they focus on simple access patterns to get data (REST), and because they leverage easily accessible infrastructures to do so (HTTP and JavaScript). The value of Web 2.0 is that it provides a set of highly accessible components at a very low cost of entry that are deployable within existing infrastructures. As a result, this space has been evolving rapidly. Even as recent as 2007, there were over eight different Web 2.0 component models that could be used to build Web 2.0 applications. 


 OpenSocial's widespread adoption on the internet has led many enterprises to realize that the same programming model that is used to reach their customers, can also be used to integrate applications across key business partners and within their own organizations. As a result, OpenSocial is emerging as the dominant, vendor-neutral programming model for collaborative applications for internal and external audiences.


Why is OpenSocial Relevant to the enterprise?

Although OpenSocial has primarily targeted consumer social networks like Ning and MySpace, it holds great promise for accelerating social application development behind the firewall. Most on-premise enterprise systems lack support for the types of human-to-human connections — friending or following, activity feeds, gadgets, and component exchange — that most popular modern consumer web applications routinely demonstrate. Those that do offer this capability had to create their own APIs and programming model because at the time of their development OpenSocial did not exist. 


As OpenSocial is adopted by enterprise software vendors and incorporated in to their product offerings, it will accelerate the development of social features within individual enterprise applications, and improve interoperability of profile, activity and gadget data between other OpenSocial-compliant application containers. The alternative — hundreds of individual applications, each with their own proprietary implementation of user profiles, activity streams or gadgets — would create more of an integration headache for businesses and may impede the adoption of social capabilities as users flounder within the social silos each separate application maintains.


Beyond the benefits provided through the wide adoption of OpenSocial amongst enterprise software vendors, OpenSocial itself offers a number of benefits to enterprise consumers:


  • An open specification: OpenSocial is an open standard, with active contribution by some of the leading consumer and enterprise software organizations. The collective learning from each contributor helps advance the OpenSocial specification.

  • Easy for developers: the OpenSocial gadget specification is a simple specification to work with, relying at the most basic level on just HTML. It is well documented and used widely. Developers can benefit from a large ecosystem and build on the work of other developers, share their experiences openly through a wide variety of communities and open source projects. 

  • Designed for reuse: once a developer understands the specification, they can apply that knowledge to developing for multiple systems. Plus, thousands of gadgets already exist that can be instantly added to any OpenSocial-compliant container.

  • Minimizes vendor lock-in: OpenSocial minimizes lock-in to a single vendor by liberating any integration and development investments based on it. Gadgets written for one OpenSocial-container can be used in another OpenSocial-compliant container. Similarly, applications interface with social data through standards-based methods which allows applications to work together more easily and improves code portability.

How is OpenSocial being used today in the enterprise?

Because of OpenSocial's value as an infrastructure that provides social capabilities and improves interoperability through a "gadget" standard, to date it is mostly being used by enterprise software companies as a way to extend their products, add new social capabilities, and improve interoperability between their own portfolios and the portfolios of other enterprise technology companies. However, enterprises themselves are beginning to work with the standard to build bespoke applications — social intranets, portals, dashboards — in advance of commercial offerings, or because they prefer to build it themselves. A few examples are provided below: 

  • Alfresco®: the open source alternative to Enterprise Content Management (ECM), Alfresco has developed a document-centric collaboration solution called "Alfresco Share", that exposes its functionality as OpenSocial gadgets that can be aggregated into enterprise portals and other OpenSocial containers such as those offered by Atlassian, eXo, Google and others

  • Atlassian, Inc.: makers of the popular bug-tracker, JIRA, enterprise wiki, Confluence, and a range of tools for developers and development teams, Atlassian is using OpenSocial gadgets as a method of integration between its own products, and other OpenSocial-compliant containers, including ones on the Internet, like Gmail and iGoogle. JIRA and Confluence are both OpenSocial gadget containers and producers, and several other Atlassian products are gadget producers. The company offers demonstrations of its work with OpenSocial at http://www.atlassian.com/opensocial.

  • Cisco:Cisco Pulse™ delivers a powerful new way to harness the collective expertise of your workforce, making it quick and easy for employees to find the people and information they need to get their work done.  Cisco Pulse is using OpenSocial gadgets/API as a method of integration for applications within enterprise by taking advantage of standards-based OpenSocial Web Services APIs.

  • eXo Platform: eXo Platform's eXo Portal product is an OpenSocial gadget container, allowing its customers to add gadgets from external directories, like iGoogle, or from other enterprise products publishing OpenSocial gadgets, like Atlassian's JIRA.

  • Google: Google is increasingly using OpenSocial in its offerings and products, e.g., Gmail, so the specification will benefit from Google innovation and ingenuity. As Google looks for ways to evolve it to benefit large-scale, consumer applications like Gmail, iGoogle, or Google Wave, the specification itself will evolve. This will have downstream impact on enterprise systems using OpenSocial, whether it's a bug tracker or an on-demand CRM tool.  

  • IBM®: the company has been successfully innovating for years now in the area of browser-based component models, mashup tools and social APIs for the IBM Mashup Center and Lotus® Connections products. IBM is enthusiastic about OpenSocial, tracking it closely and actively working with the community to evolve the specification to help meet our customer's enterprise requirements, and to interoperate with IBM iWidgets and OpenAjax Alliance technologies. IBM Rational® is working to enable use of OpenSocial gadgets in it's Jazz-based software development and Application Lifecycle Management products during 2010. You can track progress on this effort at http://jazz.net. In addition, IBM's Lotuslive offering already makes use of OpenSocial.  Several internal integrations use it and the Lotuslive team is actively working with partners to allow them to extend the Lotuslive platform using OpenSocial.

  • SAP®:  Enabling 'best run' business processes is SAP's core expertise.  SAP is working in-house and with our ecosystem to provide state-of-the-art technology that social enables our customer's businesses, and their business networks.  12sprints, one such system from SAP, is a real-time decision making tool with collaborative features that brings the right people together with the right information, and provides pre-defined interactive decision making tools to rapidly drive their business forward.  The OpenSocial JavaScript and REST APIs provide a framework for the 12sprints APIs, both for building new decision-making tools and for communicating with the 12sprints container.  The SAP Social Network Analyzer (SNA) is another component in SAP's social composite.  SAP’s approach is to work with the OpenSocial standard and the OpenSocial community to better align our solutions with both API specifications, provide concrete feedback to the community on enterprise requirements, and contribute to the further innovation of the specification.

  • SocialText: the most recent version of SocialText's popular collaboration platform supports OpenSocial gadgets. SocialText used the Gadget container as the basis for their Dashboard module, which lets individuals personalize and administrators customize a tailored interface for collaborative work.

Keep in mind that this list represents just a sampling of enterprise companies who are now in a position to go public with their efforts to date with OpenSocial. There are definitely other enterprise companies currently working and prototyping new technologies with OpenSocial that are yet unnanounced.

Enterprise Considerations

To date, enterprise considerations for OpenSocial have been driven largely by enterprise software vendors interested in or already using OpenSocial. Discussion initiated at the Google IO conference in 2009 with representatives from Atlassian, eXo platform, IBM, SAP, Oracle, and SalesForce.com. Since then the discussions have expanded to include CubeTreeTM, Lockheed, SocialText, Cisco, and Alfresco, and it is a collective hope the group will grow.

Applying OpenSocial within the enterprise introduces variations to the original requirements and different use cases than those anticipated by the original authors of the specification. Below we'll cover familiar enterprise considerations in the areas of manageability, interoperability, portability, security and tooling. We'll also discuss a new use cases that needs improved support in OpenSocial - group collaboration - describing each one briefly and exploring how the OpenSocial specifications may evolve, or how vendors might develop specific products and services, to address them.

Manageability

It is becoming more commonplace for users to be able to "mash up" content from services outside the direct control of the enterprise. Today, much of this content is isolated — each gadget represents a unique, distinct application. However, enterprise mashups have the requirement for a much more rich integration between the gadgets within the browser. 

This has broad implications for management strategies. For example, managing the performance characteristics of an application can be easier when all of the content is delivered from a single source because understanding the volume and usage patterns can be determined by instrumenting and monitoring the applications. In the Web 2.0 space, there are no defined manageability metrics or APIs that can be implemented to enable effective end-to-end problem diagnosis. For example, how would a container report management information back to the providers of gadgets? If there was a standard mechanism to do this, what information is most relevant and important? 

Another example is the protection of an enterprise's content. One of the most valuable asset of an enterprise is its data, which takes many forms and is governed by corporate policies and, in many instances, by governmental regulations. There are serious consequences when these policies, rules, and laws are violated. Enterprise software vendors who offer OpenSocial implementations must have mechanisms for monitoring and logging all content changes and interactions, decommissioning users, auditing, flagging violations and, in some cases, removing any offensive content. Being able to reconstruct an audit trail is often a key compliance criterion required to achieve certification from government agencies.

Achieving this level of management in a world of highly distributed, dynamically aggregated, situational applications is a complex and difficult problem. OpenSocial has defined lifecycle events for social gadgets. Using these, implementors can request the container report when and why an application is added and removed. However, support for gadget lifecycle is not consistent across containers and the initial design points for these events were not based on enterprise management use cases. 

As OpenSocial evolves, strategies for enterprise management will emerge and will be included as part of the specification. These strategies must work seamlessly with existing management infrastructure that enterprises have deployed. Since enterprises use a variety of tools and techniques to monitor and manage their web applications vendors that offer OpenSocial implementations should design, test, and certify that their offerings work with those tools and techniques.

Interoperability

Enterprises have been working on strategies to aggregate content from a number of disparate sources for some time which has resulted in a variety of browser based component models. Many of these components are "home grown" or "one off" solutions. Others are part of an integration and extension strategy provided by enterprise vendors (e.g., IBM's iWidgets). The current state of the art in enterprise web application development often involves highly interactive browser-based user interfaces that are often composed of components that interoperate via eventing. The proliferation of different kinds of browser components makes it very difficult to build this kind of interactive mashup where the components share information with each other in a secure manner.

Several years ago, OpenAjax Alliance (OAA) [9] was started to help address the issue of interoperability between gadget models. One key piece of technology that has been developed is the OAA Hub [10], which is a set of JavaScript that provides secure communication across AJAX libraries and components on the same page. Recently, the enterprise OpenSocial community has begun to work directly with the OpenAjax community to integrate their Hub technology (see Security section). From a specification standpoint, this work is targeted for the first release after 1.0, but we expect code and prototypes to be available via open source so this can be used by early adopters. 

By focusing on interoperability and working to ensure components running inside the browser can securely communicate with each other, enterprises can effectively manage the rate and pace of adoption of new technologies. This allows enterprises to control costs by balancing investments in existing strategies and adopting new technologies based upon business need.

Portability

One of the primary motivations for the creation of OpenSocial was the "write once deploy anywhere" approach for social applications. One of the promises of OpenSocial gadgets is to have consistent Web 2.0 deployment model. While significant steps have been made as the specification evolved, we're not quite there yet. It remains difficult for a gadget of any complexity to simply be deployed across multiple sites primarily because of subtle discrepancies between containers. 

The OpenSocial community has begun to address these issues in the 1.0 version of the specification. In addition to clean up and clarification of many of the APIs and data models, a new compliance model has been introduced. This will make it easier for sites providing OpenSocial capability to declare exactly what they support. Likewise, it will be easier for developers to target a specific set of functionality. Mechanisms have also been put in place to allow the gadget to declare a minimal set of capabilities of the container as defined by the specification version. 

As OpenSocial starts to become an integral part of integration and collaboration strategy between enterprises it is imperative to achieve consistent behavior across implementations. We look to further improve interoperability by increasing the coverage of test suites and test gadgets, providing more "sandboxes" for testing, and continuing to refine and mature the OpenSocial specification.

Security

Like portability, security is not an enterprise-only issue but there are some enterprise specific considerations in this area.  Security issues common to web applications such as malicious code and cross-site attacks take on special significance because of the sheer quantity, legal protection required, and sensitive nature of enterprise data.  As the OpenSocial specification begins to take into account interoperability between component models such as iWidgets, and provide gadget-to-gadget communication via eventing, security will take on new heightened meaning since gadgets become more pervasive targets for malicious code or cross-site attacks.

Malicious Code/ Cross-site attacks

Malicious code or cross-site attacks can lead to an attacker stealing user sessions, user ID's and passwords, credit card information or other personal information.  If a web-site doesn't check for this kind of malicious code via certain mechanisms then personal data will be compromised.  One such way to handle these kinds of attacks is to provide a logical sandbox model of security that isolates gadgets on a page.  


As an example, IBM’s mashup technology ensures enterprise-level client-side security via use of the iWidget component model and tunneling through iFrames between main window events and the widgets on a page. Communication then between widgets happens through eventing and gets processed through the OpenAjax Alliance (OAA) Hub runtime component.  


The widgets are generated with their own subdomain by a proxy and are thus isolated from resources such as DOM elements and cookies.  The widget is thus generated in its own iFrame and because it has its own subdomain it cannot access its parent or other resources.  The OAA Hub provides much of the processing for this security.  As mentioned earlier, work is currently underway for the OpenSocial spec to adopt the open source OAA Hub to meet these kinds of enterprise level security requirements.


In addition, allowing users to install and run 3rd party code within a web application is a security risk. The OpenSocial specifications and implementations are designed to prevent and limit the damage that a malicious gadget can do. Additionally, we expect that enterprise software vendors that offer OpenSocial implementations will provide ways for an administrator to control what gadgets are allowed to be installed in an OpenSocial powered site.

Privacy

Enterprise users have some of the same considerations as typical social network users when it comes to privacy.  Enterprise users, like regular social network users, are concerned about access to data they consider off limit to others and want a certain level of control on the data they share with their network. Additionally, enterprise social network users also have to consider corporate policies, rules, and government regulations in this area. 


This is an area where some additional work may be necessary in the OpenSocial specification. We anticipate that enterprise software vendors that offer OpenSocial implementations will differentiate by offering fine-grained privacy controls that comply with appropirate rules and regulations.  However, we are also contemplating proposed extensions that will attempt to provide a common means to address: fine-grained user-level access control to data, limits on what data applications can access on behalf of users, as well as clear understanding of the extent of propagation of shared data. Currently using the profile access mechanisms and the REST API some of this privacy construct can be implemented by applications and containers.  The OpenSocial specification mechanism and process allows such important concepts to evolve in a grass root fashion while also be provided via a peer-reviewed, useful, and meritocratic fashion. 

Tooling

Parts of OpenSocial Gadget and application development are covered by existing tools for HTML, JavaScript, and RESTful service development, but there are gaps. Some of these gaps can be addressed by tool vendors who, we anticipate, will build special tooling to support the needs of OpenSocial developers. Others should be addressed by extending the OpenSocial specification. To better understand the tooling needs, let's look at the roles involved in OpenSocial Gadget and application development. 
  • Application Developer — Builds an OpenSocial Gadget by authoring an OpenSocial Specification file, an XML file that can contain HTML, CSS, and JavaScript code along with references to JavaScript libraries and other resources. Also creates backend services required by the Gadget, a set of RESTful services protected by OAuth; needs tools to help automate Gadget development, deployment and debugging.

  • Application Deployer — Manages the deployment of an OpenSocial-enabled solution. This may include deploying the Gadget Specification file, deploying the RESTful services that the Gadget requires, registering the Gadget, and managing the OAuth keys that the Gadget uses to call its services; needs tools to help automate deployment of both Gadget and services.

  • Mashup Assembler — Combines Gadgets, custom-code, and web services together to create a new application, known as a mashup, for a specific set of users. This type of developer may have limited programming knowledge and needs a tool that allows the visual drag-and-drop of Gadgets from a palette and wiring them together.  This role could either be an IT one but could also be a line-of-business (LOB) role such as a business analyst.

  • System Administrator — Manages an OpenSocial enabled web application and the gallery of Gadgets available, may manage Gadget white/black lists, OAuth keys and may review newly submitted Gadgets for inclusion. 

Enterprise developers typically expect an end-to-end tooling solution; one that supports Gadget and service development, allows a developer to press a button to have his OpenSocial Application automatically deployed and supports debugging. If tools are to support automatic deployment, then we will need an OpenSocial extension, an API that supports Gadget deployment and/or registration. Although there is the start of OpenSocial tooling available via open source, more work is necessary in this area. At present, we have not defined any specific proposals for supporting an end-to-end solution. 

Support for Group Collaboration

Group collaboration, shared spaces and communities are common concepts in enterprise collaboration software and are also important in consumer-oriented social networking. The notion of a group does exist in OpenSocial and it is possible to request a list of available groups and to request users and activities within a group or set of groups. However, this does not go far enough for enterprise applications and we anticipate efforts to improve the specification in the following ways:

  • Group Profiles: Groups have titles, descriptions, charters, slogans, logos and other properties. The OpenSocial specifications should be enhanced to support the common properties that are associated with a group. Groups may also have shared resources, so it may also make sense for Groups to have Media Albums just as individuals can.

  • Group Gadgets / Preferences: A Group typically has a homepage or possibly a Shared Dashboard of Gadgets that are preconfigured by the Group owner to show information that is relevant to the group. The OpenSocial specifications should be enhanced to support Group Gadgets.

Predictability

Despite the rapid growth of software as a service, and cloud offerings, enterprise vendors still deliver products that will be installed behind the firewall in large data centers. This kind of delivery model requires longer lead times. Working backwards into testing and development, code needs to be "frozen" much earlier in the process. As enterprises consume more and more open source code to include in their offerings, this code too, must be released at a stable point. This puts pressure on OpenSocial to define and provide a stable specification that can be implemented in a reasonable time frame so that it can be consumed by "downstream" open source projects and enterprise software vendors.

OpenSocial has intentionally put in place an agile development process for the specification. It's modeled after many open source projects where development consists of short iterations with a well defined scope. When a new feature is submitted, it's required to have a working prototype that can demonstrate the concept and prove that it can be implemented. This approach has many advantages: it encourages rapid evolution of the specification, promotes involvement from the entire community, and promotes shorter cycles between a proposed feature and broadly available code.

In addition to the specification, many vendors that are providing OpenSocial support are leveraging open source code. One popular project is Apache Shindig. This project is a great starting point and provides much of the plumbing required of an OpenSocial container. Shindig, like many open source projects, grew very rapidly in an organic fashion, in part because the entire social networking space was exploding. The OpenSocial community is working to provide clarity and consistency in the OpenSocial specification and we anticipate Shindig and other related projects will follow suit. For example, OpenSocial 1.0 will provide a cleaner definition of compliance. Delivering open source code that matched only the level of compliance you required would lead to increased consumeability and broader adoption of the project. This would also lower the barrier of entry for enterprises to allow their developers to participate in open source projects.

From an enterprise perspective, we look to improve this approach by working to achieve more predictable release cycles of the OpenSocial specification and related open source projects. There are several successful open source projects that produce an integrated set of deliverables on regular schedule. The Eclipse Foundation [11] has for several years, through efforts such as Ganymede [12] and Galileo [13], coordinated the "simultaneous release" of multiple projects. This regular delivery cycle provides a level of predictability that enterprise vendors need in order to plan their development and release cycles. This has the added benefit of ensuring that the capabilities defined in the specification follow an expedient path into the enterprise. Ultimately, this will grow the development community and vendor ecosystem, broaden the spectrum of enterprise ready gadgets, and accelerate the adoption and advancement of OpenSocial.

OpenSocial's Vibrant Ecosystem

Fundamental to the success of any open platform is an ecosystem that fosters new ideas and collaboration, works transparently, and maintains low barriers to entry so that all may participate. The OpenSocial Foundation [14] established these as core tenets when the it was chartered. Perhaps there is no better example working illustration of these beliefs than the OpenSocial Development Process [15]. 


Contrary to many specification processes, OpenSocial has placed an emphasis on a highly agile, community-centric approach. The focus is encouraging new ideas, building consensus around them, and finally, demonstrating they can be implemented. In fact, the creation of a new version of the specification is treated in much the same way as application development, with a short timeline, well defined scope, working prototypes, and a full review prior to publication. 


There are, however, some very unique characteristics of the OpenSocial development process. For example, because it was important that OpenSocial be developed by a community, all proposals need to have the support of at least five community members. To ensure that no one person or company can dominate the specification and essentially "rubber stamp" their approach, each proposal must have no negative votes. 


The OpenSocial community is also working hard to encourage continuous integration. While the specification process defines how to incorporate new capability, there is work underway to refine how extensions can be incubated. The main goal is to provide a structure in which new ideas can be worked on collaboratively in an open transparent manner. This allows the inventors to refine their ideas, build consensus and validate their implementations, prior to a new version specification actually being "open" for submissions. 


Finally, as with any specification, it is important to have accountability to maintain a clean intellectual property record. As part of the specification process, the OpenSocial Foundation requires that both individuals and corporations agree to a contribution licensing agreement, as well as a non-assert agreement. These documents, when executed by members of the community, assure companies that implement OpenSocial have the necessary legal protections, which in turn, makes widespread adoption of the specification possible.


The OpenSocial Foundation

Although the original community of people behind OpenSocial had strong similar vested interests in its overall success, the continued evolution and adoption necessitated the formation of a more formal body to hand OpenSocial's continued growth and evolution. To that end, in late 2008 the OpenSocial Foundation (OSF) was created. 


The new OpenSocial Foundation was chartered with the mission to "sustain the free and open development of OpenSocial specifications." (www.opensocial.org) Membership in the OpenSocial Foundation is on an individual basis and free and open to everyone. To protect implementers of the specification, the OSF established a set of governing intellectual property rights that cover all contributions to the specifications by OpenSocial members. 


Because the OpenSocial specifications and their associated reference implementations are defined and driven through open, community-oriented processes, this ensures no one company, including those that founded OSF, can control the specification or the implementations. With the ground work in place, OpenSocial has under gone some very rapid growth. Today, with the noted exception of Facebook, the majority of social network providers support the specification. OpenSocial empowers social application developers by reducing development costs, enabling rapid development, and expanding the reach of their technology. Broad industry adoption, a vibrant developer ecosystem, open governance models, combined with a well defined component model and a programming model for social constructs, form a solid foundation to bring enterprise applications to the next level of community and collaboration through support and adoption of OpenSocial.


Open Source Initiatives

Apache Shindig - An OpenSocial Reference Implementation


Complementing the community that defines the specifications are several open source projects. The most notable one is Apache Shindig, which serves as a runnable reference implementation of the OpenSocial specification. At its core, Apache Shindig is compromised of several components that enable gadget rendering as well as people and social data management. Shindig is currently an incubator project governed under the Apache Software Foundation and although it serves as a code foundation to numerous commercial social networking sites, it has its own distinct development process, membership requirements, and software licenses. 


Today there are currently two primary implementations of Shindig which are in Java and PHP, and both are judiciously maintained by its development community. The majority of today’s commercial social networking sites and commercial products have successfully used Shindig as the foundation for their offerings, e.g., hi5, Orkut, Ning, Atlassian, LinkedIn, Netlog, along with numerous others. 


OpenSocial Frameworks 


As Apache Shindig provides the plumbing that enables OpenSocial implementations, it's arguably still a very low level technology. In this respect there are several notable projects that build on top of Shindig and serve as a higher level, more complete social application example. These include the PHP based Partuza (http://code.google.com/p/partuza) and the Java-based Apache SocialSite (https://socialsite.dev.java.net), which is in the process of entering the Apache Incubator.


OpenSocial Client Libraries 


Another important set of complementary libraries is the OpenSocial client libraries. It supports the REST protocol and greatly simplifies the coding required to fully utilize these protocols. The libraries are currently available in multiple languages including Java, PHP, Python, Ruby, and Objective-C. They are hosted at multiple locations for each language and typically follow the pattern: http://code.google.com/p/opensocial-<language>-client/, e.g. http://code.google.com/p/opensocial-php-client/, http://code.google.com/p/opensocial-java-client/ and so on.


OpenSocial Tooling


The OpenSocial Development Environment (OSDE) is an Eclipse project created to help developers quickly and easily build and test social applications. The OSDE includes a form based editor for creating gadgets and an "individual SNS [Social Network Site]" that is used for unit testing new gadgets. This tooling includes not only the ability to create and edit gadgets, but also integrates the Java client libraries to enable developers to build OpenSocial client applications. This project represents the first, and so far only, IDE that tries to create the end-to-end tooling solution.

Conclusion

As you've no doubt noticed in recent times, the social networking explosion in the consumer space has radically transformed how people communicate, and interrelate socially. Since its launch in 2007, OpenSocial has also played a major role in this explosion by offering a standard set of technologies that are entirely managed in an open manner by the community that it serves.

In a business context, the social element has always been fundamental to doing business since the dawn of commerce.  As this paper clearly illustrates, the work of transforming OpenSocial into an enterprise business compatible technology is an ongoing process. This paper does however serve as a clear example of how key companies such as IBM, Atlassian, Cisco, CubeTree, Jive, Oracle, SAP, SocialText, along with others, are now fully engaged in this task and now fully utilizing OpenSocial's own processes for evolving towards a more enterprise business friendly technology. This speaks to the inherent wisdom of how the OpenSocial process for continued evolution was created, for it is done entirely in an open and constructive manner where all parties have a vested interest in seeing OpenSocial continue to evolve to better serve their needs. Finally, this paper serves as a call to action for other enterprise software providers to engage in this dialogue and continue to help OpenSocial evolve towards an evermore enterprise business compatible technology.


Credits

This white paper represents a combined effort from a diverse group of dedicated individuals. 
Contributors, in alphabetical order of company name:


Alfresco Luis Sala (luis.sala); @alfresco.com            
Atlassian Mike Halvorson (mhalvorson), Jay Simons (jay); @atlassian.com 
Cisco Thangam Arumugam (tarumuga); @cisco.com 
Cubetree Navin Budhiraja (navin); @cubetree.com 
Google Chris Schalk (cschalk); @google.com 
IBM Tyrone Grandison (tyroneg), Tracy Hutcheson (tracyhut), David Johnson (dmjohnso), Michael Maximilien (maxim), Mark Weitzel (weitzelm); @us.ibm.com 
SAP Laurent Bride (laurent.bride), Robert Horne (robert.horne); John Mayerhofer (john.mayerhofer), David Meyer (david.meyer); @sap.com
SocialText
Gabriel Wachob (gabe.wachob); @socialtext.com



References





Quick Links

Getting Started

Articles & Tutorials

API Reference

Discussion Forums

Client Libraries

Specs

Enterprise

© 2010   OpenSocial Foundation

Badges  |  Report an Issue  |  Privacy  |  Terms of Service

Sign in to chat!