Shonzilla, a pattern-seeking animal

Sat Apr 25

OpenSocial interoperability with web 2.0 applications

A discussion recently started by Harry Hübner and commented by Christopher Blum in OpenSocial Interest Group I’m moderating over at XING, led me to a conclusion:
Supporting various applications (either web 2.0 or headless server functionality) inside an OpenSocial container can create more traffic (and revenue if they’re commercial) for application’s developers.

(Caveat: the conclusion is currently based on theory alone but sounds perfectly plausible once you read my explanation.)

Here’s my attempt to stand on Christopher’s shoulders and go into more detail. His proposition of “OpenSocial interoperability” by bringing various popular [web 2.0, headless] applications into OpenSocial containers is one of the ways to get more traction and traffic by using OpenSocial, which in turn could improve perceived interoperability.

This kind of interoperability can be best achieved using OpenSocial REST API which enables application’s home server to access selected OpenSocial container functionality. In this case, best-of-breed and widely adopted technologies are used: HTTP protocol for invoking container’s entry points and JSON for encoding data (read or written).

BTW, headless application can be any functionality on some server that runs or can run without a UI. For some examples of headless applications consider a Jabber or IRC server. You can let your imagination run free once you realize that this headless application can also be (almost) any application running in Amazon EC3, Google App Engine and other clouds. I’m wrote “almost” in parenthesis to include only those apps that understand REST, i.e. speak HTTP and understand JSON.

In more detail and related to OpenSocial, the scenario I’m supporting is the following:

using OpenSocial REST API to enable application’s home server read from and write into OpenSocial container to improve integration of application’s core functionality (running on server) by accessing OpenSocial data items like Person objects (e.g. users of XING, Orkut, MySpace, etc.) and AppData objects (which encapsulate all the specific object types relevant to the application’s core functionality). Using Person and AppData objects on home application’s server improves “social-awareness” of that application. Another part of this scenario is:
using OpenSocial Gadget XML and Gadget API to display socially-aware application’s data (accessed inside an OpenSocial gadget

Note that either part of this scenario or both 1. and 2. can be used to improve application’s interoperability.

In using part 1 of this interoperability scenario, the initiative for improving social-awareness of a popular application by using REST API to connect to OpenSocial container is in the hands of the original application’s developers. In the case of open-source application projects, there are less impediments and objective reasons not to connect open-source applications to OpenSocial container and, through it, all the users using the app. This way, data is not only more socially-aware but also more pervasive when part 2 is used.

When using part 2, application data is embedded into a “personalized web panel” running inside OpenSocial container thanks to Gadget XML, Gadget API and different features-specific APIs that are optionally supported by the respective OpenSocial container. The most interesting feature (i.e. OpenSocial JavaScript API namespace) is RPC feature (which stands for remote procedure call) that an OpenSocial container may implement (since it’s an optional API) to provide gadget-to-container, container-to-gadget, and gadget-to-gadget communication.

The final result of this interoperability scenario is better data availability and more convenience to users which can lead to an increased [web 2.0, headless] application’s usage.

The most prominent example of increased usage thanks to implementing OpenSocial (albeit implementing the entire OpenSocial container is more work than previous scenario) is Plaxo Pulse which got an order of magnitude

Sun Feb 3

MySpace about to get serious about OpenSocial

MySpace Developer Program

A couple of days ago MySpace announced receiving pre-registration to their MySpace Developer Program a.k.a. MySpace OpenSocial beta. This is the greatest news coming out of OpenSocial community since it has been made public in November 1, 2007.

For those geeky enough to have heard of OpenSocial - it is an open standard that will enable web-based applications akin to Facebook application to show on any social networking web site (or any web site for that matter) data that are related to you and you choose to display. By data I mean anything, your photos, your favourite movies, your night life recommendations,

You-know-who competition

This move by MySpace (i.e. News Corp) comes as especially improtant as Facebook is planning to increase their stronghold on the market by syndicating Facebook apps (i.e. allowing Facebook apps and your data shown in them to appear on your personal website).

Friend, pokes, funwalls - OK, now show me the money

All the Generation Next’s favourite online games like broadcasting funny videos, tagging friend’s photos, instant messaging for everyone to see, exchanging pokes and what not - they’re all fun for users of social networking sites and social utilities. The question is why and how can these be profitable to these “social containers” and social application developers, or in other words: where’s the money? Especially interesting is how MySpace’s foray into OpenSocial will earn money for those creating OpenSocial apps and therefore MySpace itself.

It’s hard to tell anything specific. I do not know much and I bet MySpace doesn’t either. ;-)

