米牛牛: 社交工具也是社区：以社交为主题的社区:):)

所有社区都是有主题的、没有没有主题的社区
钓鱼社区、小猫社区、IT社区、在家做饭社区、出去吃饭社区、交友社区、泡友社区、衣服社区、电影社区、音乐社区。。。。。

社交工具也是社区：以社交为主题的社区:):)

博客、社区、论坛之间、在技术和形式的区别都是次要的
关键是文化内涵和背景
一个社区成功啦、很多人就会去关注看这个社区的技术和形式
其实重要的不是技术和形式、而是这个社区的文化背景和内涵
随着云计算、开源软件、建站工具的普及和发展
技术和形式越来越不周要
文化大于技术、这不光是对于社区而言、对于整个WEB应用、都是这样的

[和网友讨论cache]

。。。。。

社区和社交工具并不是矛盾的：好友之间打招呼、好友之间POKE/踩一下、朋友分享一个在flickr的照片链接、朋友上传一张聚会照片到社区、朋友之间推荐感兴趣的链接(robbin的这篇文章的链接、我就是刚才在社区里看见好友分享的一个非好友的推荐、然后点过来看的)、好友转贴文章、好友分享社区外大牛的文章、好友分享社区内大牛的文章、朋友亲自写一篇日志。。。。。这些行为之间、并无本质区别：打招呼可以看作是一种UGC、写日志也是一种广义的互动：信息的种类、和信息交互的种类、是多种多样的、是互通的：facebook里面有关于某个网友组建的乐队的小组、上面有详细的乐队介绍、照片、视频、有跟贴评论、有演出预报消息、这些都是UGC的内容

BBS、SNS、BLOG、这三种形式之间、可能并不是矛盾的、而是互相包含、可以相互转化的：在某种意义上、BBS和独立博客、是SNS在群体互动和个体表达这2个方向上的极端：独立博客之间也可以加为好友、BBS上面也可以由某位网友为主开贴、若干位网友一起参与、形成相对稳定的、持续几个月甚至几年的长贴、这3者之间可以互相渗透、可能是并存和界限模糊化的关系：SNS有一个特点、就是比较灵活、可以调整好友的范围、自定义一个可大可小的圈子、过滤好友的信息：一般的用户、加上几十个好友互动、再加上几个大牛好友只听、互相打打招呼、聊聊天、传递一些链接、写一些日志、其实还是蛮有意思的

这里面的关键在于去中心化：比如一群人在一起聚会聊天：即使里面没有大牛、电影明星、都是普通人、这一群人照样可以聊的很开心、聊很长时间：对于facebook来说、就相当于这群人是熟人同学、如果对于一个有主题的SNS、就相当于这些人可能不认识、但是有共同的职业和爱好：SNS可以提供一个这样的聊天场地

我个人有一点不同的意见：在facebook模式、myspace模式之外、可以比较自然的存在很多种"混合的"模式：好友可以用真名、也可以不用、在好友圈中可以只是打招呼、也可以发表文章、可以完全去中心化的(好友全是草根、认识或不认识)、也可以把社区内的大牛加进圈子来"半互动"、还可以把社区外的大牛的RSS种子导入圈子、好友可以本来在线下就认识、或是因为某个共同点在社区内认识、或是经人推荐加入社区、最后在互动中成为真正的线下朋友、社区的主题可以是比较宽泛的、也可以是比较专一(垂直)的：社交和社区、我个人认为是可以比较自然的混在一起的、并且社区可以有很多种(比如不止2种)模式。谢谢robbin的讨论！

。。。。。

社区有很多种、不光是facebook和myspace两类、目前已经存在啦很多混合或创新的模式：

比如我加入啦一个社区、转啦一下找到一个老同学、于是经常通过社区保持联系、这算是社交

同时我加入啦一个讨论3D应用的小组、发现啦几个网友的日志很有水平、于是加为好友、经常互相交流3D方面的信息、我自己也写啦一些这方面的日志、这算是UGC

经过不断的交流、我和一位同对3D应用感兴趣的好友互相交换啦EMAIL和真实姓名、这又算是拓展社交

一个社区、完全可以同时具有社交和UGC二种功能、甚至门户、博客、BBS的因素都可以包含进来、从技术上说这种融合是可行的：一个SNS成功与否、技术和形式都不是主要的、可能主要是主题和文化背景在起作用

目前一些"UCHome们"的SNS、已经具备啦robbin所描述的"理想的社区形态"的混合模式：SNS的模式既不是单一的、也不是固定的、实际上模式最终是由这个SNS的主题来决定的

