A few weeks ago, Gabe Wachob and I attended a meetup at Google HQ in Mountain View about Enterprise OpenSocial. It was a good time to take stock of the progress of OpenSocial in the Enterprise.

Where we started

Last Fall, when we launched Socialtext 3, we made a big bet on OpenSocial, a standard designed to make application functionality run across multiple websites. With hundreds of thousands of Google Gadgets, a developer base as wide as the internet, and a straightforward model for adding new ones, OpenSocial appeared to be a major advance over proprietary tools for creating extensions, and over heavier-weight standards that had relatively low adoption.

From beginning, Socialtext bet our company on the adoption of Web technical and social architecture in the enterprise, and OpenSocial looked like the next step. We used the Gadget container as the base for our Dashboard module, which lets individuals personalize and administrators customize a tailored interface for collaborative work. Other layers of the OpenSocial standard, including OAuth, the social graph and profile representations were less easy to fit into an enterprise environment. We chose to wait until there was more to build on in these areas.

Widget adoption

For Socialtext, the use of widgets (as we call them, following the common industry terminology) has been a big success. Customers – including large enterprises – have developed their own OpenSocial gadgets to provide corporate data for business users, in the context of their collaborative workflow. Customers are using a wide variety of available widgets. When customers are interested in some small tool, chances are really good there’s a widget available for it.

State of the industry: all about Gadgets

The meeting had representatives from Google, IBM, Cisco, SAP, Oracle, Atlassian, Afresco, Exo, and Lockheed Martin. As with Socialtext, the bulk of the OpenSocial development in the enterprise to date centered on the use of the standard and framework to develop widgets for business dashboards. The alternatives are JSR-168, the Java Portlet standard, and SharePoint web parts, with custom development within the SharePoint stack.

Regarding gadget development, there was a lot of discussion about standards conformance and portability. There was discussion about developing a conformance suite (including test widget, backend, rest api implementation), in conjunction with the upcoming 1.0 of the spec (the next step was discussion on the OpenSocial mailing list)

There has been little adoption of other aspects of the stack, but a lot of interest. At the the meeting, we discussed aspects including: activity streams, friend representation, authentication, authorization.

The conversation centered on changes to OpenSocial that will make it a better fit for the enterprise.

• OpenSocial is planning to incorporate the ActivityStrea.ms standard to represent activity. The standard has a well-developed draft, and has already been implemented by Facebook, MySpace, Windows Live, and Opera. An important next step there is a JSON representation of ActivityStrea.ms content. The Enterprise group agreed to have representation in ActivityStrea.ms (disclosure, that’s Ryan Boyd of Google and me).
• The definition of “friend” was updated to make it clear that it supported relationship definitions that make sense in the enterprise. The language about the “friend” representation the standard covered the symmetrical relationships that are common in consumer applications such as FaceBook and MySpace, and business applications that deal with loose ties, such as LinkedIn. But the symmetric friend model makes less sense within the enterprise. What does it mean to ask to be friends with a corporate VP, or for your boss to ack to be friends with you? The asymmetric model used by Twitter, where each individual chooses people to follow, to manage their own attention. It wasn’t clear to the folk at the meeting – including the people from Google, that the Friend definition could actually be used to cover the asymmetric friending suitable in the enterprise. We updated the definition to make it clear that asymmetric friend lists were acceptable within the standard.
• Single Signon and Security. Security and trust models are not well agreed upon or understood by the vendors. There was lack of shared understanding about how or whether to use OAuth, and how authentication and single signon might work with a multi-layer model including gadget contents, container, application server, and corporate directories. In particular, there was a lot of discomfort with the assumption that the container (server side) could hold tokens for widgets to use to access external apps on behalf of a user. One person from Cisco said that they could basically not do that at all. The next step is for the conversation to continue on the OpenSocial mailing list.
• Intergadget communication. There was a fair amount of interest in intergadget communication, in particular the relationship between work done by the OpenAjax alliance and Google’s work on pubsub. Mark Weitzel of IBM has the ball to submitting a spec proposal on this topic.
• Other technical development. There are ongoing development efforts with technologies such as Google secure data connect (which can be used for tunneling through firewalls), Shindig (the opensource server and client reference implementation of OpenSocial), and Caja (sandboxed JavaScript). The next step is for Chris Schalk of Google to arrange webinars on SDC, Shindig, and Caja development.
• Web standards are gaining adoption in the enterprise, and more information is needed for enterprise developers about the benefits and options available to them. The group took on a task to write a White Paper on OpenSocial in the Enterprise (Disclosure: Gabe Wachob is one of the authors)

The Enterprise developer perspective

In a room full of vendors, the most interesting presentation was Shawn Dahlen and Chris Keohane at Lockheed Martin, about how they were actually rolling out OpenSocial as part of Enterprise 2.0 initiatives in their organization.

Dahlen and Keohane reported on some very interesting learning experiences. The main lesson was that one size does not fit all. The initial strategy centered on SharePoint, but they found in practice that SharePoint is good for group document management and little else. SharePoint platform development turned out to be time-consuming and resource-intensive – Gadgets were a lower-cost, platform-indepentent way to extend a shared platform. Policy also needs to be tailored for the group and the use – the HR department did not want its employees to create sides, but the IT and R&D groups strongly encouraged employee-generated sites and content. Since one size does not fit all, they need lightweight solutions that tie multiple systems together with portability.

Meeting Notes

Meeting notes taken by group members at the session can be found here:

See you at Enterprise 2.0

I’ll be talking about OpenSocial in the Enterprise at the Enterprise 2.0 conference coming up in November, and hope to see you there!