关于OpenSocial讨论的总结

最近我写了两篇关于Google OpenSocial的文章，分别是：为什么说OpenSocial只不过是一个公关骗局？和我为什么鼓吹facebook，为什么唱衰OpenSocial？，出乎我自己的意料，这两篇文章得到了异乎寻常的关注，有赞成我的观点，也有反对我的观点，当然也有谩骂的。其中非常感谢那些对OpenSocial很了解的人热情的回复我的文章，指出我文章的错误之处。我今天看了一遍OpenSocial v0.8的文档，想就前面的文章和讨论做一个简单的总结：

Google OpenSocial v0.8增加了REST API，支持服务器端的扩展

之前我看OpenSocial的项目文档，是直接访问到了OpenSocial的中文官方网站(也许是因为我的Google账号设置为默认中文版的缘故)，中文网站至今没有发布v0.8版本，因此我没有注意到REST的支持。今天仔细看了一遍OpenSocial英文官方网站，v0.8版本正式提供了REST支持。准确的来说就是：OpenSocial v0.8支持两种方式的访问：

1、使用gadget访问OpenSocial，本质上是在浏览器端运行的JavaScript，这就是我在前面文章当中一直大力批评的方式。gadget如何发布，官方文档没有明确说明，只是说容器应该提供功能让开发者可以发布，gadget应该运行在containing page里面。

2、v0.8正式公布的REST方式访问OpenSocial，这也是f8平台早就支持的方式,你可以在自己的服务器上面编写程序去远程调用OpenSocial的REST API。至于通过这种方式开发的应用，应该如何发布在容器网站上面，官方文档没有任何说明。

我想从技术角度分别谈谈这两种方式：

1、gadget方式调用OpenSocial

gadget方式其实就是一个页面里面嵌入的widget应用，用AJAX开发出来的。这种方式我否定它的重要原因就是这种方式难以开发高交互式的复杂应用，而SNS的应用要火爆要推广出去，必须是那种交互式很强，越多人参与越有意思的应用，比方说看一下facebook上面那些很火爆的app，都是交互式特别强的app。

gadget方式还有另外一个可能的隐忧：大量AJAX的应用可能会拖慢浏览器的速度，特别是一些mashup的应用，如果gadget开发者无节制的使用JS，很可能导致一进入该containing页面，浏览器就假死。

当然gadget还有一个问题就是源代码泄漏问题了，使得拷贝没有任何成本，这一点前面文章提过，他和网站AJAX应用的JS源代码泄漏其严重程度是不一样的。因为网站的核心竞争力往往并不在那点AJAX效果上面，而gadget的主要竞争力就靠这个了。

不过我看很多朋友在回复我的文章当中，反而更加看好这种“轻”应用的方式，比方说：

ScorpioX 写道

你有空可以研究一下Netvibes的结构，他们刚刚开源了。我个人认为一个显示空间和数据操作功能都有很大限制的Widget适合做一些简单的信息发布，例如RSS或邮件。太复杂的交互，Widget就捉襟见肘了。但这并不妨碍我们可以利用Widget来做一些事情，例如我刚给你的Feed在 Netvibes做了一个Widget，呵呵。http://eco.netvibes.com/widgets/241588/javaeye

Netvibes自己也做Social功能，而且也开发了Facebook的Widget，当然不可能把FB的全部功能搬进来，但进行一些短平快的查询还是很不错的。http://eco.netvibes.com/widgets/206745/facebook
Netvibes为什么要这么搞，当然是通过自己平台的能力把FB边缘化，让Netvibes成为你每日必上的网站。所以，从根本上讲，清楚自己的目的最重要。而手段可以层出不穷。

其实我觉得Netvibes现在混的一点都不好，iGoogle也没有怎么火起来，这种mashup也很难看到什么商业前景，我也不看好“轻”widget应用，当然关于这个问题见人见智。大家可以多多发表见解。


2、远程调用OpenSocial的REST API

