Blake Commagere is a top third-party developer on Facebook, having built or worked with others to build popular applications like Causes, Zombies, Vampires, Werewolves and Slayers (he also works with startup Mogad, which is developing a sort of news feed site).
Commagere is the type of developer Google and its OpenSocial partners want working with them on their OpenSocial project. The project aims to let a single application work across multiple social networks.
We chatted with Commagere today (by IM) to try to get a developer’s view of OpenSocial’s significance.
VentureBeat: Will OpenSocial change how you spend your time? That is, will you spend less time developing for Facebook, where we saw the first gold rush? (See here and here.)
Blake Commagere: Naturally I’m going to try out OpenSocial. It certainly has the potential to turn into a gold rush. And as a developer, I love that I only have to learn one new set of APIs.
However, here are some distinct differences. Say OpenSocial allows access to post to the equivalent of a newsfeed on another social network. If the social network doesn’t have a newsfeed, an application that relies on Facebook’s news feed won’t have this news feed to help it grow.
Of course, I think every network has said they’ll do a news feed (if they haven’t already) so I imagine it’s just a matter of time before that isn’t a big deal. But the essential point is that these social networks still have to implement these features if they don’t have them. Now we can interact with the social networks. So say your app is on Bebo and doing well and now another network implements those critical features you needed, well then it’s easy to try out your app on that network.
I would imagine that as the social networks converge in features, you’ll see good results on each. Success won’t all come at once as the networks probably have different priorities.
VB: Some are concerned that Google’s leadership of the OpenSocial’s application programming interfaces will result in standards that favor Google. Are you concerned?
BC: Well, standardization doesn’t necessarily kill innovation. Google is very much a tech company that understands developers. The API they’ve created is versioned, and as companies come up with new aspects for their platform, I would think that Google would accomodate that in OpenSocial.
I would be amazed if one of these companies came up with a killer platform feature and Google refused to add it to OpenSocial in order to maintain some sort of advantage for themselves.
VB: Do you think Facebook will be able to keep some sort of competitive edge? Do you see Facebook’s design, its existing user base, or other factors helping it in the long run?
BC: I think honestly — and I know this sounds like a very diplomatic, planned answer — that Google and Facebook are both incredibly smart tech companies. And the world of social networks is huge. I’m pretty sure there will always be room for two players. Maybe one camp will have an edge over the other but it’s a huge and lucrative market. So if someone ends up in “second place” they’ll still be sitting pretty.
As a developer, I would hope that Google and Facebook work together and standardize together. Even if they don’t, they’ll both be very successful. So will I develop on OpenSocial? Absolutely. Will I continue to develop on Facebook? Absolutely.
VB: Part of the OpenSocial pitch is that you don’t have to learn a special markup language, and other specifications of an individual social network. But you’ve talked about how great Facebook’s markup language, FBML, and its query language, FQL, are.
BC: I think FBML or some variation of it is great. While FQL is powerful, I prefer not to use it. To do some things, you do need it, but if possible I try to just use FBML
Pros of FBML: Fewer API calls, the look and feel of Facebook is maintained by them, so less code. Cons: It won’t do everything you hope (yet!), but facebook’s API makes up for that – it makes for a very powerful combo.
Now why are fewer API calls so great? Well, say I want to say “Hi Eric, Welcome to my cool app”
In Facebook I don’t have to know your name to do that – I just output something like this to facebook “Hi, <fb:name uid=1234 firstonly=true />”
So all I have to deal with is your user id. Doing several API calls means more points of failure. So if I have to call your API 20 times versus two, it’s a big deal. Google realizes this and I’m sure they’ll do one of two things:
1) Design OpenSocial in a way that really does minimize the number of API calls so that this pain isn’t felt
2) Create a standard FBML-type markup that developers can use
OpenSocial is only going to get better, so I imagine that the biggest pain points may not even be what I’m anticipating. Whatever developers are going to have problems with I’m confident that Google will work to improve.
VB: If you were Facebook, would you join OpenSocial?
BC: Platforms are still a very new concept – so there will be parts that need improvement. If I were Facebook — again, this answer may come across as too diplomatic to be useful to you –I would absolutely look at it and chat with Google.
It may make sense for them to join, it may make sense for them to join later on, or never. They won’t just ignore it – they’ll of course look into it & decide if it’s in their best interest. Again, I don’t know if it’s a “join or get crushed” situation. I think the market has room for both. I think some of what I created will be successful on other networks. I’m trying to be cautiously optimistic.
VB: Specifically to you, how could you see your Facebook apps working on other social networks? Will Zombies be able to bite across networks?
BC: The cross-network functionality isn’t clear to me. I would love it if it was easy for a user to have the same zombie on all networks – because then they can play the game wherever they want
I’m not sure if OpenSocial will allow for that – if so it would rock. And someone probably already knows the answer to whether that will be allowed but I don’t know yet :)
VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.