by Jason Costa
It’s been fascinating to watch how a large incumbent, Facebook, has been effectively dealing with the threat of a rapidly growing upstart, Snap. Facebook, with all of their product prowess and constellation of social apps, has been steadily chipping away at Snap’s previously meteoric growth rates. This is a case study in how a large company leaning into their strengths and executing flawlessly can neutralize oncoming threats. The situation has also reminded me of my time at Google, when Facebook was just an upstart threat and how our team could have better leveraged its strengths to compete. Below is a reflection on Google’s approach with OpenSocial, and some of the lessons learned.
Facebook vs OpenSocial
Back in 2007–08, the Facebook juggernaut was surging forward quickly, and the rich identity information that they were collecting would clearly pose a threat to Google’s ad business over time. One of the little known secrets at that time was that photos & games were what drove the vast majority of pageviews and time spent on Facebook. In an effort to neutralize this growing Facebook threat, Google built a coalition of other social networks and tried to circle the wagons against Facebook Platform. This coalition, under the name of OpenSocial, would be Google’s first of many attempts in the social space against FB.
The concept was simple: create a technical standard that any social network could implement and support. At the time, Google had assembled quite a group of social network “containers”, which would integrate this standard and allow 3rd party developers (such as RockYou, Slide, etc.) to deploy apps on the network via APIs. There was even a reference implementation of the standard named “Shindig”, developed as an Apache project and available in Java and PHP.
There were a number of social networks that had agreed to integrate at that time: MySpace, Yahoo, Hi5, Bebo, Orkut, Friendster, LinkedIn, and many others. The value proposition to them: don’t lose out to Facebook. The value exchange for developers to build on OpenSocial: you could write your app once, and then run your app anywhere (thanks, Java). This, in theory, would get far more user distribution than what was available on Facebook.
Fragmentation of a standard
The realities of implementing an API do not always live up to the dreams expressed in a standard. While OpenSocial made the Apache Shindig reference implementation available, it came in two flavors: Java and PHP, which rarely kept feature parity. So if a container was built on PHP, they may not be able to support the same features as one built on the Java version. Further complicating matters, MySpace, who was the largest container at the time, wrote their own custom version in C#, causing more divergence from the reference implementation.
Lastly, Google App Engine was available only in Python at that time. This limited the OpenSocial initiative from having a more complete developer story. A 3rd party developer should have been able to write their app in any language, interface with the REST & JavaScript based API for OpenSocial, then deploy & scale their application directly on App Engine. Instead, most of these app developers had to seek out support on AWS.
The need for a marquee container
Because there were fragmentation issues with the standard, OpenSocial itself turned out to be a “learn once, write anywhere” operation rather than fulfilling the “write once, run anywhere” promise. But the value proposition for developers was to write once and suddenly reach users across MySpace, Yahoo, Hi5, and other containers. If a developer had to manually write and rewrite for each social network — the overhead was too great. Why not just concentrate instead on deploying for Facebook, and reaching ~100M users at once?
MySpace was just starting its decline, and Yahoo never really delivered on a major property implementation. Google’s primary offering was Orkut, which was big in Brazil and India but not very compelling elsewhere. Had Google been able to step up and offer a major marquee container in the form of say, YouTube — that might have been able to buoy the developer base. Without such a marquee partner, it simply wasn’t worth the effort for a developer when comparing against Facebook. Google wanted to take market share away from Facebook, but didn’t commit strongly enough to building these features into their own core products and leverage their existing networks to grow quickly.
The lack of Social DNA
OpenSocial marked the beginning of a long line of social product endeavors for Google: Friend Connect, Buzz, Latitude, Google+, and others. Ironically, the information problems at the periphery of social around search & content organization led to one of Google’s most awesome products: Google Photos. That’s where Google shined — problems that could be overcome with raw engineering horsepower. But to understand social took a different type of product lens.
In the early days, when Google was just search — the UI was a clean, simple background. And it remains largely so today. There was little room to think about the “experience” beyond this — the vast majority of focus was spent on the backend: delivering the highest quality search results, optimizing performance with minimal latency, and so on. All incredibly important engineering feats, yet indirectly impacting the product’s information architecture and thus the user’s experience. Consequently, product teams were for the most part far more technical and less design oriented, because most of the heavy lifting was behind the UI. This set a tone early on. But social is not an engineering matter at its core.
OpenSocial was never able to slow down the Facebook juggernaut, despite all of the team’s efforts. And over time, the OpenSocial project surprisingly morphed into an enterprise-oriented standard being largely driven by IBM and others. But it was a good reminder that, if you want to build a product that is highly capable of competing in a certain space, you must first have the DNA and talent in house that understands that space, then you must execute (get the right partners, manage inconsistencies, etc.) flawlessly. Particularly if you’re battling a formidable foe like Facebook.