开源基础设施

第一代开源基础设施与协作模式

第一代开源协作模式，在早期几乎没有符合自身特殊需要的工具，有什么用什么，因此最为常用的email，被发展为Maillist，成为整个开发团队的协作核心工具，大多数操作系统内置的diff/patch工具，使得代码的交流以email patch为主。这些老牌的开源项目，从使用RCS、CVS，到了后来也开始逐步引入svn/git，bugzilla这样的工具，但是围绕mailing list开展协作的特征，则持久不变。

作为协作核心的Maillist

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

在邮件列表里，所有的用户都是平等的，在无法用工具保障流程的情况下，社区逐渐发展出了一套严格的邮件礼仪和格式规范。不规范的邮件，不会被理睬；不礼貌的家伙，甚至会被赶走。

邮件越来越多，即使分成多个邮件列表，依然太多。Archive这样的邮件归档、查阅的工具，就必须得有了。一封邮件，大家都来回复，严格re:的标题，组成了一个可供追溯的线索。

在邮件列表里，通常出现个人的名称，加上Reported-By、Tested-By、Acked-By的标记，即是一种代表个人名义的认可，也是流程规范的一部分，更是计算各人贡献的依据。

Bugzilla应运而生

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

代码提交流程的规范化

开源社区，表面上非常的崇尚民主自由，但实际上却盛行精英主义、甚至是个人独裁的。我们往往会给某个开源项目的创始人，冠以「仁慈的独裁者」的头衔。虽然，是否仁慈，大家不得而知，但独裁确实是显然的了。

最大的独裁，是代码的管理权。因为作为创始人与核心开发者，他们往往以一己之力，贡献了绝大多数的代码，确定了项目最初的架构与发展方向。他们不会容忍任何人随意地向代码库提交代码。

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

总结：在简陋的工具条件下，发展出高效、严格的社区协作模式

第二代开源基础设施与协作模式

第二代开源协作模式，有两大特征：Web化、集成化。随着Web技术的不断成熟，开源社区也开始创造一个又一个的Web开源项目，其中Web化的项目管理工具，如雨后春笋般冒了出来。在wikipedia上，issue-tracking systems列出了55个，project management software列出了152个，其中开源的也有30+，open-source software hosting列出了22个，堪称蔚为壮观。

这类平台又可以分为两大类：基于开源的项目管理工具或issue tracking工具，自建平台，以JIRA、DotProject、Redmine为代表；基于免费开源托管平台，以SourceForge、Google、LaunchPad为代表；

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

以SourceForge与Google Code为代表的开源托管平台免除了开源项目搭建自己的官方网站，管理工具，代码仓库之类的繁琐事务，大大促进了开源项目的发展。不过，由于平台的功能总是受限的，因此自建门户，自组工具的开源项目依然层出不穷。

issue & milestone

在第二代开源协作模式日渐成熟的过程中，另一股潮流也正方兴未艾：「敏捷软件开发」。其中，最为深入人心的概念之一，就是每个迭代，完成一批User Story。

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

服务平台化

平台在逐步进化，因而能够帮助开源项目，打理越来越多的事务。通常主流的开源项目托管平台，都能够完成：

在线代码浏览，并能够支持不同的配置库
需求管理、Bug管理，通常合并为Issue tracking
版本与里程碑管理
文档编写与管理，以Wiki的形式为主

更进一步的，还有能够完成：简单的自定义工作流、文件夹与静态资源管理、输出各种统计报表、甚至提供论坛、搜索、邮件列表以及各种排行榜等等。

总结：以Web形式提供的集成化开源项目托管平台，标志着开源项目的协作模式，进入成熟期

第三代开源基础设施与协作模式

随着MySpace、Facebook与Twitter这样的SNS网站的兴起，开源项目的协作模式，受到SNS的启发，也随之进入了第三代，以Social Coding为核心的开发协作模式，这样的模式在以Github为代表的网站上，体现的最为充分，众多的模仿者也层出不穷。

围绕着Github，一大批周边扩展服务被建立起来，构成了一个更加有活力的生态圈。而程序员们，不仅在Github上参与开源项目，更在Github上结交朋友，分享经验，增进能力。甚至这样的协作模式，还拓展到了编程领域之外，成为开放式协作的流行模式。

激励机制

第三代开源协作模式，以Github为代表，以Social Coding为精髓，这一代模式想要解决的问题，是激励机制的问题。

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

开源社区，原本就有非常深厚的，统计补丁数计算贡献度的传统，这一点在Github被发扬光大，可以说是优秀的继承与创新。

基于fork/pull request的协作机制

在github，一键就能够fork自己的分支，然后可以跟原有的分支毫无关联，也可以非常方便的提交pull request，这就带来了更加频繁的分裂，使得分裂常态化了。

原来的开源社区，开发者修改了代码，希望能够贡献给社区，需要穿越种种障碍，如果社区不接受，最后开发者只能逼不得已，自己开一个新的分支，变成一个新的项目。

Pull request，从一个代码合并的方式，变成了开发者之间主要的交流方式，他们发现，最好的交流，正是通过源代码来交流，一切的讲道理，都不如用源代码来讲道理。这恰恰是程序员们最习惯，也最喜欢的一种交流方式。

围绕Github出现的扩展服务

与其他项目管理工具集成（Bugzilla，Asana， Basecamp，Redmine，JIRA，ZohoProject）
与持续集成服务集成（Travis，Bamboo，CircleCI）
与消息通知服务集成（Amazon SNS，Email，IRC，Jabber）
与DevOps服务集成（AWS OpsWorks， DeployHQ）

这些扩展服务，极大的丰富了开源生态圈的内涵。

最新的发展，是GitHub的Robot与Actions，基本上内置了开源开发协作所需要的一切功能。

总结：社区天生就应该是社交化的，Social Coding与开源社区，简直就是天作之和。

暗线：工具、习俗背后的逻辑

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

开源社区研发工具的两大目标：降低门槛，提高效率
如何计算参与者的贡献？
如何激励、吸引、回报参与者？
如何保障项目质量？
如何协调一致的工作？
如何在社区里平等、高效的协商？

开源社 —— 开源书籍