metal & gin | (a weblog by craig t mackenzie)

Today I attended a Google Developers breakfast to learn about one of Google’s latest tool for developers. The event went swimmingly and the focus was on their brand spanking new API, “OpenSocial”. The seminar was (obviously) focused mainly at developers and therefore this post is very much from a developers point of view.

What is Google OpenSocial?

Google OpenSocial are two sets of API’s; one for developers and one for owners of social-oriented websites. They facilitate with the development of building “Social Applications” for a variety of social networking websites. The basic premise is that me as a developer I can learn one API (OpenSocial) and use my knowledge of that API to build social-oriented applications for any website which is an OpenSocial “container” (has implemented the website owner version of the OpenSocial API).

The developer API consists of standard’s based xHTML + JavaScript. This is brilliant news as anyone who’s anyone knows these languages like the back of their hand. The API’s allow easy access to common social-network oriented data such as users, users friends lists, the “social news feed” and other social-graph data. The API also allows you to store small amounts of data on Goolge’s servers (such as key/value pairs) meaning that you could (in theory) build an application without having to serve the application yourself (great news if your app become popular)

Why is this Important?

The OpenSocial API’s are Google’s first steps into what they see becoming a far more landscape altering change. In recent years the web has started to evolve into a very user-centric ecosphere. People are choosing how they want to consume the information they are interested in, when they want to consume it and how they wan to share it. Take for example technologies such as RSS, widgets/gadgets and customized home-pages. These are all perfect examples of what is happening, users no longer have to visit a particular site or service to get the information they want. It is now delivered to them, ready for them to consume.

Now if you look at social-networking sites, you have masses of users communicating with their peers, socializing, vocalizing and participating in like-minded groups. What is (largely) missing from these site’s is personalization. I’m not talking about skinning or theme-ing, I’m talking about being able to consume (and more importantly) share the information users care about.

This is where social-applications come in. Leveraging social networks, content providers can enable a massive group of like-minded people to consume their content and potentially share it with yet more like-minded people. This is the massively important aspect of social-applications, in itself this gets your content to more people, fast and with instant viral appeal.

Let’s look for a moment at a typical web-savy user, let’s call him Steve. Steve has a personalized homepage full of gadgets and widgets which keep him up-to-date on things he cares about. He has a profile on MySpace, Orkut, Bebo and a profile on LinkedIn. Steve is really into photography, so when he hears that his favourite photography sharing site Flickr has developed an application for Orkut he is thrilled! He instantly adds it to his profile and starts sharing awesome photography with his friends on Okrut.

This is great for a while and as the Flickr application matures it becomes something he checks every day, constantly sharing things he finds with his friends and becoming an active user of the app. The only problem is that his only access to this app is through Orkut. He’s back to the days of visiting one place, to get one type of information. The reason it’s only available to him at Orkut is because the developers at Flickr had to decide which of the propriety social application development API’s to learn, and because they chose Orkut they become dependent on Orkut’s API to mature as their app did. They were unable to launch the app on other social networking sites because it would require re-writing the app.

So back to why all of this is important and the future of OpenSocial; Steve is getting tired of having to visit Orkut just to see he latest awesome photos on his Flickr app, he want to be able to quickly view the information on his homepage when he checks his feeds with his morning tea. Not only that but he wants to be able to share this content with his other friends that use MySpace or Bebo and also his business acquaintances on LinkedIn… Enter OpenSocial.

The first problem that OpenSocial solves is the issue of portability, using OpenSocial Flickr are able to write a social application which will run natively on Orkut, MySpace, Bebo and LinkedIn. With absolutely no extra work their application will work on all of the social-oriented websites that Steve uses. This is brilliant! The more places Steve can use this application the wider the reach.

What will be important for OpenSocial in the future (and something which Google today said was the long-term plan) is convergence. Imagine if Steve is able to share content he cares about with ALL of his friends, regardless if they are on MySpace or Bebo, Orkut or LinkedIn. This is a massively significant aspect of what Google hopes to achieve with OpenSocial. Take this a step further and imagine if Steve could now embed a micro version of this application on his personalized homepage. Now steve has access to this content, and the distribution aspects of it from the place he visits the most. The whole concept could be taken another step further, with application like Google Desktop, Dashboard Widgets and Adobe AIR applications, integrating with these different frameworks (all of which run native xHTML + JavaScript) he now has access to this content online and offline. You can even take it another step further still, Steve could access these services on his mobile phone whilst on the go.

So, by utilizing an open, standards based approach to developing applications for social-network sites Flickr has multiplied the reach, access and viral aspects of the content they deliver through this application exponentially. It’s easy to see why this is so important, if current trends are anything to go by, the web as we know it is getting more and more user-centric, do we really want this garden-walled approach? Applications exclusive to certain separate mega-sites with little interoperability, or do we want the content we love wherever we want it, whenever we want it with the ability to share it with whoever we want? More importantly as developers do we want to launch an application to 5 million potential users on one website, or 75 million potential users across 15 websites, giving them easy access to the application from wherever they want?

Errr… What about Facebook?

You may have noticed that I neglected to mention the largest, fastest growing social-networking site out there in this article. The problem with Facebook is that they have already developed a propriety API for developing applications. Granted they were first to the table late 2006 with their FBML (Facebook Markup Language) and FQL (Facebook Query Language) API’s for developing Facebook applications.

The problem with these is the fact that they are propriety, and writing you application within FBML’s limitations (FBML is a subset of HTML) means your application will only work on Facebook, unless you re-write it. This is not good for the future of the open and social web (now I see where the big G got their name!) and means masses of extra time and effort for application developers.

You could argue the point that this isn’t an important thing at all, and that OpenSocical will never really take off because of Facebook’s dominance. That might be true, who know’s what the future holds? However, I’m willing to bet that both consumers and developers alike will want their content in more places, with easier access. If I were at Facebook I would seriously consider either bridging the gap between Facebook and OpenSocial, or consider implementing an OpenSocial container for Facebook.