Open Source "Social App Server" Might Crack Garden Walls?(开源“社交应用服务器”有可能推倒那些“院墙”？)

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.

Ringside　Networks昨天从其秘密行动里走出来发布了第一个开源的“社交应用服务器”。

那到底是什么？

是一个你可以在自己的网站上构建社交网络的软件系统，就像过去那样，在防火墙后面。

公司希望构建社交应用（像跑步的人用Runlicious晒时间）或者社交市场计划（像Jeep用户晒照片和视频），现在他们可以用社交服务器在自己的Web网站上开发全部社交网络。在自己的网站上，用自己的品牌，而不是在Facebook上——旁边还放着“有赌博方面的问题吗？需要帮助？”广告。

用这样的办法自己开发一个社交网络和利用像Ning这样的框架系统比会艰苦一些。但是这样做有最完全的灵活性，可以完美地和你网站的其它部分结合起来，而且所有应用的数据你都掌握，可以研究。

用“社交服务器”构建自己的社交应用和网站还刚刚开始。然而我仍然好奇它如何才能撼动Facebook和Myspace这样的“院墙”里的巨兽。

OpenSocial曾经打响了进攻这些“院墙”的第一枪，它让用户移动自己的社交数据（至少在Google里面是可移动的）。尽管OpenSocial许诺给开发者不需要服务器的社交应用，Ringside现在认为很多开发人员需要自己控制他们的东西。我认为社交应用服务器也是针对“院墙”的革命，只是多了社交网络广告商和应用商业。

通过支持Facebook的API,Ringside极大简化了将为Facebook写的社交应用移植到你自己的网站上，反之亦然，就像这张图显示的一样。这种写一次就可以用在各种社交网络的能力会带来很多有趣的可能性。

比如：你不希望在Facebook和Myspace的Beer!重复输入你喜欢的啤酒。如果Beer!在社交服务器上构建自己的应用，把你Facebook上的账号和Myspace上的账号绑到一起，你就可以不用重复输入了。Facebook和Myspace变成了这个社交应用的两个呈现的点，对于Beer!自己的网站它们是一样的。无论你从哪里登录都能看到你的啤酒和志趣相投的酒友。

Facebook设计他们的平台时打开了这种可能性，让开发人员的服务器做体力活。这样他们就不用提供那么多的服务器和资源来运行这些社交应用，但是仍能够轻易地粘住墙外的社交服务器，把他们以及其它墙外网络当作自己的销售空间。一旦一个应用能够平滑地跨越这些网络Facebook就能做更多的事情，就可能作出一张比任何网站都大的社交图表，比如一个针对特定社交应用的超级大图。

未来一个可能的情况是：用户通过Opensocial拥有自己的全部社交图表和数据，应用提供者通过自己的社交应用服务器拥有全部社交图表和数据。那些大牌社交网络还在，也有一些非常大的“芭蕉叶图表”（社交图表），但是他们再也看不到一个用户或者一个社交应用的全貌了。

这样的话也许就会看到开发者首先给Facebook和Myspace开发应用，从而迅速得到大量受众。一旦时机成熟他们就会把流量拉回到自己的网站上，在那里他们会提供更好的或不同的界面以及更好的客户体验。想象一下如果NBC让你在周四晚上七点的节目展示你的Youtube视频会怎样？还是免费的。

或者开发者通过写一次到处用的战略把他们的社交应用最广泛化，到处放。这个领域曾经Facebook和Myspace是国王，到这步田地他们只能作为很多社交应用的两个呈现点，手里攥着一部分联合社交图表。成功的应用开发商拿着跨越网络的超级图表就会随心所欲地换钱了。

Ringside 的社交网络系统应该是开源的，这样可以分散跟踪不可避免的API演化的负担。