社交网站，何去何从？

除非赚取金钱，任何重复的事情，大抵懒人们都会有排斥心理。

最近GMail里面的邀请信愈发多了起来，这些邀请来自常见的社交网站，以不排斥新事物为原则，一一欣然注册。这个过程中，一遍一遍的填写用户资料，上传头像的动作之后，也让人精疲力竭，更是懒于每天逐个访问这些网站，开始真正的社交历程。不晓得像我这样的用户会有多少，即使我们有精力去访问几个自己中意的网站，但是可能也没有多少人愿意就重复的主题浪费自己的时间——作为豆瓣的用户，如果已经在其网站上甚至自己的博客上发表了某篇影评，访问海内时又看到类似的话题，你还愿意再做一遍吗？

这就引出了一个问题，如何让用户通过唯一的信息源和各色社交网站的好友交流？不能否认，当前的社交网站之间的竞争仍然是以建设网站本身来吸引用户量为中心：只有拥有了一定的用户量为基础，才能基于此进行广告等营销业务，即便如Facebook提供API，也是希望以更多的应用吸引用户。这种局面和即时消息的发展状况类似：各自形成一定用户量的规模，而对于用户来说，如果想同时和名目繁多的即时消息用户交流，必然需要忍受同时打开若干个即时消息客户端的痛苦——不管某个社交网站如何的好，其分属的用户之间还是没有办法交流，形成这种“不相往来”的局面，无疑对以此为基础的营销业务的增长没有益处。

互联网的理想是多个层面的互联互通，应用层面亦如是。如果社交网站可以互联互通，用户可以只在一个自己喜欢的网站下和所有社交网站的用户交流，实在是一件很美好的事情。只是在目前以争夺用户为利益的背景下，理想终究是理想，这样的实现过程必将困难重重。

在用户注册相对廉价的今天，通过遍历先前用户的邮件和即时消息列表便可以通知成百上千的潜在用户注册，社交网站的用户数完全可以迅速增加。因此，实名制和应用便成为吸引和粘着用户的重要因素，对于不以实名制为原则的社交网站来说应用更加重要。如何将自有应用适配其他社交网站用户就成为了需要考虑的问题。

另外，想到BSP之间博客大搬家的往事，如果将来真的出现互联互通，比如基于Google的OpenSociety，彼时国内是否会出现社交网站互相导入用户的闹剧？

即时消息目前已经出现了MSN和Yahoo，Google和AIM的互通趋势，而早在这之前，就已经出现了Gaim这样大包大揽的综合客户端：用户可以在这一个客户端上实现和所有的即时消息用户互通。参考这样的思路，再结合Web2.0的技术特征，社交网站是否可以提供RSS输出，方便用户使用自己喜欢的RSS阅读器去接收一些基本的信息，比如好友动态、共享条目、事件等等？这种过渡的方式，不会损失网站本身的用户群，又省去用户重复登录多个网站之繁琐，也完全可以借助RSS的输出添加广告，完成营销。从某种意义上说，这也会成为广大用户喜闻乐见的一种社交网站应用。即使损失了一些基本PV，可是在“应用为王”的发展趋势下，用户愿意使用的应用终究还是要回到浏览器里，对于这些应用的PV并无多大影响，何乐而不为呢？