开源组织管理模式演变

这篇文章出自好友老庄（庄表伟）的公众号（zbw_blog），文章叫：三代开源社区的协作模式。请大家订阅(zbw_blog)来持续关注老庄的更多更好的文章。

老庄经历了盛大的类似论坛BBS的积分绩效机制，也经历了盛大创新院的类似水浒个人英雄好汉的社区管理与协作机制，老庄目前在华为这个庞大严谨体系内专门融入世界开源社区大体系内做开源。这些经历的思考都会点滴融入这篇文章，大家都能够感觉到老庄其实在思考探索软件公司组织的管理模式

一、研发工具与研发模式相互影响

工具也同时在限制我们的能力，甚至限制了我们的行为模式与思维模式。有一句俗话说得好：「手里拿着锤子，看见什么都像钉子。」

在研发工具的领域，我们观察到另外一些有趣的现象：因为软件研发工具的开发者，同时也是工具的使用者。因此，他们不仅仅会受制于工具，也往往会由此被激发，开发出对自己而言更加趁手的工具。开发者与使用者身份合二为一，这个现象值得深思。

随着软件复杂性的不断增加，以及软件开发的参与者不断增多，随后我们发现：工具不仅仅限制了个人的行为模式，更进一步限制了团队的协作模式。

软件研发企业的管理者，往往会有某种错觉：管理就是定下制度、流程与规范，然后「下面的人」就会照此执行。因为有人「听话」，有人「不听话」，所以才需要奖励与惩罚的制度，来帮助管理者推行他的「规则」。所以，他们一般都很喜欢看《执行力》这样的书。

在开源社区，事情变得有些不一样。虽说开源社区也有「领导者」，甚至往往会有「精神领袖」，但他们并没有暴力手段，也没有经济手段，甚至行政手段。因此，要协调一帮自由散漫的黑客，共同开发高质量的开源软件，必须有更加高明的手段。

由于一切都是Open的，所以：不仅代码人人可见，开源社区的协作模式，也暴露在众目睽睽之下。

从某种意义上来说：开放式人才吸纳、开放式竞争、开放式透明，促进了开源社区的协作工具的开发、进而使得开源的研发协作模式，以远远超过企业内部的演化速度飞速演化。

二、起步期开源协作模式（想想一个创业公司人员吸引、挑选、成长、协作、沟通）

第一代开源协作模式，在早期几乎没有符合自身特殊需要的工具，有什么用什么，因此最为常用的email，被发展为Maillist，成为整个开发团

队的协作核心工具

随着软件的日益复杂，开发人员社区不断扩大，邮件列表也会不断分化，通常会划分为：核心组、开发组、用户组。开发组与用户组的邮件列表，随着软件的架构分化为多个模块，还会进一步分解。

邮件规范制度

在邮件列表里，所有的用户都是平等的，在无法用工具保障流程的情况下，社区逐渐发展出了一套严格的邮件礼仪和格式规范。不规范的邮件，不会被理睬；不礼貌的家伙，甚至会被赶走。邮件越来越多，即使分成多个邮件列表，依然太多。一封邮件，大家都来回复，严格re:的标题，组成了一个可供追溯的线索。在邮件列表里，通常出现个人的名称，加上Reported-By、Tested-By、Acked-By的标记，即是一种代表个人名义的认可，也是流程规范的一部分，更是计算各人贡献的依据。

Bug管理工具应运而生

在邮件中，有一类话题是最活跃的，那就是bug。一个bug，从提出，到最终解决，并被确认在哪一个版本中发布fix，是一种稳定的状态转化模式。一个专有的处理工具，势必应运而生。Bugzilla、trac等一批工具，就由此被创造出来了。

代码管理精英化

开源社区，表面上非常的崇尚民主自由，但实际上却盛行精英主义、甚至是个人独裁的。最大的独裁，是代码的管理权。因为作为创始人与核心开发者，他们往往以一己之力，贡献了绝大多数的代码，确定了项目最初的架构与发展方向。他们不会容忍任何人随意地向代码库提交代码。

一个新来的家伙，从没人认识，到能够独立的向代码库提交代码，非得经历艰辛的历程不可。这样的历程，简单的说，就是一次一次的Code Review。被审核通过、合入代码库的patch越多，一个人对于社区的贡献就越大，可信度也越高，身份地位也逐步提高，然后，他也就可以去

Review其他人的代码了。

三、发展期开源协作模式（想想一个发展期公司人员吸引、挑选、成长、协作、沟通）

开源协作，一开始就如同中国人过马路的例子：「不管红绿灯，凑够一堆人就过马路」，开源软件，往往也是「不管里程碑，稳定一堆特性和bugfix，就发布一个版本」。因为从开源的原始教义而言：所有的贡献，都是自愿、随机、不可预期的。为自然生长的软件，规定里程碑，本来就显得荒谬。

如果在开源软件很少，更别提形成开源生态圈的情况下，这种随意的做法还是可行的。但是在大量软件，相互依赖的情况下，一个开源项目要赢得其他协作项目的信赖与协作，必须给出稳定的规划，以便相互配合。这种规范，也是被逼出来的。

