Filed Under : 
6 月.2,2014
技术人员主要分为两种，参加技术活动和不参加技术活动的。
技术活动也分为两种，由中立机构、社区、媒体举办的技术活动；由企业（有自己产品的，而不是媒体型的企业）举办的技术活动。
今天要讨论的是由企业举办的技术活动。
企业，肯定并不是以作技术活动为生。企业做技术活动，通常都是需要花费高额的费用，以实现明确目标。
下面从企业的角度出发，来阐述一下，应该如何操办技术活动。
Posts Tagged ‘社区’
前面写了很多关于互联网社区的信息流转方式的东西，还写到了最具中国特色的两种信息流转方式之一，QQ群。今天要来说一说另外一种中国特色的社区信息流转方式——论坛。
前面的文章出来之后，我们的大妈就写了一篇文章来论证为什么技术社区不能采用QQ群的形式。我的看法倒是没有那么极端，使用的工具、管理者自己的管理方式、以及工具设定的各种规则，一起决定了信息的流转方式，而信息的流转方式则会决定社区的风格。国内的技术社区，可以选择不同的方式来运行，而且确实有很多社区是选择建立QQ群的，当然，这些选择QQ群的社区，可能在选择之前，并没有意识到这种选择带来的后果。大部分社区即使不使用QQ群作为主要的信息流转方式，也至少会建立一些QQ群来进行某些小范围的沟通。很多技术社区，或非技术社区中，大家互相交换qq号的事情，也是非常普遍的。
希望今天这篇文章出来之后，还可以看到大妈写的中国技术社区最好不要采用论坛这种形式的文章吧。
这个系列讨论了互联网社区的各种不同的信息流转方式。上一篇关于邮件和邮件群组的文章最后写了一个关于中国人的笑话，那么这一篇就来讨论一下最具中国特色的两种社区形态的信息流转方式之一吧。
这是一个讨论互联网社区信息流转方式的系列。前面介绍了不同的流转方式之间演进的过程，以及演进所遵循的基本规则。也介绍了最原始的信息流转方式，并在上篇《互联网社区的原始信息流转方式——邮件和邮件群组》文章的最后，给出了一个关于国人的笑话，那么这一篇就来稍微讨论一下对于中国人的互联网生态影响最大的，最具中国特色的两种互联网社区形态之一，以及这种形态所使用的信息流转方式。
上一篇文章《互联网社区中的信息流转方式》中介绍了互联网社区中的不同信息流转方式。以及这些信息流转方式之间是如何进行演化的。
这个演化的过程，简单地说就是：
- 从无序中发现有效的次序；
- 用更少的人为更多的人服务。
今天的这篇文章中希望可以和大家聊聊，最早的互联网社区信息流转方式，邮件和邮件群组。
邮件
邮件算是互联网最早的应用形式之一了。邮件和互联网之间，应该算是鸡生蛋蛋生鸡的关系，到底谁孕育了谁这个问题，现在已经没有必要讨论了。
邮件是一种最原始的信息交互方式，一封邮件上写着收件人、发件人、标题、正文等等。可以让信息从发件人那里，传递到发件人知道邮箱地址的收件人手中。
这就是信息的流动了。
- 发件人知道收件人的邮件地址
- 发件人决定要发出邮件给收件人
- 收件人能够阅读发件人发过来的信息
- 收件人知道了发件人的地址，可以回复邮件
- 收件人可以转发邮件给第三个人
- 第三个人，知道了前面两个人的邮件地址，可以选择回复或重新写邮件给这些人
上面描述的过程，仅仅是一个发件人，将信息发给了一个收件人。那么，当一个发件人希望将邮件发给多个收件人的时候呢？
- 发件人知道一些收件人的邮件地址
- 发件人决定向这一些收件人发送邮件
- 这一些收件人收到了信息，并知道了互相彼此，以及发件人的邮件地址
- 这些互相之间知道了邮件地址的人，可以选择回复或发送信息——
- 给上一个发件人
- 给所有其他人
- 其他不在这些人中的，自己知道邮件地址的人
- 这群人或其他人的各种排列组合
之所以要将这个过程描述得这么繁复，就是为了告诉大家，信息流就是这样形成的，那种能够让讨论不断进行下去的链式反应就是这样形成的。如果形不成这样的链式反应，讨论就无法进行下去，那么社区就不会诞生，因为社区不能为讨论者带来价值（及时、有效的反馈）。
邮件群组
仅仅有了邮件，社区还是很难生存的。社区是一群相对固定的人，而邮件则是一个开放的系统。互相之间发送邮件唯一需要的条件就是知道对方的邮件地址。于是邮件系统就进化了，出现了邮件群组。邮件群组解决了几个问题：
- 不需要每次书写一大堆的邮件地址了，一个群组的邮件地址就代表了群组中所有的人
- 人们在知道群组地址的情况下，可以选择是否要订阅群组，从而接收到群组的信息。订阅并不完全是主动行为
- 发件人，通常不知道每一个收件人的地址，而是只知道群组的地址
- 群组中的人，可以对群组邮件单独处理，不需要将群组邮件和普通邮件混在一起
- 有一个地方，能够记录所有人在群组中的讨论，并可以提供搜索服务
- 可以确认谁有权利在群组中发言
信息是怎么在群组中流动的呢？
- 发件人知道群组的地址
- 发件人向群组发送了邮件
- 群组判定发件人是否有权向群组发送邮件
- 如果发件人有权向群组发送信息，那么将信息发给群组的每一个订阅者
- 订阅者接收到信息，并阅读信息
- 群组记录信息，以备后续查询之用
- 收到信息的人，可以向群组发送回复
- 群组判定再次发出的信息的发件人，是否有权限向群组发送信息
邮件群组并不都是用来做社区的，有很多邮件群组中的订阅者，是不允许向群组中发送邮件的。比如那些新闻订阅群组，用户订阅了，就可以定期收到新闻，但却不能够将信息发回到这个群组中去。在邮件群组中，用户通常有权利选择是否要订阅，用户自己的地址，是被保护的。这其中，有一种群组，为社区提供了有力的支撑。那就是群组中每一个订阅者都可以发言，都可以向群组中发信息的那一种。在这种群组中，信息流转的链式反应是很容易建立起来的。这种群组中的信息流转通常是这样的：
- 一群人，出于某种目的，建立了一个群组
- 群组中的一个人向群组中发送了邮件
- 群组中的其他人，收到了邮件
- 然后群组中的每一个人，都有权回复这封邮件给群组中的所有其他人
这就像题图中所画得那样，一些人围绕着一个不大的会议桌开会，其中一个说话了，桌子边的其他人都可以听到，然后他们再选择是否要继续这个话题讨论下去。如果桌边有一些人对这个话题感兴趣，那么这些人就会就这个话题讨论下去，他人不是那么感兴趣的人们，可以选择只听不说。一个相对固定的人群，在有人提出了有趣话题之后，就能够形成信息传递的链式反应，并在讨论的过程中为参与者提供了价值，社区就形成了。
所有在互联网上出现的信息流转方式，都可以在现实生活中找到原型。
邮件群组解决了邮件在信息交流中的一些问题，从无序中发现了秩序，而且这种秩序对于某种形式的信息产生和流转来说是更有效率的。于是，这种形式被固定了下来，并一直持续到了现在，目前依然有很多社区是以邮件群组的形式来组织的。当然，现在的邮件群组的功能已经更加完善了，可以解决的问题也更多了。
不过邮件群组也有些问题处理得不是很好。
- 时效性
邮件本身就不具备时效性。一个群组中的人们，每个人在线和处理邮件的时间都是不固定的，所以邮件群组中信息流转的速度通常不快。如果邮件群组中所有的成员都在同一个时区，并工作生活习惯比较接近，那么大家通常在同一个时间段来处理邮件。在大家都处理邮件的时间段，邮件群组就会非常活跃，在大部分人都在睡觉的时候，邮件群组也会比较安静。如果是成员分布涵盖全球不同时区的邮件群组，那么问题得到反馈的速度通常是以天计的。
- 交流的顺序
- 信息A被发送到群组
- 所有成员看到了信息A
- 几个成员回复了信息：A1…An
- 信息A1…An被所有成员看到
- 有些成员依然在回复A
- 有些成员则开始回复A1…An中任意一条或多条，得到了信息A11…Ann
- 大家再回复
- 信息过载
- 当群组中的人比较多，而且都很活跃
- 一个用户订阅的群组比较多
- 当一个群组中同时讨论的问题比较多
- 当一个群组中讨论得比较激烈的时候
信息过载了，用户会感到无所适从，信息流动的链式反应会断掉，线索会被埋没。
基于邮件群组的社区必然会受到一些限制：
- 大家必须采用相同语言（这不是废话，有些以图片、音乐为基础的社区，并不一定要有相同的语言）
- 信息的流转不能太快，否则就会因为交流的无序，而破坏信息流转的链式反应，丢失线索
- 同时讨论的问题不能太多，这个问题通过标题、标签、群组的分支被部分的解决了。不过歪楼、灌水这些事情自古有之，所以在同一个群组中同时讨论的事情太多依然是不推荐的做法
总结
邮件和邮件群组，算是最早的互联网社区中所使用的信息流转方式了。甚至可以说是这两种形式孵化出了互联网和互联网社区。这些古老的、混沌的信息传播方式，直到现在为止，依然是很大一部分社区所选择的主要信息流转方式，即使社区现在有其他更有效率的信息流转方式，社区成员之间依然会使用邮件和群组来进行一下信息流转的补充。信息流转方式的演进过程是从无序中发现有效的秩序，其实也可以说是通过各种规则，将那些不符合的部分给剔除掉了。那么，当有时候某些信息的流转需要绕过规则的时候，邮件和群组就是一种非常棒的补充方式。
上面说了那个围绕桌子开会的故事，但是群组和这些围着桌子的人之间还是有差别的，那就是群组中每个人的距离都是相同的，而这在超过3个人的桌子边上就不能成立了。那么当桌上的人想要和身边的人交头接耳一下的时候，应该怎么办呢？选择比群组更原始的方式，直接给某个人写邮件就好了。这些邮件可以在讨论在特定时间从新回到群组中去。这就是一个当秩序无法满足沟通交流要求时，向后退一步的典型案例。
最后补充一个关于信息流转的笑话。
很多亚洲人都会组团出去旅游，对于欧美国家的人来说，他们很难分辨得清中国人、日本人和韩国人。后来有人发现了一个规律，来帮助他们进行这种分辨。一群亚洲人聚集在一起，一个人在大声说着什么，其他人都在认真听的，是日本人；好几个人都在很大声的说着什么，好像正在吵架，其他人在认真倾听的，是韩国人；几个人在大声说，有些人在听，有些人在交头接耳，还有些人则在左顾右盼的是中国人。
基于互联网的社区本质
最近好像讲的各种本质实在是太多了一些。最近对于社区的思考也比较频繁，在以往的文章中，有时候直接说社区，有时候说技术社区，有时候说是互联网下的社区，各种定义和描述也放了很多了。本质这种定义是比较难下的，什么什么的本质，这个东西太严肃了，要求太高了，为互联网社区来描述一个本质，这违背了我写东西的原则，我是一个讲故事的人，并不喜欢那些特别严肃的东西。所以这里要说的本质，应该只能算是某一个侧面的本质吧，这确实是一种本质，但仅仅是一个侧面。
互联网社区，其实是一个计算机程序，这肯定是没有人反对，那么用计算机程序的某一种特性来作为互联网社区的本质，应该也能够说得过去吧。
这里要对互联网社区本质的定义就是，一个拥有输入、处理、输出，三个最标准环节的计算程序。
今天要探讨的是社区的信息流，也就是说，互联网社区，是如何通过处理不同的人的输入，然后为不同的用户形成输出这个本质工作，将不同的信息发送给不同的人，从而形成社区的。
前一篇文章写了社区的规则，社区的信息流是被规则所规范的，不过归根结底，互联网社区是程序，规则也是需要使用程序来执行的。还有很多程序能够做的事情，是规则所不涉及的，比如SEO和推荐算法。
互联网社区的信息流动方式
前面讲过了，社区的核心是人，但是光有人是不行的。社区是依靠人来创造内容，然后再依靠内容来吸引人的。那么信息是怎么吸引人的呢？同样的一堆信息，使用不同的排列方式，吸引力一样吗？当信息很多的时候，应该筛选出哪些信息来给用户看呢？大家看不到有价值的东西，就会离开社区。当人们发出声音的时候，不能及时得到有价值的回复，他们也会离开社区。
这篇文章要讨论的，是互联网社区信息流转方式的一个大略的演进方向，以及其中几种有代表性的信息流转方式。
互联网社区的信息流转方式，这里面的内容很多，不可能在一篇文章中说清楚，甚至我可能都没有彻底说清楚这个问题的能力，毕竟我并不是社会学家、语言学家和人类学家。这应该是这一系列文章中的第一篇，后面还将陆续写一些不同信息流转方式的案例，以及规则和算法如何影响信息流转方式，信息流转方式对于社区性格、价值的改变，如何尝试建立新的信息流转方式等等。
一个最典型的信息流转——
- 甲提出了一个观点，以及一些疑惑
- 5分钟后，乙表示自己认同这个观点，并拥有相同的疑惑
- 有一些人看到了，但什么也没有说
- 又过了3分钟，丙表示，自己看到了这个问题，好像在其他地方也看到过有人在讨论，这个问题丁可能会有一定的见解，于是通知了丁
- 又有一些人看到了，但是他们依然什么也没说
- 10分钟后，丁收到了丙的通知，过来看了甲提出的观点和疑惑，于是对观点进行了一些讨论，他补充了自己在日常生活中的一些事例
- 甲先就丁提出的观点进行了讨论，然后询问丁，是否能够解答自己的疑惑
- 丁和甲进行了辩论，并对甲的疑惑提出了一些设想
- 丙邀请了更多的人进来进行讨论
- 更多地人发现了这个话题，有些人还是一言不发，但也有些人加入了讨论
- ……
- 甲的观点经过讨论和补充，变得更加完善，同时还获得了很多相关的实例，甲提出的疑惑，得到了部分或全部的解答
- 一段时间过去了
- 有人在此发现了这个话题，并进行了阅读，然后离开，或者是再在上面添加一些自己的评论
- 又一段时间过去了
- 又有人在此发现了这个话题，并进行了阅读，然后离开，或者是再在上面添加一些自己的评论
- 又一段时间过去了
- ……
这个实例里面有人提出了观点和问题，有人附和，有人帮忙寻找能够解答的人，有人参加了讨论，有人给出了解答……，这里面还包含什么呢？顺序，谁先来的，谁后到的；以及时间，几分钟，不是几秒，也不是几个小时，几天，而是几分钟；有人发现了问题，这些人是怎么筛选的，他们是否对这个问题感兴趣。这些都是组成社区讨论信息流的各种因素，当这些因素发生变化的时候，信息流也就发生了变化。
互联网社区里面的信息流，有些像是核反应里面的链式反应。如果形不成链式反应，那么核反应就无法进行下去。互联网社区的信息流也需要一环扣一环，不断地发展下去，否则就会散掉，形不成完整的信息流。这些信息流的形成，通常需要两个关键条件，那就是回复和反馈，必须具有及时性和有效性。如果上面那个例子中，大家只是讨论一些简单的家长里短，但是时间间隔是以年为单位的，那就讨论不起来，如果一个人说了什么事情，紧跟着的回复都是驴唇不对马嘴的，肯定也是讨论不起来的。这里面隐含着一个观点，就是及时性的衡量是和讨论问题的性质相关的。有些问题的间隔必须是以秒为单位，有些可以是以分钟为单位，有些则可以以小时、天、月甚至是年为单位。
互联网社区信息流转方式的演化历程
由于互联网社区的本质是程序，是输入、处理和输出，那么写程序的人肯定能够根据各种数据和经验来不断地优化这些程序，让社区中信息的流转效率不断地提高。那么社区信息流转方式的演化就肯定会拥有两个核心的目标：
- 从无序到有序
互联网社区的信息流转方式的演进过程，应该可以被描述为，程序员或社区管理者（这两者经常是同一个人），在不断的观察信息流转的方式，并希望尝试从中发现一些规律，然后对这些规律进行筛选，找出那些对社区有利的规律和有害的规律，然后禁止那些有害的规律，并通过程序或规则去固化或增强那些对社区有利的规则。
由于有些规则需要经常发生调整，或需要由社区中不同角色的人来进行调整，以及互联网社区的程序可能会被那些不是程序员的人们用在不同的领域上，于是聪明的程序员们将一部分程序做成了可以设置或解释并执行某些规则的方式。这样当某些规则发生改变的时候，就不需要重新修改程序代码了。
最早的相对无序的信息流转方式，比如邮件列表，后来也发展出了一些自己的规则。真正无序的是邮件多人讨论，就是一个人给一个或多个收件人写邮件，然后收到邮件的人再进行回复或转发。邮件列表已经算是在这种形式上发展出来的一种相对有效的方法了。邮件列表的规则通常是围绕准入制度的，谁能够看到这些邮件讨论的过程，新人怎么发现这些正在讨论的内容等等。但是讨论的顺序，中间大家能够说什么，不能够说什么，谁先说、谁后说，说的时候是不是要引用前面说过的内容，新的内容哪些人可以看，哪些人不能看，这些都是不能规范的，混沌的。不过有些讨论会进行得很好，很快得到有价值的东西，有些则很快歪楼，大家最后谁也不知道在讨论什么，然后散掉。
这个时候，聪明的程序员们就去设法分析那些有价值的讨论，看看他们是怎么做的。然后总结这些规律，再设计出新的信息流转方式，比如论坛、问答等等。
- 用更少的人，为更多的人服务，以及分工的不断明确
这其实并不仅仅是互联网社区这一种特殊程序在演化过程中的追求，很多系统都在不断的追求这个。
从邮件列表中，每一个人都是组织者、规则制定和执行者、内容的贡献和消费者这种混沌状态中，发展到各种职能都比较清晰。到了论坛时代，组织者就是组织者，他们订立和修正规则，监控讨论的进行；然后通过规则，去奖励那些有效、有价值的内容贡献者；吸引那些内容的消费者。
然后，到了所谓的web2.0时代，更多地人开始参与讨论，更多的人能够创造出内容来，给更多地人消费。比如盛大文学，10万人写小说，上亿的人，付费来看这些小说。在这个过程中，组织者相对于内容的生产者和消费者来说，比例更少了。
百度贴吧替代了传统的论坛，在论坛上，几个管理员需要自己负责找服务器来搭建论坛，需要设定论坛的规则，并维护论坛的运行。而在百度贴吧上，百度已经把服务器什么的都搞定了，贴吧里面那些吧主，就像论坛里面的版主一样，并不是专职员工，他们只需要对自己的吧负责就可以了，其他的都不需要管。这个服务比例一下就从几个管理员为几百上千会员服务，升级到了几十个贴吧员工，为几亿人服务。
Tumblr和其他一些内容社区的涌现，Facebook和Twitter、新浪微博之类的社区的崛起，最终使得很少的人，就可以为全世界的人服务了。
总结
互联网社区的本质就是一个集输入、处理、输出为一身的程序。社区的核心就是信息从一个人，流向另一个人，社区的发展，就是社区中信息流转方式的不断进化和发展。
社区信息流转方式的发展，一直围绕着两个中心：
- 从无序中发现秩序，固化并增强某些特定的模式
- 用更少的人，为更多地人服务，分工不断细化
以后再用更多地文字来描述不同特色的信息流转方式，以及不同的信息流转方式为社区带来的不同的风格和价值吧。
前面的很多文章中，都反复的描述了社区是具备生长型的。这种生长性来是来自于组成社区的人自身所携带的动物性本能。这是不可抑制的。但是，生长是有方向的，虽然生长本身是不可抑制的，但是生长的方向却是可以引导的。
那些建立或管理社区的人，对于社区的未来是有憧憬的，他们会期望社区发展成什么什么样子，于是就会设置各种各样的规则，来引导社区在生长的过程中向着自己所预期的那样发展。就像父母期望孩子今后能够如何如何，于是现在就要为之付出各种努力。
前面几篇文章探讨了社区的一些情况，探讨了社区进行企业化管理过程中的发生的问题，探讨了企业为什么会越来越关注技术社区。
现在，我们来探讨一下，那些直接由企业建立的社区是什么样子的吧。当然，这里所说的企业建立的技术社区，并不是指的那些自发社区，职业化之后形成的由公司运营的社区。而是那些由产品或平台服务提供商建立，并维系的社区。这里也不讨论那种媒体企业建立和运营的社区，这主要有两个原因：第一、自发社区职业化之后，大多都转向了媒体模式，所以媒体企业建立的社区和自发社区职业化之后的状态比较相近；第二、媒体企业建立的社区和自发社区之间关系相对比较简单，就是竞争。
前文讲过，企业为什么会关注社区，企业为什么会自己建立社区，以及企业建立社区是为了解决什么问题。
本文就是探讨企业自己都建立什么样的社区，以及这些社区的一些故事。
缘起
前文阐述了技术社区是什么,社区是怎么产生的,社区的目标,以及社区是不是应该采用KPI这种企业方式来进行管理等等.
以前,企业就是企业,技术社区就是技术社区,这中间并没有什么交集. 这种状态是怎么发生改变的呢?是什么促使企业开始关注社区,甚至有些企业自己创办技术社区的呢?
最早关注开发者社区的企业,是那些开发并销售开发工具的企业. 比如Borland,Microsoft,IBM. 他们发现,通过社区这种形式,对他们的产品提供客户服务,是一种非常好的办法. 开发工具类的产品,其产品复杂度,里面涉及的内容等等,都是普通软件所无法想象的. 开发工具的用户,遇到的最大的问题是不会玩儿(网络游戏经常将自己遇到的问题分为三个层级:不能玩儿,不会玩儿,不好玩儿). 开发工具的用户,提出的各种问题,纷繁复杂,并不是厂家工程师都能及时搞定的.
然后,开发工具厂家发现了一种现象,他们工具相关的很多用户问题,其他用户都可以解答. 这些用户自发的建立起了社区,在上面交流和沟通开发过程中遇到的问题.
最后,开发工具厂商采取的办法就是,自己创建开发者社区,让自己的用户可以在上面找到有用的东西.
Tags : 社区
前面讨论了社区的发展历程。很多自发形成的公益性的社区，开始面临一个艰巨的问题。那就是随着规模的扩大，必须要进行职业化转型。也就是说原来主要依靠志愿者的业务时间维系的社区，在不断扩张的规模面前，已经无法很好的运转下去了。必须要让原来的那些志愿者，脱离他们原来的工作，全职的为社区工作。
职业化之后，就必然面临一个问题，那就是需要赚取更多的钱，以支付越来越多的各种费用，雇佣更多地专职雇员，吸引更多地用户，创造更多地内容。
于是，KPI这种在公司里面十分常见的管理方法，就摆在了面前。这里就是要讨论一下社区目标和KPI之间的故事。
、
~ 开发者社区越来越被大家所关注,一个在开发者社区这个圈子里面混了很多年的人,说说自己的看法
开发者关系社区探讨
本文首先发表在一个开发者社区讨论博客中：http://devrel.info 。这是一个博客站,一个由一些和开发者打交道的人,记录和开发者关系相关的一些故事和想法. 之所以说是故事和想法,就是不希望为这里记述的东西赋予太过于严肃的色彩. 故事,那么与事实或历史稍有出入就是可以被理解的;想法,和理论比较起来,可以不是那么严谨.
这是我在这个地方的第一篇博客,想和大家讲一讲开发者社区的事情. 我是Luke Fan,一个IT圈里面混迹多年的,爱讲故事的老胖子.
