一、研发工具与研发模式 据说，人之区别于禽兽，最大的特征在于利用，甚至发明工具。在没有任何其他工具时，我们只能借助于自己的肢体，一旦有了工具之后，我们的能力将会大大的增加。
但是，从另一个角度来看，工具也同时在限制我们的能力，甚至限制了我们的行为模式与思维模式。有一句俗话说得好：手里拿着锤子，看见什么都像钉子。 而在研发工具的领域，我们观察到另外一些有趣的现象：因为软件研发工具的开发者，同时也是工具的使用者。因此，他们不仅仅会受制于工具，也往往会由此被激发，开发出对自己而言更加趁手的工具。开发者与使用者身份合二为一的现象，使得研发工具的发展，简直可以用“日新月异”、“层出不穷”甚至“争奇斗艳”来形容。 随着软件复杂性的不断增加，以及软件开发的参与者不断增多，团队协作的辅助软件，也开始不断增加，随后我们发现：工具不仅仅限制了个人的行为模式，更进一步限制了团队的协作模式。 软件研发企业的管理者，往往会有某种错觉，他们会认为：管理就是定下制度、流程与规范，然后“下面的人”就会照此执行。因为有人“听话”，有人“不听话”，所以才需要奖励与惩罚的制度，来帮助管理者推行他的“规则”。所以，他们一般都很喜欢看《执行力》这样的书。 在开源社区，事情变得有些不一样。虽说开源社区也有“领导者”，甚至往往会有“精神领袖”，但他们并没有暴力手段，也没有经济手段，甚至行政手段。因此，要协调一帮自由散漫的黑客，共同开发高质量的开源软件，必须有更加高明的手段。 由于一切都是 Open 的，所以：不仅代码人人可见，开源社区的协作模式，也暴露在众目睽睽之下。从某种意义上来说：这促进了开源社区的协作工具的开发、进而使得开源的研发协作模式，以远远超过企业内部的演化速度飞速演化。 二、第一代开源协作模式 第一代开源协作模式，在早期几乎没有符合自身特殊需要的工具，有什么用什么，因此最为常用的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 也会定义一个预期完成时间。 这是好事？还是坏事？其实很难评价，因为从开源的原始教义而言：所有的贡献，都是自愿、随机、不可预期的。为自然生长的软件，规定里程碑，本来就显得荒谬。但是，从另一方面而言，我们可以引用另一个中国人过马路的例子：“不管红绿灯，凑够一堆人就过马路”，开源软件，往往也是“不管里程碑，稳定一堆特性和 bugfix，就发布一个版本”。 如果在开源软件很少，更别提形成开源生态圈的情况下，这种随意的做法还是可行的。但是在大量软件，相互依赖的情况下，一个开源项目要赢得其他协作项目的信赖与协作，必须给出稳定的规划，以便相互配合。 这种规范，也是被逼出来的。 服务平台化 虽然黑客们喜欢写程序，但是要写的程序实在太多了，能够不重复造轮子，有现成的好工具可以直接拿来用，也是件好事。如果可以打开一个网站，注册一个用户，创建一个新的项目，剩下的事情自有平台帮忙打理，那么大家都可以愉快、专心的写自己的代码了。 平台在逐步进化，因而能够帮助开源项目，打理越来越多的事务。通常主流的开源项目托管平台，都能够完成：
更进一步的，还有能够完成：简单的自定义工作流、文件夹与静态资源管理、输出各种统计报表、甚至提供论坛、搜索、邮件列表以及各种排行榜等等。 在此之前，一个开源项目，是一个社区。到了大平台的时代，整个平台，构成了一个更大的社区。 总结：以 Web 形式提供的集成化开源项目托管平台，标志着开源项目的协作模式，进入成熟期 |