于是，在开源社区，无论是bug和feature，都被统称为issue。这些issue，被分到不同的milestone（版本），即使最后有可能延期，milestone也会定义一个预期完成时间。

于是，管理开源项目的管理软件也出现了。第二代的开源项目管理工具，可以说，主要是在向企业内的开发管理学习。文档、流程、角色、权限、统计报表等等功能

进而，从项目管理软件正在逐步进化为一个平台：在线代码浏览，并能够支持不同的配置库；需求管理、Bug管理，通常合并为Issue tracking

；版本与里程碑管理；文档编写与管理，以Wiki的形式为主

更进一步的，还有能够完成：简单的自定义工作流、输出各种统计报表、

甚至提供论坛、搜索、邮件列表以及各种排行榜等等。

四、成熟期开源协作模式（想想一个成熟期公司人员吸引、挑选、成长、协作、沟通）

能积极热情不求金钱不求名利的参与开源、并有能力贡献代码甚至核心代码的，那都是牛人。牛人需要自我存在感，而不是大家都淹没在一个个的开源项目中。

过去的开源项目与托管平台，都是以开源代码项目为中心来打造，而Github则是围绕着参与开源的人来打造。

首先满足的不是项目的需求，而是个人的需求，由于对人的黏性大大增加，也使得Github成为近年来最具吸引力的开发社区。程序员们不仅在Github上参与开源项目，更在Github上结交朋友，分享经验，增进能力。甚至这样的协作模式，还拓展到了编程领域之外，成为开放式协作的流行模式。

第一代开源协作，虽然创造了一批大大有名的项目，但事实上却是一个非常小圈子的事业。即使是最为成功的Linux内核开发，也不过1000~2000人。一旦人多事杂，就会出现管理混乱的现象。

第二代开源协作，虽然借鉴了很多企业界的规范管理经验，但是在事实上，却是不适应开源软件的风格的，举一个例子：在Redmine中存在的角色、权限、工作流之类的东西，实际开源项目使用的，却非常少。

第三代开源协作，借鉴了社交网络中的各种数值化模型，关注者数量，Star数量，Fork数量，Issue数量，Pull Request数量，都在显要位置标示出来，对于开发者形成正向激励，还有很多的统计图表，形象的展示了项目的活跃程度。

原来的开源社区，开发者修改了代码，希望能够贡献给社区，需要穿越种种障碍，如果社区不接受，最后开发者只能逼不得已，自己开一个新的分支，变成一个新的项目。在分裂是异常的状态下，分裂是罪恶的，是不应该的，是会带来阵痛的。

当分裂变得常态化，pull request也变得常态化，分分合合，以每天N次的速度发生，恰恰因为如此，他不再是一种罪恶，而是一种健康的、向上的、以更快速度进步的模式。大家不再是在一个版本下，各自贡献，而是在各自的版本下，独立发展，想分就分，想合就合。

Resume Service，根据开发者在Github上的各种社交行为与开源项目贡献度，自动生成格式化的简历

五、未来思考

1、「开源社区的协作模式为何会变？变化背后的逻辑是什么？」

开源社区研发工具的两大目标：降低门槛，提高效率

在《大教堂与集市》中，Eric Steven Raymond总结到：「如果开发者协调者有至少一个像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战」，这简直就是绝妙的预言。

所以，开源社区一直在致力于两个看上去相反的目标：「吸引尽可能多的人，以尽可能简单、便捷的方式，参与到开源中来」、「在人多得超乎想象的情况下，依然能够保持，甚至不断提高效率」。（这两个目标也是所有企业都想做到的啊）

2、如何计算参与者的贡献？

开源社区，不会给参与者发工资，因此激励是一个大问题。公平、公开、公正大计算所有参与者的贡献，以所有人都能够接受都形式，计算并公布各种排行榜，可以说是开源社区特有都「刚性需求」，因此SNS与开源社区的结合，成为必然。以后，面向开源协作的大数据分析，也一定会出现。

3、如何激励、吸引、回报参与者？

计算参与者的贡献，仅仅是公平激励的基础。让激励变得有趣，变得有价值，变得有意义，则是吸引与回报参与者的不二法门。因此：游戏化的思路，会被越来越多的引入到开源社区中来。

4、如何保障项目质量？

开源项目保障项目质量都最大利器，是引入数量众多的热心测试者。但是，仅仅有人愿意测试，主动、积极都帮助测试，已经越来越不够了。随着项目越来越复杂，开源项目必须逐步走出仅仅依赖肉眼、依赖人多＋运气的质量保障模式。

自动化测试、以及更加规范的Review流程，则是必然出现，而且将越来越重要的环节之一。

5、如何协调一致的工作？

自由与规范，计划与变化，兴趣与责任。经常会在社区里，成为争论的热点话题。

因此：「某种调节手段、协调者与协调机制、甚至是看不见的手」之类的东西，会慢慢的回到社区。

6、如何在社区里平等、高效的协商？

目前来说，依然只能是线上讨论+线下开会。虽然，很多开源社区，开始学习《罗伯特议事规则》这样的开会圣经。但是，开会依然是最令程序员感到苦恼的事情。在这方面，将来会不会出现更好的辅助工具，这方面很值得期待。