我个人是非常推崇这种方式的开放平台的，对于开发者来说没有任何限制，可以做任何事情。因此如果OpenSocial的开发商都倾向于采用这种方式，那么我前面文章当中对于OpenSocial的一些论断是错误的，请大家不要被我前面的言论误导。

但是OpenSocial文档没有说明app开发商开发的REST应用究竟应该以何种方式呈现在OpenSocial容器网站上面，而我却认为这是至关重要的地方。比方说facebook网站是把自己定位成为一个纯粹的平台网站的，他开放任何数据给app开发商，他把app作为网站的核心价值展现出来，给app开发商最大的利益。

但是作为一个社区网站来说，如果提供这种REST API，就面临一个两难的抉择：如果把app作为网站的重要功能集成进来的话，那么app开发商事实上就在和网站自身争夺用户，网站为了保护自身的利益，就会限制app访问的数据；如果不作为网站重要功能集成的话，app开发商没有动力给你开发app。关于这一点，我在前面文章提到过：

robbin 写道

而且还有一个特别容易被忽视的关键问题：你的网站究竟是做什么的？你是做平台的？还是做社区的？

facebook网站压根就是一个做平台的网站，他的网站架构全部都是为了app服务的，除了app它啥都没有了，就连facebook自己网站提供的所有功能也全部是以app形式出现的。也正因为如此，facebook做平台才能成功。

因此这些网站断然不会扔掉目前网站积累的所有社区资源，孤注一掷的做平台。也正因为没有这样和facebook一样的决心，网站开发和运营的中心还是必然围绕社区展开，其结果就是开放平台永远不会成为他们网站的核心，永远只是锦上添花的功能。因此也就注定了他们的开放平台不会成功。

根据我了解到的一些信息来看，国内目前宣布支持OpenSocial的网站当中确实有这种担忧在内，并且开放的并不彻底。

事实上如果SNS网站虽然提供了完整的REST API支持，但是对于app应用的集成方面做的不够，或者说不热心积极整合的话，那么REST API的意义也就不大了。因为对于app开发商来说，开发app的目的是希望利用你SNS网站的平台给我带来流量和用户，如果你不提供整合手段，或者提供整合手段但是不提供良好的app推广方式的话，那我app开发商想要达到的目的根本就没有达到。

而gadget整合进来和app整合进来是不太一样的两回事：整合gadget无非就是在页面里面嵌入一个iframe，在页面开一个小天窗，增加点页面功能而已，对SNS网站本身不会形成什么冲击，有益无害，但是对开发商没有什么利益；而整合app就不一样了，需要你对自己网站本身做很大的改动，能够适应app顺利的整合进来，成为网站功能的一部分，帮助app开发商达到推广他应用和分享利益的目的。因此指望在网站现有基础上增加点OpenSocial，然后很多app就自己来了，这是不可能出现的。天上没有掉馅饼的好事。


探讨一下OpenSocial的前景

尽管OpenSocial规范支持了REST，我前面文章批评OpenSocial的很多理由可以被推翻了，但是OpenSocial的隐忧还是有很多：

1、OpenSocial的版本不一致的问题，这个问题包含两个意思：

1) OpenSocial规范自身一个版本一个版本的升级，网站不可能整齐划一的都支持到最新版本，有的支持v0.5，有的支持v0.6，有的支持v0.7。让开放者开发的应用失去了处处部署的可能性

2) 即使都支持OpenSocial的同一个版本，不同的容器网站支持的功能也各有多少，处处部署是不可能的


2、即使OpenSocial从代码上可以处处部署，但从用户角度也未必可以处处部署

毕竟不同的SNS网站侧重点是不一样的，你在一个SNS网站上面非常受欢迎的app，原封不动挪到另外一个SNS网站就未必会受到这个网站用户的欢迎。特别是国内的社区网站，都会形成一种内在的、独特的、甚至有些排外的社区文化，不同网站的社区文化是不一样的，同样的app不可能到处都吃香，成功的app必然是为这个社区用户和社区文化定制的app。

3、OpenSocial怎么鼓励app开发商？

