Three Minutes With Google's OpenSocial Director
Almost four months after Google emerged from the background in social networking with its OpenSocial initiative, there is no shortage of skepticism around the project.
The initiative, which will develop a common set of APIs (application programming interfaces), has the goal of making life easier for developers by simplifying the porting of applications to different social networks. But some see OpenSocial as an attempt to undercut the momentum of rival Facebook and its successful application development program, launched in May of last year. Others are unimpressed with OpenSocial's technology architecture, saying it's too weak for creating truly sophisticated applications.
Still, while Facebook hasn't supported it yet, other big guns in the social-networking market are backing it, including MySpace, LinkedIn and Bebo, and even major enterprise application players like Oracle and Salesforce.com.
IDG News Service recently chatted with Google Engineering Director David Glazer about various OpenSocial topics, such as the dangers of partners splintering it with proprietary extensions and Facebook's lack of support. An edited version of the interview follows.
IDG News Service: Some key components to OpenSocial are in different stages of readiness. The API itself is in version 0.7, which you feel confident developers can start using to build real applications that can be deployed in production.
David Glazer: Yes, when we announced the initial API we said: "Here's a start. Give us feedback." [After two more versions] they said: "Yes, we can build great apps with this. There are a lot more things we might ask you to do someday, but we can build a great app today." So we shipped it.
IDGNS: You also have a server-side REST [Representational State Transfer] component that's still not ready, right?
Glazer: When we announced OpenSocial we said that we could provide interfaces for building applications with client-side code and also apps that let your servers get information from site servers. We got a lot of interest and traction in the client-side thing. People said they were interested in the server-side option also but that they weren't locked on it, that they didn't need it to build a great application. They said it's something they'll take advantage of when it's available. With that, we put all our energy into what the app developers were telling us were critical [components.]
Glazer: That's ready for developers to start kicking the tires and giving us feedback on. We want to do a very open and a very carefully timed rollout of it. It's protection technology and we want to be sure it's appropriately safe.
IDGNS: Could you explain Shindig?
Glazer: That's the open-source reference implementation of the OpenSocial API. It's being done -- governed and run and implemented -- entirely as an Apache Software Foundation project. This means individuals commit code with permission of their companies to open the license on any IP that's contributed.
Shindig's mission is to make it really easy to implement OpenSocial support on your site. The goal is that your development team takes Shindig and has a proof of concept up and running in hours, not months. Shindig is making great strides in that direction. There are big pieces of the spec now that are plug-it-in-and-run, and that'll be ongoing.
There's no requirement that somebody uses Shindig to implement OpenSocial. The API can be implemented in many different ways, and Shindig is one easy way to do so.
Glazer: The short answer is: no gratuitous differences. That means it's essential that everyone implementing OpenSocial be able to extend it to take advantage of their site's unique capabilities. It's also essential that if I'm a developer building an application that does the same thing on three different sites, I should do it the same way.
So we're working hard with [Web site partners] to say: where you support something for which there's a standard mechanism, use the standard mechanism. Where you want to support something that isn't part of the standard, please do so and here's a standard extension mechanism that we built in so you can easily add your unique capabilities in a discoverable and testable way by developers.
IDGNS: Is there an OpenSocial certification, so that if a Web site partner strays too far with its extensions, Google can force them to scale things back or else lose the seal?
Glazer: We've asked ourselves that, but so far, our interests are so aligned that we haven't come close to having to do anything that black-and-white. The people that [such a problem] will hurt first and most are application developers, and they will raise an outcry and we'll say: "Ok, what can we jointly do to bring a little bit of order back to this world?" But so far that hasn't been a concern.
IDGNS: Some complain OpenSocial aims to be such a baseline standard that it will only allow developers to write simple widgets and gadgets.
Glazer: There is some confusion about what piece of the problem OpenSocial is trying to solve. Also, there's a false reasoning that what I see today is all I will ever see.
First, the word "gadget" has a bunch of connotations, not all accurate. One is that it's something 100-by-200 pixels in a little box on a page. There are implementations of gadgets like that out there, but that's not true for how OpenSocial supports application builders. OpenSocial has built into it the concept of "views" which lets you say: "Here's how my application looks if you give me a little rectangle and if you give me a full page, and here's how I can navigate between different views of my application."
The second thing is OpenSocial isn't trying to boil the ocean. Our overall goal is to help the Web become more social more quickly. There's a whole bunch of things we can do to help the Web become more social, and OpenSocial was the first and biggest place where we saw an opportunity. OpenSocial isn't meant to be a panacea, nor to do everything for everyone. It's meant to move the world forward and to solve a very specific problem: help developers build an application that can run on any social site that wants to support OpenSocial.
At the same time, the proof is going to be the application, and if it turns out this round of OpenSocial provides good applications and we want to get to stellar applications, we'll enhance it.
IDGNS: There has also been talk of whether OpenSocial should address data portability. What's Google's latest position on that?
Glazer: [Data portability and standard social-application-development APIs] are parallel issues that are both interesting and can both be addressed, but they don't have to be coupled. We thought about where we can help things move forward quickest and decided it best to separate these two things.
Glazer: That's up to users and developers to answer. The benefit of a standard is it helps people reach more users more quickly, and we welcome anyone who chooses to implement the standard if it makes sense for them. The nature of the Web is a playing field that tilts towards openness and interoperability, and it's great anytime anyone makes a move towards open interoperable applications in the world of social [applications], but everyone should make their own decisions and do what's right for their business.
IDGNS: Yet, today Facebook is probably the most attractive platform for this type of application.
Glazer: Moving from a world in which you have 12 different ways to build an application to a world in which you have six, and then two and then one, every one of those steps makes things better.
IDGNS: You recently announced that Orkut's OpenSocial container is ready and that you'll soon begin making OpenSocial applications available for Orkut users. Is that correct?
Glazer: Yes, the Orkut sandbox, which is the developer limited-access site, is running the launch version of the API, and there's a whole community of developers building applications for it right now. We're on the countdown to opening that up to consumers.
IDGNS: What's the next big OpenSocial milestone or announcement we should be looking out for?
Glazer: There's a set of launch milestones. As Orkut, MySpace, Hi5 and others that have announced imminent plans open the doors of their OpenSocial applications to consumers, there'll be a wave of those. The next step will be watching the interaction between users and developers on these different sites: seeing what kinds of feedback they get from users, seeing developers come up with new creative ideas and seeing the sites work to enable that. That's what we're looking forward to: opening the doors and watching the party get started.