From right here in Philly's backyard, Ringside Networks came out of stealth mode yesterday to launch the first open source "social application server."
And what is that exactly?
It's the software guts of a social network that you can use behind your own firewall, old school style, to build social networking "stuff" into your own site.
Companies that want to build social applications (for runners sharing times at Runlicious) or socially aware marketing programs (like Jeep owners sharing pictures and videos) will be able to use social servers to develop the whole thing on their own websites. Their brand on their site instead of their brand on Facebook next to the "get help for your gambling problem" advertisement.
Developing a social network will be harder to do this way than it would be using a white label network like Ning, but it will be completely customizable, will integrate neatly into the rest of the site, and all the data will be right there for the application owner to mine.
That's the simple version anyway; use social servers to roll your own social apps and sites. But I also wonder how it might upset the balance of power inside the behemoth walled gardens of Facebook and Myspace.
OpenSocial took the first shot at the garden walls with a goal of empowering users to keep their social data portable (well, portable inside Google anyway). However, while OpenSocial promises developers social apps without servers, Ringside is saying that at least some developers are going to want their own stuff under their control. I think social app servers are going to take shots at the wall too, but with the social networking advertisers and application ecosystem as the core constituency.
By supporting Facebook's API (with other API's to follow), Ringside makes it a lot simpler to take a social application written for Facebook and move it to its own site, or visa versa as shown in this picture. This kind of write once deliver anywhere approach to social applications raises all kinds of interesting possibilities.
Like,... Don't want to have to enter your favorite beers into Beer! in both Facebook and Myspace? If Beer! builds their application on a social server that can tie your Facebook user name to your Myspace user name, you won't have to. Facebook and Myspace just become two points of presence for the application, and they'll be on equal terms with Beer!'s own web site. Wherever you log in, you see your beers and (most of) your beer friends.
Facebook opened up this possibility when they designed their platform to have the developer's servers do the heavy lifting. Doing it this way meant they didn't have to provide all of the servers and gear to run the applications, but it also means that it's easier to stick a social server outside the wall and treat it and other branded networks like distribution shelf space. Once an application can seamlessly span the networks, it can do more than map a user's identity across sites, it may also piece together a social graph that is bigger than any one site's. Sort of an application-specific super graph.
In one possible end state, users own all of "their" social graph and data in OpenSocial, and application providers own all of "their" social graph and data in their own social application servers. Meanwhile, the big branded social networks are still in the game with very large "lily pad graphs," but they no longer see the whole picture for any one user or any single application.
As this evolves we may see developers building first for Facebook and Myspace to get quick viral adoption in a huge audience. However, as soon as they can they may start to drive traffic over to their own sites where they can provide a better or different interface with a more carefully managed brand experience. Imagine if NBC let you show your first YouTube video from a planned series at 7pm on Thursday, for free.
Or, developers may use the write once deliver everywhere strategy to deliver their app as widely as possible. Where Facebook and Myspace were once king, in this scenario they may end up as two of many application points of presence with awareness of only a piece of the associated social graph. The successful application developer with a network-spanning super graph might then be free to monetize it however and wherever they can.
Well, at least until the API wars start in earnest. There is a good reason for the server to be open source, it will spread the load of keeping up with all those inevitable API changes.
By: Jim Stogdill
O’Reilly Radar; March 25, 2008