这个问题我在前面文章详细谈过了，从OpenSocial整个战略来看，并没有考虑到app开发商的利益，而OpenSocial的不可移植性又大大增加了开发的成本，再上了SNS网站自身对于app开发商的利益争夺还是有戒备心理的，那么怎么来形成一个健康的商业生态链呢？我想这个问题我们得拭目以待了，就我个人来说，并不是那么看好。

评论

17 楼 cycles 2009-09-12  

对几个东西都不是很熟悉，所以觉得有点糊涂，我就做个假设，如果明天fb宣布，除f8外也提供一套os规范的接口，会怎样？

f8是执行，os是规范，f8没说自己是规范，而os始终是要落地的吧。所以两者不算是矛盾的东西。

而对于赚钱的问题，跟规范有什么关系？

16 楼 mayongzhan 2008-06-29  

开心网的挂件很不错.比那个汉化的myspace好很多.似乎开心目前还没开放api出来...

拭目以待,看开心怎么把数据漏出来.

国内的SNS现在都是型似神不似...

个人觉得,挖掘目前国内用户关于社交的需求才是关键.做了半天用户就不喜欢别人看到我的动作,也不想看到别人的动作.只想和好友打打在线游戏...

PS:我对于csdn比robbin还愤青...跟风搞SNS不说,还去掉了很多好的功能.也许是这些功能浪费带宽,不赢利.  两耳不闻窗外事,我只想一心只写愤青博.咋就这么的难呢?

15 楼 米牛牛 2008-06-28  

从站方/容器角度来看：OpenSocial主要是为目前还不具备开放APP接口的SNS、类SNS、或任何希望提供APP接口的网站使用的。这样的网站有几种做法：自己设计一套接口规范、按照OpenSocial来做、参照F8平台来做、这几种做法的难度、并没有实质性的区别：按照OpenSocial写出来的接口、和参照F8写出来的接口、性能差别不大、开发工作量相似；并且按照OpenSocial写接口、其他符合OpenSocial的APP可以、可能、至少容易加进来：如果因为OpenSocial容器的特点不同、版本不兼容造成困难、那么这个困难、总要比一个F8上面的同类APP转过来要小、所以这个问题、即使不是优点、但也不是缺点、是OpenSocial>=F8的关系

从APP开发者角度看、按照F8来写一个APP、和按照OpenSocial最新规范版本来写一个APP、不但并无大的差别、而且很相似、同样、一个放在某个OpenSocial容器站方的APP、在转到其他一个OpenSocial容器站方的时候、即使遇到版本/兼容/规范实现细节的问题、那也比把一个F8平台的APP转到OpenSocial平台容易、至少API的名字是一样的、所以这基本上也是OpenSocial>=F8的关系

从用户角度来看：都是从SNS站方开始、点击侧面的APP链接、最后在站方的CANVAS内部、或是在弹出的新窗口内、调出APP的内容、所以区别不大

IP over Everything成功啦、Java over Everything不太成功、这里成功与否的原因不在over Everything这一块、主要是网络部分相对简单、所以覆盖后性能损失不大、而网络本来就是用来互联的、所以简化互联接口好处很大、2方面一综合、就成啦；对于操作系统的覆盖。则基本相反、所以不太成功；所以不能以java来论OpenSocial。java为啦跨平台、和自身开发力量不足、而在性能上损失较大、OpenSocial并没有这个问题、相对于F8、OpenSocial并没有性能劣势

F8的优势在于8000万用户已经在那里啦、所以一些APP可以很快赚到钱、但这并不是F8在结构上的优势、从而也不是OpenSocial的缺点

OpenSocial并不是用来让facebook重写整个F8的、OpenSocial是用来为一个没有APP接口的网站用的、APP接口的性能、主要取决于容器本身的数据结构、即对于外部数据调用的反应速度、APP接口部分的负担并不是很重：一个网站如果开放APP很困难的话、多半是因为本身的结构的问题、如果是这样的、无论用OpenSocial还是参照F8的结构、可能都会遇到问题。OpenSocial只是一个象USB那样的接口、比如一个足球SNS、通过APP接口挂上一个足球游戏、好友之间可以组队踢球：在这个过程中、一般来说SNS如何吸引用户、游戏如何更精彩是难点、而APP接口这一块的负载通常不重、一般来说不是关键：F8可以胜任、OpenSocial也可以胜任

