OpenSocial targets social apps API 'balkanization'

In a recent chat with IDG News Service, Scott McMullan, Google Apps partner lead in Google's Enterprise division, described OpenSocial as an attempt to simplify the lives of developers by addressing what the vendor considers is a 'balkanization' of social-networking APIs.

McMullan also articulated how OpenSocial's scope goes far beyond the creation of applications for social-networking sites, saying its core set of common APIs is intended also for the creation of social features and capabilities within Web sites in general and within business software.

Below is an edited transcript of the interview.

IDG News Service: Regarding the "balkanization" of APIs in general on the Web, do you plan to extend OpenSocial so that it contains open APIs for other types of Web applications -- not just social-networking ones, but for things like maps, where different vendors, like Google, Yahoo and Microsoft, have their own set of APIs?

Scott McMullan: In general, one could argue that any time you have two APIs that do similar things you've got this inherent problem. I'm not sure if OpenSocial is going to [address] that larger problem, but certainly this is the context where we thought we could make an impact.

IDGNS: Google has said that the scope of OpenSocial APIs isn't limited to social-networking sites, that OpenSocial can be used for creating social-networking features or components in Web sites in general and also in business applications.

McMullan: Yes. Take, for example, Salesforce.com as an application whose goal is to coordinate a team of people to sell stuff. Sales is a quite socially driven activity. ... You have this group of people all coordinating [their efforts] to sell, and all within this one Salesforce.com application. It's a business application that has kind of an implicit social network to it. ... So you see how it would make sense to bring these social features more explicitly to Salesforce or any other application that has that similar dynamic.

IDGNS: Is OpenSocial a solution in search of a problem? Are developers really clamoring for something like this? How many social-networking sites are out there today for which you can or would want to write applications? There don't seem to be that many APIs for social-networking sites out there.

McMullan: There are a lot of social-networking sites. There's a long tail of them. There are a lot of big ones and small ones. In addition, my personal perspective is that the social nature of a lot of different applications is also an equally important part of the story. It's about the social features that we all find very compelling in social-networking sites and we'd like to empower those across the Web. So getting ahead of the problem and creating a standard that we all can rally around to make that happen, and help channel that developer energy, is a big part of it. And these are early days for social-network platforms.

IDGNS: In the real world, won't developers ultimately find themselves having to tweak and retool applications so that they are appropriate for different sites, because, say, the concept, the policies and the look-and-feel of Facebook are different from the ones of LinkedIn?

McMullan: You certainly might, in the same way a Web developer has to take into account different browsers. There can be devils in the details, but hopefully [with OpenSocial] the vast majority of the effort is certainly not in porting. It's in perhaps the last 1 percent of tweaking.

IDGNS: At this point, should developers start writing applications based on OpenSocial or rather wait, kick the tires and send Google feedback?

McMullan: We've got an Orkut sandbox and there are other sandboxes for other sites coming online. When you're at the sandbox stage only, we're talking about, "Come, kick the tires, participate, learn, test, but know that the sandbox may have an API [revision] before it reaches production status." A big part of it is the policies and the production hardening that this requires for our partners, for anyone who implements this. It's something that takes time. We want to get that open feedback loop going with the world as soon as possible.

IDGNS: Is Orkut [Google's own social-networking site] now fully enabled for OpenSocial?

McMullan: It's still in sandbox stage.

IDGNS: Many social applications are designed for end users to load information into a database, be it text, photos, videos, audio, whatever. If someone adopts one of those applications for, say, the eight social networks he's in, he has to enter the data separately on each Web site. As part of the OpenSocial effort, will Google help end users with this data portability problem?

McMullan: That's an interesting idea, but we don't have anything to talk about regarding that at this time.

IDGNS: Does OpenSocial have any features for advertising functions?

McMullan: We don't have it now, but we're very conscious the developers want to monetize their applications. So, part of this discussion is to figure out how that can be made to happen and if the APIs have an impact there or if there are other mechanisms for advertising [that fall] outside of the API.

IDGNS: OpenSocial, in theory, will let developers write an application once and have it be compatible with any Web site that supports the OpenSocial platform. However, for Web site publishers, is there value in having the same applications as 30 or 40 other sites, some of which it may compete against?

McMullan: We're not that far into this notion that developers should be thinking about social features, not only for social networks but for all kinds of applications, in a standardized way. When you think about the number of developers that will be brought under the fold to unleash their creativity, one side is, yes, that one application may run on 20 different sites, so as one of the Web sites you feel less special. But the upside is you've got orders of magnitude more developers who can bring their creativity into your environment. Although the APIs are the same, the context isn't the same, the notion of friends isn't always the same, so you still have the ability to differentiate yourself and tap into that giant pool of developers. That's the ultimate upside.