三代开源社区的协作模式

　　据说，人之区别于，最大的特征在于利用，甚至发明工具。在没有任何其他工具时，我们只能借助于自己的肢体，一旦有了工具之后，我们的能力将会大大的增加。

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

　　而在研发工具的领域，我们观察到另外一些有趣的现象：因为软件研发工具的开发者，同时也是工具的使用者。因此，他们不仅仅会受制于工具，也往往会由此被激发，开发出对自己而言更加趁手的工具。开发者与使用者身份合二为一的现象，使得研发工具的发展，简直可以用「日新月异」、「层出不穷」甚至「争奇斗艳」来形容。

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

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

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

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

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

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

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

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

　　这是好事？还是坏事？其实很难评价，因为从开源的原始教义而言：所有的贡献，都是自愿、随机、不可预期的。为自然生长的软件，里程碑，本来就显得。但是，从另一方面而言，我们可以引用另一个中国人过马的例子：「不管红绿灯，凑够一堆人就过马」，开源软件，往往也是「不管里程碑，稳定一堆特性和bugfix，就发布一个版本」。

　　虽然黑客们喜欢写程序，但是要写的程序实在太多了，能够不重复造轮子，有现成的好工具可以直接拿来用，也是件好事。如果可以打开一个网站，注册一个用户，创建一个新的项目，剩下的事情自有平台帮忙打理，那么大家都可以愉快、专心的写自己的代码了。

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

　　到了MySpace、Facebook与Twitter这样的SNS网站的兴起，开源项目的协作模式，受到SNS的，也随之进入了第三代，以Social Coding为核心的开发协作模式，这样的模式在以Github为代表的网站上，体现的最为充分，众多的模仿者也层出不穷。过去的开源项目与托管平台，都是以项目为中心来打造，而Github则是围绕着参与开源的人来打造。首先满足的不是项目的需求，而是个人的需求，由于对人的黏性大大增加，也使得Github成为近年来最具吸引力的开发社区。

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

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

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

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

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

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

　　Cloud IDE，用Github账号登录，直接在浏览器里打开一个IDE，编辑自己在Github上的开源代码

　　git与github互相促进，作为全球最大也最流行的开源社区，他的标配是git。这也导致越来越多的开源项目，选择git作为标配

　　众人拾材火焰高，越是参与开发的人不断涌入，越是帮助git发展得更快。这是一个赢家通吃的世界

　　开源生态圈的出现，使得围绕git、github发展出一大批相关的开源项目、开源工具以及次级社区。这一现象，在docker横空出世之后，再一次得到展现。

　　开源社区，一直有非常悠久的CodeReview的历史，哪怕在最早的mail & patch的时代，Review也是开源协作的头等大事。仅仅梳理Review的历程，也可以看到其中工具与流程的发展。

　　最初是邮件review，然后是在集成平台上内置review功能，或者提供更强大的review插件。到github创新的提出pull request，则是一种更加方便有效的review模式。

　　从Everything as Code到Everything Automation，是另一个越来越明显的趋势。前两天，我从机场出来，正好看到两个并列的广告牌，一个广告的大意是：「UPS助您打通全球供应链」、另一个则是「中国银行助您打通全球供应链」。这真的很有意思，看来在各行各业，大家都开始在关注整个生命周期的各个环节之间的打通。

　　只是，在软件领域，我们会感觉到这是一种回归。毕竟，最初的软件开发，都是很简单的。在一台计算机上，自己写程序，自己编译，自己调试、运行，最后发布。既不用依赖他人，更不用等待什么流程。

　　在开发者水平参差不齐的情况下，如何质量？在分工、协作、流程与质量的要求之下，如何提高效率？

　　开源社区，与普通的软件开发最大的不同，就是参与者多多益善。在《大与集市》中，Eric Steven Raymond总结到：「如果开发者协调者有至少一个像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战」，这简直就是绝妙的预言。虽然当年的ESR也许并未预测到，基于Internet会出现那么多辅助开源的相关工具（他们当时还只有邮件列表）。

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