What is apparent, some players from the Facebook ecosystem (Max Levchin’s Slide) are getting heavily valuated, so there’s fire behind the smoke curtain.

Not much choice

I guess it will necessarily be an ad-based revenue model. It is all about getting more eyeballs, more time spent on the site and ad rolls trying to attract customers while trying to be more relevant and trying to increase conversion. OpenSocial support is supposed to lower the barrier of entry for a tidal wave of applications that will make you spend more time on MySpace.

In my view, Facebook currently has by far a more consistent user experience and application ease-of-use which translates into Facebook’s immense valuation in the market of social networks/utilities. That is Facebook main value proposition to everyone - user, developers and future investors.

OpenSocial needs to iron out many technical hurdles in order to make it easy for significant number of developers to jump ships. In the case of MySpace, it will need to work actively with developers taking part in the MySpace Developer Program while ironing out their revenue model. Being a big company, MySpace (i.e. News Corp.) will almost certainly do both things at the same time, which always proves to be tricky as in such cases target (market and revenue model) is moving even more quickly.

Future, if any and the best way to predict it…

At the end of the value chain are the big name contracts (i.e. the true OpenSocial customers) which will come if OpenSocial makes it easy to develop and safe to use OpenSocial applications.

Also to have in mind is Google Social Graph API, that could be a part of the future online social networking puzzle.

Cards, some of them, are on the table and more chips needs to fly in for the greater developer community to jump the OpenSocial ship.Currently, OpenSocial is something to play with and MySpace Developer Program I expect to be a much better far-less-buggy environment then Orkut Sandbox.

Fri Nov 2

Google OpenSocial API premature review

This short review has been based on an early sample using the inofficial release of long-awaited Google OpenSocial API. Thanks to Gaurav for pointing it out.

The sample is a mash-up of a MySpace page and author’s Flixster account using OpenSocial API. Better said, parts of it. I’ll explain why.

What can be learned from this sample is that OpenSocial API is a JavaScript library. The above sample uses (probably) a partial OpenSocial API core that is squeezed in a single JavaScript file (peculiarly called Person.js) together with some Google general-purpose JavaScript utility classes and methods. There are two other files (MySpaceContainer.js and MySpacePerson.js) that implement MySpace-specific Open Social connectivity.

From the OpenSocial part, what can be noticed is the concept of Containers. Yesterday, Marc Andreessen of Ning and Netscape fame wrote about Containters and Apps. Therefore, Apps is missing, which is might make sense at this early stage because this example does not require generic App connectivity (i.e. full-blown OpenSocial API that is able to interoperate with several applications since only Flixster is used here).

The following concepts can be noticed in this early sample:

Person - central concept of a Container user (i.e. social networking system account)
Container - (partially) open window to social networking system itself
DataRequest - this is where the most of interesting interaction between Containers can be seen (dealing with Persons, Groups a.k.a. friends, ProfileDetailTypes, FilterTypes, new friend requests etc.)
Activity - action that can be performed from inside Container with any of the Apps (that’s my assumption)

The main action involves MySpaceContainer, while interaction happens using DataRequest and DataResponse JavaScript classes that encapsulate you-guess-what.

For now, I’ll avoid going deeper since its 2:15am in Belgrade now and I expect/hope an official OpenSocial API together with documentation will appear online.

Conclusions:

First impressions are that OpenSocial API itself, the JavaScript code, seems intruiging, conceptually correct and in line with the expectations. It does allow rather clean interaction between different Containers and Apps.
What is evident - Google has definetely done a great PR and extremely quickly crossed the tipping point by getting strong partners on their/open side of the fest.

MODIFIED (Nov 2, 9:15): Now it’s sure - the offical name is not Open Social (as Marc Andreessen was writing) but it’s a developer and search engine-friendly one word OpenSocial. :-)