RESEARCH DOCUMENTS - COPYRIGHT OPENSOCIALI .ALL RIGHTS RESERVED.
It’s only been about a month since Google launched OpenSocial, its development platform for social networking applications. But already developers are frustrated with how half-baked the whole thing is. Russ Whitman, the founder of MediaPops, a startup that launched at TechCrunch 40, reports to us in an e-mail:
While we were initially very excited, we have learned the hard way just how limited the release truly is. My dev group has been discussing the issues in the Google forum trying to figure out how to build our service through OpenSocial. From our experience its not even a beta platform. The concept of “write once, distribute broadly” is not accurate and core functionality components are missing.
Its clear we are pre-Beta at this point, with Google telling developers they are hoping to launch 1.0 early next year. Any company hoping to leverage Open Social as a means to grow its user base similarly to the Facebook growth model will need to wait at least until February to get started, if its ready then. In the end my hope is that Open Social becomes more than just hype to compete with Facebook.
In our opinion the fundamental problem lies in the core value of Open Social - it’s a unique partnership between Google, Containers/Hosts, and Developers. Getting all on the same page is going to be a ton of work. The opportunity is clear, but the path to get there will be difficult for sure. We remain excited about the vision, but are disappointed with the current state of the union. It’s clear that they announced too soon, and clearly Open Social is NOT Open for Business. (sigh)
Whitman is not alone in this assessment. Even as Google was preparing to launch OpenSocial, back when it was codenamed Maka-Maka, developers were telling me that Google needed “more time” and that the launch was “a challenge for them.” More recently, here is a developer thread on Google Groups about the problems with the “write once, run anywhere” part of OpenSocial. And just last Friday, Google quietly acknowledged how much work it still has to do to get OpenSocial up and running in a meaningful way when a Google employee posted this lengthy to-do list on Google Groups titled “What’s up with OpenSocial?”
The post is an attempt to address developer concerns. But it is clear from the laundry list that Google has a long way to go before OpenSocial can be taken seriously. The post addresses issues with security, navigation, privacy, basic user-interface features, standardizing profiles across all apps, timing of the more-baked 1.0 launch, versioning, API specifications, and the lack of an application directory. Google has yet to determine such basic things as “what features a container supports” (container is Googlespeak for a site that hosts OpenSocial applications), standards for passing data between profile and canvas pages, or even how to reserve a name and URL for an OpenSocial app.
Given all the uproar around Facebook’s Beacon project and how it sends data about members willy-nilly across the Web, Google should make sure it doesn’t fall into the same trap as well. Might as well add it to the list.
As OpenSocial evolves, we're eager for websites to be able to host OpenSocial apps. To that end, we released an in-memory container sample which includes an early glimpse at the Service Provider Interface (SPI) layer, and you may have heard about the Apache Shindig project proposal, which we're quite excited about. We're still iterating and thinking through some of the open questions, but we wanted to let you know what we're thinking about so we can get your feedback. Here are the highlights (there is a more detailed forum post linked below as well):
Privacy and Security:
Given that OpenSocial lets developers create applications that build upon users' profile information, we need to be especially careful with authentication and permissions. In the last blogpost, we talked about a proposal for a trusted version of IG_Fetch_Content, which leverages pieces of OAuth, to help address the trickiness around cross-domain authentication. Additionally, from a privacy perspective, there is an important difference between the owner and viewer of a particular app. When you are browsing a social network, you often end up on someone else's profile page -- that makes you the "viewer," and them the "owner."We plan to add an API that lets app developers handle this situation while respecting the container's privacy policy (e.g. if an app wants to perform some operation based on who the viewer is, it may have to prompt for the user's permission).
API and SPI iterations and refactoring:
OpenSocial is young, and we’re iterating quickly to extend the initial 0.5 spec. One improvement is to cleanly separate the API for app developers from the SPI for container implementors. This split is important to serve both audiences well: the former want a clean, convenient interface for building app; the latter want a clean interface for connecting those apps to their websites. Another improve is to add support for parts of the Google Gadgets API. There is a fairly broad scope to the Google Gadgets API, and, while we're eager to let all gadgets run everywhere, it seems best to start with the bare essentials. For the short term, we've heard that equivalents of IG_Fetch_Content, IG_Adjust_Frame_Height, and IG_Register_On_Load_Handler are crucial components that all containers need to support; if your OpenSocial gadget definitely needs something else, please let us know in the group.
Shindig: open source OpenSocial reference implementation
We're very excited to hear about the Shindig project proposal that is being put together for the Apache incubator, and we'll be contributing both code and engineers to the effort. Shindig hopes to provide a reference implementation for sites that would like to host OpenSocial apps; more on that as it happens.
Policies (gadget directory, discovery, and abuse)
Outside of the more technical conversations, there are many important policy questions. To name a few: How do users discover applications? Is there a central application directory? How can apps let viewers easily “get their own” copy of an app? What happens when an app is reported as malicious?
We’re still working through many of the specifics, but we’re attracted to the idea of an opt-in unified gadget directory as it would let developers have a single point of entry for listing their apps, and let containers offer a wide variety of apps with little effort. In addition, it would potentially allow for unified malware and abuse detection, and some global rankings.
Server-to-Server APIs:
The OpenSocial docs include an early iteration of the server-to-server API spec. We've heard from gadget developers that, although those APIs will be useful, it is fine to have a consumer beta release without them. This also makes it easier for containers to host OpenSocial apps more quickly. Therefore, we are working on the server-to-server API spec in parallel with the JavaScript API spec, but we are not gating on it.
Several people have asked me recently about my thoughts on Google's recent release at the beginning of this month of Open Social, a set of common APIs for building social applications on the web. Since I have really been neglecting my blog over the last few months, I figured I would begin by discussing my (still quite undeveloped) thoughts on this project.
First, I think it is quite obvious that Open Social is an incredibly smart idea in theory. It is a set of three common APIs, defined by Google with input from partners, that allow developers to access core functions and information at social networks such as profile information, friends Information and social activities, things that would be found in Facebook's news feed for example. It also allows developers lots of latitude with respect to how their applications are created instead of relying on a proprietary mark-up language the way Facebook does. Developers can use normal javascript and html and can even embed Flash elements. But the advantage of this approach is really its ability to provide developers with one way to reach users across multiple different platforms. Initial partners include LinkedIn, Ning, Hi5, Plaxo and Friendster with developers like Flixster, iLike, RockYou and Slide already developing applications.
The problem is, however, that in order for Open Social to integrate into a platform, the platform itself has to become a 'host'. This means that instead of developers going where the critical mass of users are (i.e. facebook or myspace) they must wait for the platforms these users have already integrated their social activities into to come to them. This is not necessarily a problem if popular platforms open up to the project and many have. But what would be the advantage to the giants in social networking of doing so, particularly in the case of Facebook?
Since its release, many people have stated that this is a blatant attack on Facebook where it is the weakest, its quintessential closed nature. But it is its closed nature that has been attracting record numbers of users, particularly internationally. The integration of applications within this closed environment means that users have control over their information and social connections, while still bing able to easily utilize incredible amounts of functionality with a mouse click. And lets not forget that the adoption of applications is viral thanks to the news feed. Developers have the ability to tap into a huge user base that is already paying attention.
Now, I am not intending to sing Facebook's praises unconditionally. Any developer knows that, while creating an app for the platform is quite simple, its restrictions and limitations are incredibly frustrating at times. It has also become frustrating to attempt to reach users across multiple platforms, having to learn different APIs or method of creating applications that will work in different situations. Open Social gets rid of this problem. It also gets rid of the need for developers to find hosting solutions for their applications, something that many of the more popular Facebook apps, such as iLike, had to struggle with in the beginning when their user base shot up exponentially overnight. It also takes a lot of the strain off of the platforms themselves. Imagine, for instance, how much of a project the Facebook Developer platform was for the in-house developers.
All in all, I think where Open Social will initially have the most success is with the less popular social networks and smaller developers who have good reason to participate since Google will be doing all the heavy lifting. But I don't see this as being a Facebook killer, at least not in its present incarnation. While I am a firm believer that the future of social software is indeed moving towards a more open and less proprietary environment, Open Social is still relying on its success through integration with the proprietary. And the leaders in that field have very little incentive to join the band wagon. Developers of these kind of integrated applications, however, will naturally be excited to try out something new. But the bottom line is, developers flock to where the users are and the users are, for the time being, on Facebook and Myspace.
***