The OpenSocial roadmap
On November 1, 2007, Google launched OpenSocial, a set of APIs that leverage JavaScript and HTML for creating applications that access friends and update feeds from any compliant social network. Nearly 10 months later, Google is touting the maturation of the OpenSocial specification and growing developer and user adoption.
At this juncture OpenSocial version 0.7 has an addressable market of more than 300 million social network users, including the social networks that have delivered OpenSocial applications or are actively developing them, according to Joe Kraus, Google's director of product management.Friendster, which claims 75 million users including 55 million in Asia, recently unleashed OpenSocial for its developer community. Hi5 has more than 1,800 OpenSocial-compliant applications and 66 million installations, according to platform architect Paul Lindner. Hi5 has nearly 60 million users, with 80 percent outside the U.S., according to ComScore.
Overall, Kraus said that there are more than 4,500 OpenSocial applications and 150 million installs. In comparison, Facebook, which has so far eschewed OpenSocial, has more than 30,000 applications and 700 million installs.
"We expect to reach 500 million OpenSocial users by the end of the quarter. It's also very international, as social networking is a global phenomenon," Kraus said.
(Credit: Google)The latest version of OpenSocial, 0.8, adds a number of new features that extend beyond its original JavaScript roots. "When we launched OpenSocial JavaScript was the center, but the community wants more choice. We agreed upon a RESTful API that gives access to the social bits and is already implemented in Apache Shindig and deployed by hi5 in beta," Kraus said. The OpenSocial RESTful API specification defines how servers, mobile devices, and desktop computers interact with OpenSocial containers without the need for JavaScript or direct user interaction.
"Hi5 launched with OpenSocial very early--January 1, 2008--and we ended up building the system, which had a lot of undefined pieces," Lindner said. "We had a lot of custom work with the REST endpoint so that applications could contact our server directly. As time went by all participants came up with one-offs, but now we are bringing it all together in the community with common types of solutions for these problems. Standardizing on a single specification will allow application developers to write code once and it will work on all different containers. We are already seeing others build on REST specification. Plaxo, for example, has enabled privacy-enabled exchange of contact info."...
No comments:
Post a Comment
Comments accepted immediately, but moderated.