arrow_backward Back to blog

OpenSocial, Buzz and the Tao of Releasing an API

Generate the Right Buzz

OpenSocial was released the 1st of November, and there was much rejoicing. Developers rushed to the official site to see what exactly Google was up to. Facebook developers everywhere crossed their fingers as the page loaded up, hoping to find a means of escape from the FBMLized, constantly-changing hell they were experiencing. Surely, Google will have the answer! This is Google we’re talking about — they wrote Gmail, remember the buzz for that launch? They’ll surely deliver! Right?

Release the right thing at the right time (or ‘First Impressions Matter’)

November 2nd was the first day of RubyConf 2007, and while I saw many a Rubyist’s Macbook Pro loading up the API site during the morning sessions – I would say that it’s within reason to declare that there were no libraries or even hacky interface wrappers written that night. This was partly because Google has YET to release the actual meat of the API — the RESTful interfaces to their data. What the developers got on Thursday was a tiny set of extensions to Google’s pre-existing Google Gadget API, which is primarily written in Javascript. Google, if you’re reading this, know that you would have had a beautiful Rails plugin for OpenSocial a day after launch if you had only came through for the early adopters and opened up the REST interface. Release the whole API (or something respectable and usable) if you want to make a solid first impression.

Don’t frustrate your developers

The developers who actively seek out your API and are excited about it at the beginning are the ones who know a good thing when they see it. Don’t alienate them. The Gadget Javascript extensions are great for tiny widgets, but developing with those brings forth their own set of problems. Orkut has an extremely annoying caching bug that pretty much forces developers to add/test/remove/add their app every time they make a change — not a good start, we are no longer in the dark ages. This brings me to my next point – why just Orkut?! Brazil and India are Orkut’s main consumers, or at the very least, the only people who use it pretty much exclusively (even though I hear rumors of hi5 making major strides in South Asia). The last I heard, Friendster, hi5, LinkedIn and Ning were also launch partners, why are my sandboxed apps not running on their sites as well at this moment? Good developers love an all-encompassing solution rather than a targeted one. If one of these developers writes an app for Orkut now, and finds later when LinkedIn or Friendster finally opens up their sites as containers, that their code does not run as well as promised, Google loses trust, credibility and karma points.

In theory, OpenSocial is fantastic — I will not deny that. In time, I can see that it will be a sweet little platform for writing network-independent social apps. The pressure is on, however. The VCs are probably loving this, considering what Facebook apps are worth now, and Google needs to deliver a flawless platform that is ready to whip out of the gate and crush everything in its path. Intridea will be tracking OpenSocial quite closely, stay tuned for more in-depth posts quite soon.Michael Arrington announced OpenSocial on TechCrunch two days before its official release. Prior to that, there were whispers everywhere about Google’s new social platform, but not many seemed to know what exactly was about to go down. Needless to say, this is good buzz. Two days before ‘launch’ the overwhelming mood among web developers, especially us who dwell in the realms of social networking, was one of intense (even feverish at some points) anticipation. What unfolded over the next few days, combined with what we observed of Facebook’s API venture, provides us a set of best practices that we can apply to an API release.


New Project Request