There are a couple of helpful posts that set me off on the path to blog this so here's the acknowledgement :
- "Facebook vs. OpenSocial":http://blog.widgetbox.com/2007/11/facebook-v-open.html
- "OpenSocial and Facebook Platform side by side comparison":http://www.iosart.com/blog/2007/11/03/opensocial-and-facebook-platform-side-by-side-comparison/
I have been spending some time on the Facebook and OpenSocial platforms, and while these both attempt to solve the same need, they end up doing so quite differently. For anyone interested in web based software design, the differences are both curious and interesting, and serve an interesting contrast of how different means can get used to attempt to reach similar ends.
The Facebook platform
The facebook platform primarily allows the hosted applications to access facebook data through a variety of APIs. The hosted application can primarily draw itself onto a "Canvas" which is the primary channel of interaction, and can also render its own part of the profile, and plug into the messaging infrastructure (news feeds, mails etc.). When a user is working with the canvas, the canvas occupies a large share of the screen and thus dominates the interaction with the user.
The OpenSocial platform
Now for some of the important differences.
1. Application Structure
Facebook applications are all hosted on a web site. These typically require a reasonable amount of server side development using a variety of languages. PHP and Java client libraries are provided and supported by Facebook. However client libraries in other languages are also available.
2. Application predominance
In facebook one application is predominant at a time since the canvas it is provided occupies a majority of the rendered screen space. It is not yet clear how most OpenSocial applications will get presented, though it is quite likely that many of these will coexist on one screen with different independent spaces assigned to them
In case of OpenSocial, the application is provided a space for its gadget to be hosted, and after that the application is firmly in control ie. the browser communicates directly with the application.
4. Development Skills
Facebook application development skill requirements are likely to be more similar to those required by the conventional server side application development. However the developers will need to learn the facebook platform apis and technologies (eg. rest apis, FBML, FQL etc.).
5. Application or applet
While one can potentially build both applications or applets with both the platforms, seems like the focus of Facebook is to build applications while that of Open Social is to build applets (small focused functionality) which primarily seems to stem from the fact that OpenSocial borrows heavily from the Google Gadget infrastructure which itself was not focused on heavy duty application development.
6. Usage of IFRAMES
OpenSocial is likely to depend a lot more on the usage of IFRAMEs. While older facebook applications used IFRAMEs, many contemporary applications do not. Combined with the fact that due to Facebook acting as a reverse proxy, which ensures that the data stream is coming from a single domain, some of the difficulties associated with IFRAMEs especially for passing information across domains and usage of SSL with IE (where I've in the past faced some difficulties) can be avoided easily in Facebook.
I am going to go on a limb here and make a conjecture here - Given facebook's reverse proxy structure and given the fact that its platform had some reasonable time to develop (unlike OpenSocial which just seems like a lets make Google Gadgets into a platform API as fast as we can approach), its "probably" going to be tougher to build more secure applications under OpenSocial
8. Platform data is being pulled or pushed ?
In case of Server side OpenSocial applications, the relationship graph and user preferences are pushed into the application as a part of the URL itself (reminds me a little bit about dependency injections - except that it is being done for data). Additionally the application can communicate with OpenSocial platform through REST based APIs but these specifications are currently still in progress. In case of client side applications, this data is pulled from the OpenSocial platform and mashed up with the application data on the client side.
9. Standards compliance
Clearly OpenSocial could be "considered" to be more standards compliant. However that is a rather mixed blessing - All the proprietary facebook additions eg. FBML tags actually help reduce a fair amount of development effort with no equivalent capability in OpenSocial yet. There still are many things that Facebook platform supports which are as yet unaddressed by OpenSocial, so I am not so sure if the issue is so important yet. But as OpenSocial starts offering more capabilities in future versions this could start becoming an issue.
Clearly there exist quite a few dissimilarities between OpenSocial and Facebook platforms. These differences are sufficiently large enough to tempt me to call them apples and oranges (though their end goal is to feed me). It would be wise to avoid the question "which one is better ?" However I can indeed state that as a developer having spent a large time on building server side enterprise applications, facebook just seems to be a lot more enjoyable to work with along with it likely to be more stable and more secure. But remember YMMW (some people like apples more and others oranges).