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, 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.

IDGNS: 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.

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.]

IDGNS: There are other complementary OpenSocial projects, such as the Caja Javascript sanitizer. What's Caja's status?

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.