。。。。。

1个用户在网络上的行为、主要靠自己来控制：就算没有SNS、1个人也可以1天24小时泡在javaeye里面、不停的学习javaeye很好的技术内容、不停的在javaeye发表新的博客、最后忘记吃饭、饿死在计算机前面啦、这能不能说是因为javaeye刺激啦这个网友、正是javaeye使他像打了鸡血、所以javaeye的结构良好的底层数据库、和javaeye的美观实用的界面、都要对这个网友的死亡负责呢？

相反、在一个基于UCHome的SNS里面、1个用户控制自己每天在SNS里面活动的时间、控制自己的好友数量、利用SNS提供的工具有目的的过滤出自己认为有用的信息、每天首先浏览一下好友发表的UGC日志、再看一下好友推荐的种子、然后根据需要发表一些跟贴、最后可能还要自己UGC一篇日志、然后就下网去踢足球锻炼身体啦、每天在SNS上面的时间、可以是1个小时、0.5个小时、如果忙的话就根本不去SNS啦、那么在这种情况下、怎么会精疲力尽呢？

所以、如何上网、如何上SNS、在SNS花费多少精力/时间、完全是自己可以控制的：穿上球鞋跑步比穿高跟鞋更舒适、但是如果一个人不能控制自己、穿着球鞋不停的跑步最后累死啦、能不能说大家以后一定要“远离球鞋、珍惜生命”呢？

内容是由用户创造的：我在javaeye上面发表博客、和在一个SNS上面发表日志、和在我自己的blogspot上面发表博客、假如不考虑以前的老用户的话、从UGC的角度讲、对我没有本质的差别：只要我愿意、我就可以不停的在一个SNS上面发表日志：IT的、足球的、音乐的、数学/物理/哲学的、请问：SNS在哪一点上阻止我的UGC啦？SNS在什么地方使我的UGC不方便啦？只要我愿意、我就可以在一个SNS上面不停的写日志、不停的UGC。所以、UGC的数量和质量不在于是博客还是SNS、关在在于作者：高水平的文章、不管发表在博客上、还是SNS上面、都是好的UGC、SNS并没有对UGC产生任何副作用

内容、主要不是由形式决定的、是由人决定的：博客、BBS、SNS、都是信息交流、发布的工具、决定质量的关键是作者、不是形式或工具

。。。。。

一个SNS、完全可以既产生大量内容、又是一个陌生人交友社区

这里的关键在于主题的选择：在某一个主题下、陌生人可以成为好友、熟人可以社交、陌生人和熟人一起UGC：比如一个甲骨文SNS、刚开始这个SNS由社科院的专家和博士生创立、早期用户大多是熟人、大家社交；然后一些甲骨文民间学者、一些甲骨文海外学者陆续加入、大量关于甲骨文的日志产生、同时这些原先彼此不认识的学者们互相成为好友、甚至成为线下好友：在一个共同的主题下、不同的人通过SNS成为好友、大家互相促进产生UGC

通过这个系列的博客、我有一个基本的不同观点在于：我认为robbin把内容和关系对立化啦：实际上、内容和关系不是对立的、内容是人产生的、关系是人和人之间的关系、内容和关系、终将统一于人、因特网是人(或泛称智能节点)的互联、以此为根据、内容的产生和关系的维护/产生、是可以很自然的融合在一起的、实际上完全是同一类的事物

SNS的种类远远不止这2种：国内和国外的SNS、早已经存在啦混合熟人社交、陌生人交友、UGC产生、这3项于一体的SNS：在SNS领域、网站的形式并不重要、人和主题是重要的、如果需要的话、一个SNS可以把门户、媒体、WEB-MAIL、WEB-IM、视频会议、WEB-collaboration、。。。。。等等、全部mashup进去、这在技术上是可行的：因为因特网本身、既可以看作是一个信息网、也可以看作是一个关系网、并且关系本身就是信息、信息也可以由关系来促进产生、所以归根结底、因特网是人的网络、而SNS、恰恰就是人的网络的一种

黑格尔老师曾经说过：形式和理论是苍白的、实践之树长青:):)、尤其在因特网应用这样的快速发展的领域、试图通过对几个成功案例的简单的归类和分析、就可以从理论上证明别人的新的类型的网站是不合理的、证明他们注定要灭亡、这是不太可能的、新的形式会层出不穷的出现、到时你连分析的时间都没有啦:):)

【关于OpenSocial和网友的讨论】
从站方/容器角度来看：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没有得到优势、但也没有造成劣势