在站方(容器)、应用服务器、客户端3者之间、OpenSocial通过提供不同种类的API、使得在应用服务器和客户端上的负载时可调的、可互换的、说OpenSocial只能提供客户端类似于Widget方式的应用、这是不全面的、相反、OpenSocial可以提供和F8一样的结构

对比Adsense和FriendConnect的长尾特性、OpenSocial实际上是半个长尾：就是把一批具有某种SNS特征网站联合起来、从这个目的出发、OpenSocial在结构上并没有大的问题、而即使统一标准这一点、因为版本问题在各个网站之间协调不好、那也只能说OpenSocial没有得到优势、但也没有造成劣势

14 楼 s.w.pollux 2008-06-27  

希望大家不要盲目的崇拜一些人!仅此而已.

app开发商是需要鼓励,但app开发商真的不是希望他的app跑在你的容器里面!明白吗?
app开发商更乐意开发一些轻量级的widget跑在更多的容器里面.

同意以上2点的朋友就应该知道搂主地分析有没有道理了

13 楼 itmuse 2008-06-26  

非常看好facebook，精到的观点，本人刚刚开放好一个facebook实用工具，可以体验下：http://apps.facebook.com/chinese_name/

12 楼 ceci.lia 2008-06-26  

是不是应该拿facebook f8平台和google的app engine来作比较？

11 楼 naizhao 2008-06-25  

其实我很想知道，这个限制是什么呢？目前我们没有限制任何类别的挂件（违法的除外）。对于api方面，如果开发者有需求可以向我们提出，我们会尽力满足。如果是好的需求，还有可能被融入到opensocial体系里面去

10 楼 zhenxie 2008-06-25  

feisan 7 小时前
to naizhao:

给myspace的平台提个意见，现在在上面开放应用限制太多了，希望以后能更宽松一些，毕竟大多数开发者都不是要去搞破坏的。不好的应用，自然不会有人去用，更多的选择权给用户好了。

**********************************************
完全同意Feisan的看法，目前Myspace上除了和汶川地震有关的表达爱心的一个应用安装较多以外，其它最火的也只有一、两万次安装。这样很容易形成恶性循环，大家觉得Myspace上的组件没什么意思，就不会去安装。开发人员看到组件的应用不火，就懒得去开发。

开心网公测至今反馈不错，很重要的原因是他们在上线的时候就集中推出了十几个比较好玩的组件，用户体验一下子就上去了。

9 楼 naizhao 2008-06-25  

to all:
谢谢大家的支持，有兴趣和我交流的可以发邮件到javaeye at samwu dot net

8 楼 calmness 2008-06-25  

对于OpenSocial和facebook我不是太了解，大部分的认识都是道听途说，一开始一直问自己，那就是google为什么做一个OpenSocial出来，不过很明显，无非就是针对facebook，robbin列出了很多条不看好OpenSocial的原因，对于哪个好哪个坏，我还无法评价，但是我却非常佩服google的战略眼光，也许OpenSocial还不成熟，暂时还无法对抗facebook，但是他却通过OpenSocial，来培养n个facebook的对抗者，facebook做平台，那google也不自己做，但是他却提供技术服务，提供标准，为SNS平台化提供支持，集合各大站点的一起对抗facebook，不管OpenSocial是否成功，但是google的策略我是非常认可的。

7 楼 feisan 2008-06-25  

to naizhao:

给myspace的平台提个意见，现在在上面开放应用限制太多了，希望以后能更宽松一些，毕竟大多数开发者都不是要去搞破坏的。不好的应用，自然不会有人去用，更多的选择权给用户好了。

6 楼 robbin 2008-06-24  

to naizhao:

你好，谢谢你的解答，希望多交流。

5 楼 naizhao 2008-06-24  

