Platform wars are interesting, mainly because the winner will potentially be in the hotseat for quite some time. Take a look at Microsoft winning the desktop platform war – they’ve had a very well entrenched position for a considerable amount of time.
We’re more or less at that point with the web. We were at the beginning of the wars about a year ago when Google launched OpenSocial and FriendConnect, and then Facebook with their platform and Facebook Connect. Having a well adopted framework is very important – developers typically want to develop apps for a widespread platform. This allows them to build once, and get multiple distribution on different sites.
From the outset, it looks like most of these services are very similar, but on closer inspection they do have some subtle and important differences, which I’m grappling with at the moment.
To sketch a background, I’m doing research on a pretty exciting portal project. At the risk of giving too much away – we need a portal that users can customize with widgets. It’s not too far off from something like Netvibes or Pageflakes. The scripts to run these sites are a dime a dozen and pretty easy to get hold of, plus it’s not so difficult to build them from scratch. They’ve almost become as ubiquitous as white label social networks, blog platforms etc. To use the lingo, they’ve become a commodity.
We initially did some research into white label networks to add a social element to the site. But this poses new problems though – will users need to sign-up to the site again, and find all their friends on the site? Wouldn’t it be cool if they could get a current list of friends already on the site, and potentially on the site right now? We honestly don’t want to build a new network from scratch. Cue FacebookConnect. We decided on Facebook Connect over Google Friend Connect for the predominant reason that we find the social profile of Facebook much more expansive than Google. Even though lots of people have a Google account, we feel the data in Facebook is much richer and also much more organized. There is the benefit of action injection into the news feed, as well friend linking and profile integration.
So we’re going to go the Facebook Connect route – we’re pretty excited about the one-click login for users as well. Now however, we’re posed with a different problem. We want to outsource the development of new widgets to the portal. It’s a similar problem that Facebook had a while ago, and the reason for the platform development (or definitely a large part of it). Facebook has effectively allowed for the outsourcing of it’s ecosystem – things which make the site useful. They first started with Events, Albums and Videos, eventually they expanded in the Marketplace. Soon enough it becomes apparent that they won’t be able keep up with new apps – what if they want to add a TV guide? And if they build a TV guide, how would they build a localized one – for us here in South Africa?
An easier route is to allow outside developers to build those apps – effectively outsource the development of them. Enter the Facebook Platform. This allows for hyper-localized applications (e.g. a TV guide for DSTV) without Facebook needing to build them, and also better applications. Facebook is going “license” the building of the marketplace to Oodle.
So what we’re going to need for our portal site is a similar platform framework. We could build our own platform, but that won’t make much sense. For one: we also want to outsource some of our development. Say someone builds a DSTV app for Facebook, we want that app to be available on our portal as well without the developer having to build the app again. Secondly, we also don’t want to go through the process of building an entire new platform – we simply don’t have the people to build a new platform, plus we want to play nicely with the other platforms out there (why build something that is already built?).
And we’re lucky here as well – we have actually have a choice! We can look at Google’s Open Social, or we can go the Facebook Open Platform route. But once again, we’re more partial to Facebook, also because we’re not to keen to go down a route where we need to figure out a way to integrate Open Social and FBConnect. Yikes. Plus the OpenSocial implementations that I’ve seen are pretty mediocre.
So now some problems start cropping up – I’ve never seen an implementation of Facebook Open Platform, plus I have no idea what we will be able to do with it once we have it setup correctly.
- Will the Facebook Open Platform be compatible with our portal?
- Will we be able to filter apps that will appear on our site?
- Will we have access to the applications?
- Will people be able to build an application once, and it be used on Facebook, and our site?
- What happens to users who aren’t Facebook users?
- Where are other examples of these same implementations?
These questions are really bugging me at the moment, and if anyone has any tips, we’d really appreciate some feedback!