My company, Ning, is participating in this week’s launch of a new open web APIcalled Open Social, which is being spearheaded by Google and joined by a wide range of partners including Google’s own Orkut, LinkedIn, Hi5, Friendster, Salesforce.com, Oracle, iLike, Flixster, RockYou, and Slide.
In a nutshell, Open Social is an open web API that can be supported by two kinds of developers:
- “Containers” — social networking systems like Ning, Orkut, LinkedIn, Hi5, and Friendster, and…
- “Apps” — applications that want to be embedded within containers — for example, the kinds of applications built by iLike, Flixster, Rockyou, and Slide.
This is the exact same concept as the Facebook platform, with two huge differences:
- With the Facebook platform, only Facebook itself can be a “container” — “apps” can only run within Facebook itself. In contrast, with Open Social, anysocial network can be an Open Social container and allow Open Social apps to run within it.
If you recall how I previously described the Facebook platform as “a dramatic leap forward for the Internet industry”, you’ll understand why I think Open Social is thenext big leap forward!
Open Social takes the Facebook platform concept and provides an open standard approach that can be used by the entire web. Open Social is an open way for everyone to do what Facebook has done…
…including Facebook itself, potentially — more on that below.
Open Social basically standardizes the concept of a plug-in API in such a way that neither host social networking environments (containers) nor external applications will ever have to invent another plug-in API, or have to choose between multiple competing proprietary plug-in APIs.
Open Social is very practical. Many standards die an early death because they are too complicated and hard to implement. Open Social is what you want in a standard — it’s expansive enough to do useful things, but limited enough to be very easy to implement, both for containers and for apps.
At this Thursday’s launch event, you will see Open Social already running in a variety of containers, including Ning, Orkut, Hi5, and LinkedIn, and across a variety of apps, including iLike, Flixster, and Slide. I’m talking about working code. At Ning, it took us only a few days for us to add support for Open Social as a container — because we already had all the necessarily underlying APIs and mostly just had to map to them — and the app developers in the launch created Open Social versions of their apps even more quickly. We also have live running examples, such as iLike, of the same app running in multiple containers — Ning, Orkut, and Hi5 — proving the interoperability that the Open Social specification promises.
Now, all that said, Open Social is not quite ready to go live on Ning and the other partners. The API has to stabilize a bit, and containers have to finish testing and validating their implementations. But public production systems aren’t far off — Ning, for one, will go live as soon as we possibly can, probably just as soon as Google finalizes the API.
What does this mean for today’s Facebook app developers?
Today’s Facebook app developers just got very good news — they will be able to take all of the work they did to build their Facebook apps and create Open Social versions of their apps very easily… and by so doing, get access to a huge new pool of users — as many as 100 million users just via the initial Open Social partners, more than twice as many users as Facebook has today.
What does this mean to web sites that aren’t Facebook apps?
Are people really going to maintain multiple sets of front-end pages for their web sites for Facebook, Open Social, etc.?
I think so, yes. I think any web site going forward that wants maximum distribution across the largest number of users will have a single back-end, and then multiple sets of front-end pages:
- A third set of pages in FBML (Facebook Markup Language) that use Facebook’s proprietary APIs for consumption within Facebook as a Facebook app.
- Perhaps a fourth set of pages adapted for the Apple iPhone and/or other mobile devices.
The overwhelming good news here is that these pages can all be served and serviced by the same back end code — and of course, 95%+ (and usually 99%+) of the effort involved in building any web app consists of building the back end. Having already built the back end, it’s a very small amount of effort to create any of these front end pages.
What does this mean for Facebook?
Well, to venture a few opinions…
Facebook did an absolutely outstanding job kick-starting this whole approach with their proprietary Facebook platform. That plus their very large walled garden user base generated a rush of app development and adoption on Facebook that has performed very well for them over the last five months.
Open Social — by making this exact same kind of opportunity available to any other social network or container and every app developer and site on the web, in an open and compatible way — will prevent Facebook from having any kind of long-term proprietary developer lock-in. Developers will easily write to both Facebook and Open Social, and have every reason to do so — in fact, 100+ million reasons to do so.
If you’re Facebook, you’d probably prefer to have that proprietary lock-in, and so this announcement may not make you that happy. However, all is not bad for Facebook, because a big part of what’s happening today is market expansion, and Open Social will definitely help fuel market expansion, which is in everyone’s interest, including Facebook’s.
Look at it this way: most users on the Internet (1.3+ billion, with 100 million joining every year) are not yet using any social networking service. The more compelling social networking becomes, the more users who will discover and start using social networking, and the bigger the pie gets for everyone, including Facebook.
Meanwhile, most software developers in the world are not yet building apps for social networks — Facebook or otherwise. The more developers who build social networking apps — Facebook or otherwise — the more apps there will be on social networks, and the bigger the pie gets for everyone, including Facebook.
It’s hard to see Facebook losing in a world of a billion or more social network users, and hundreds of thousands or millions of social network apps. And it’s also easy to see how a lot of other people — containers, and app developers — will win, as well.
In fact, if rumors of a Facebook web-wide ad network are true, then this could be great for Facebook in another way — such a Facebook-run ad network could be an outstanding ad network for all of these new Open Social web applications!
Finally, note that Facebook can easily support Open Social any time they want. They probably won’t do so right away, but in the long run, it will probably be a no-brainer for them, because then they will pick up whatever Open Social app developers who aren’t also Facebook developers.
Is this good for the web?
How will Ning support Open Social?
We will aggressively support Open Social in every conceivable way, including but not limited to:
- Being an outstanding container. Open Social apps will be able to run easily and reliably inside Ning social networks — all 113,000+ of them. Ning Network Creators will be able to quickly and easily add Open Social apps to their networks, and Ning users will be able to quickly and easily add Open Social apps to their profile pages.
- Being an app publisher. Ning already automatically produces Facebook apps for every Ning network — specifically, video, photo, and music players — using the Facebook proprietary platform approach. We will do the exact same thing for Open Social — we will automatically produce Open Social apps for every Ning network.
- Being an outstanding environment within which you can build new Open Social apps. More on that a bit later!
No, I don’t think so. Think of it this way. As an app developer, you have three options:
- You can write purely to the Open Social API. If you do this cleanly enough, your app will run unchanged in any compliant Open Social container. (Google is actually not making this claim — they’re calling Open Social “learn once, write anywhere”, which is not the same as “write once, run anywhere”. But in practice, the API is simple enough that “write once, run anywhere” should work just fine.)
- You can write an app that is specific to one container. For example, there may be some apps that make sense only in LinkedIn — business-related apps, say. There may be other apps that make sense only in Ning — apps that presume that users are creating their own social networks, say. And there may be yet other apps that only make sense in Salesforce.com, which will also be an Open Social container. In those cases, you are targeting your app to one specific container, and so using whatever additional APIs that particular container provides, in addition to the Open Social APIs, is a no-brainer.
- Finally, you can write an app that behaves differently depending on which of several containers it’s running in. Your app just discovers which container it’s running in, and then does whatever it wants on a per-container basis.
No standard can possibly anticipate all of the different use cases and scenarios people will think up. Standards that try to anticipate all of the different use cases fail, because they are too complex and generally impossible to implement.Standards that standardize behavior that is clearly standard, while leaving open the ability to innovate on top, succeed. The history of this kind of thing is quite clear, and Open Social is on the right side.
Congratulations to Google — the crew at Google has been outstanding in conceiving of, implementing, and evangelizing Open Social to the initial set of partners — and now, to the world. Thanks!