我又来胡扯了：
1.在0.9版本的架构里，支持markup language。也就是类似fb:xxxx、xn:xxxx
2.gadget的发布，通过实现的网站来发布。比如myspace就可以在developer.myspace.cn上面发布，然后用户在apps.myspace.cn上面看到展示、安装
3.基于restful开发的app，开发者先到os（opensocial）的实现网站上面发布，程序可以放在任何地方给用户下载。用户在发布的网站上面安装（安装相当于一个允许访问自己资料的授权）后下载程序，经过一个oauth的授权验证后就可以直接在桌面使用程序。
4.提到的gadget源代码泄露。当然，用js作为前端肯定会泄露代码，并且os的实现网站也不允许你对代码做任何的混淆。但是你可以把绝大部分的运算都放在后端，自己的服务器上，通过makerequest进行交互（使用makerequest还可以避免js的跨域问题）。甚至你前端的js可以只简单做一个展示，所有获取用户信息、处理都交给后端的服务器使用restful来处理，并把最终的处理结果返回给前端的js
5.前面说到的makerequest，对数据交互的安全性也做了考虑，可以使用oauth对传送的数据进行签名，防止数据在途中被篡改
6.嵌入js过多造成浏览器假死，myspace作为国内第一家大规模运营opensocial的sns，自然是深有体会。一个myspace的用户平均会安装5个左右的挂件，每个挂件要引入10个opensocial的js库，一个用户的profile页面打开，就需要load & parse将近50个js。就算对js文件做了缓存，不需要重复下载，但parse对客户端cpu的消耗还是非常可观的。所以最近我们一直在着力解决这些问题。
7.总结下前面几点：opensocial并不是只能用js或者restful，而是两者可以混合使用。甚至用户不在使用widget的时候，你后台都可以写个crontab来做一些事情。
8.说说实现opensocial的难度。目前有shindig，有java和php两种版本，下载回来，稍微配置下就可以让你的网站支持opensocial了。哪天opensocial到v9了，升级下shindig，成本并不高。当然，myspace没有采用shindig，后端都是自己实现的，升级成本比较大。但不排除以后会使用shindig的可能性。
9.谈谈api的命名空间。目前opensocial提供的api都是很基本的，可以获取的信息非常有限。每个sns网站都有自己的特色，也不可能把opensocial的api做的非常强大，让所有网站都去兼容这个api。所以产生不同sns自己的命名空间也是很正常的。比如myspace，在opensocial的基础上做了个myopenspace，提供一些自己特有的功能，然后myspace china又在上面再加了一层myopenspacechina，提供了不少有中国特色的内容。google也在不断的把myspace一些特色的方法引入到opensocial中去。并且在未来google还会针对中国市场提供一些如在线支付等特色的方法到opensocial里面去。说实话，如何把api的方法大一统，还是一个很漫长的路。
10.想起一个很多开发者都关心的问题，但突然就忘记了。算了，想起了再说。

4 楼 harryempire 2008-06-24  

在google开发者日上，我问了一位google讲解OpenSocial的工程师“gadget使用xml文件，源代码如何保密？”，他居然回答“开源的东西本来就不应该过分保护！”晕倒，没有商业化激励，怎么能把平台做大？

3 楼 fyting 2008-06-24  

可以这么理解吗：widget/mushup只是把数据整合起来，做成类似门户；而app平台具有核心的用户数据，所有app都是以数据为中心的？两者在某种意义上是相反的，一个是整合数据，另一个是提供数据。
而OpenSocial的准确定位到底是什么呢，我总觉得和netvibes的定位有点相似……

2 楼 stingchen 2008-06-23  

这篇分析比前两篇更客观些。

还不够！

尺有所长，寸有所短。

OpenSocial不适合开发应用，那就用来开发信息传播用的小插件。假如我是卖房子的，我当然愿意开发一个小插件给任何想买房的人放在他们的社区页面上。

假如我是digg，googlemap, delicious或twitter, 我也很高兴放个小插件在其他网站上，传播一下品牌和信息。

开发商的利益可以从信息传播上体现。

1 楼 zhenxie 2008-06-23  

刚说要看Robbin评价V0.8的大作，就上来了~占个前排沙发~