Why

OSI组织对开源的定义，我斗胆翻译为中文：

开源是充分利用分布式同行评审和流程透明化的一种软件开发方式。
开源有助于更好的质量，更高的可靠性、灵活性，更低的成本，避免掠夺性的厂商锁定。

OSI把分布式同行评审放在开源定义里，因为这正是开源的核心竞争力。

几年前，我的一个朋友，某openerp中国合作伙伴签下了一个订单，竞争对手是一家行业软件供应商。两家公司拿出的软件从功能、架构上不分伯仲，在 最后PK过程中我的朋友说了这样一句话

> 开源软件的质量要优于作坊软件。

据说这是最后取胜的决胜关键。撇开市场因素，我觉得这个论断是有根据的。

What

之前看到  @出版人周筠关于吴军先生建议让新人code review的微博及其评论，发现很多人并不知道什么是同行评审。这里分享一个链接，同行评审常见问题解答。很喜欢开头的一段话

技术工作之所以需要接受同行评审就好比铅笔需要橡皮一样。

可见，同行评审是保证成果工作质量的重要手段。做过外包项目的都知道code review的重要性。而在开源项目里，这个流程更是至关重要。常见的开源项目平台都提供code review的功能，而且作者一般在申请review的时候并不指定具体的reviewer，而是通告给所有人。这就叫 分布式同行评审 。

How

在googlecode里有Request code review的功能，会建立一个issue，描述是 Purpose of code changes on this branch: When reviewing my code changes, please focus on: After the review, I’ll merge this branch into: /branch，也就是说代码只有经过评审才能进入发布仓库。

googlecode还支持项目组外的人在代码上添加评审意见，并提交，googlecode会自动给作者发邮件提示查看评审结果并修改。我对 launchpad研究不多，但我所在的OCA邮件列表总是收到社区成员申请merge代码到官方的review request，然后官方的review意见也会自动发送到邮件列表里。

当然，开源项目的同行评审不只限于code review，由于开源项目的流程透明化，整个开源软件的生命周期都接受任何社区成员的评审。从愿景、蓝图、技术方案选型、版本计划、代码到项目管理过程 和人员配置，把这些都开放地发布出来是为了接受更多的eyeball共同把问题和风险扼杀在萌芽阶段。

分布式的同行评审正契合了自由软件的那句名言：啤酒收费、发言免费。为了让更多关注此开源项目的人能有机会提供评审意见，开源软件项目组建立了公共的信息 发布和交流平台，并尽量使用简单的工具降低发布意见的门槛。快速对评审意见做出反馈（其实解释和拒绝也是反馈），并通过投票等民主方式决策。

实际上，开源软件以鼓励附带源码的免费复制也是为了降低同行了解软件提供建议的门槛

将欲取之，必先予之

What else

开源在传递一个声音：您的意见，我们在倾听。

可现实是，这种基于网络的陌生人之间的协作方式面对的是沉默的大多数。公司内的同行评审作为质量控制的一个环 节，会指定专人负责。而这种网络协作的过程里，谁都可以做也就意味着谁都可以不做。ibm dw有篇文章说开源社区里指望10%的人参与贡献已经很奢侈了。

大部分我们熟知的开源项目，contributor比例要远低于5%。而这些活跃的contributor大部分都在欧美或印度，中国的凤毛麟角。不仅是 因为语言障碍，更是文化差异。在民主国家的集会上，人们更看重自己的speech机会而不是beer。而在集权国家，笑而不语是成熟的表现。

Reviewer比Developer多，这是开源软件实现可靠、灵活、低成本、非厂商锁定这些承诺的前提。现在很多项目并没有满足这个前提，这也 是开源 软件为最终用户诟病的主要原因，也是大部分开源方案现阶段在同类应用软件中缺乏竞争力的根本原因。现阶段的解决方案大部分是“铅笔自带橡皮”。

在主导开源项目的公司工作，主要工作除了写代码，还包括评审社区的创意和代码。当然，开源项目组内部成员也会互相review。但是，这种解决方案把本来 就有限的资源投入到了本应众包到社区里的工作上，而且质量责任和开发工作完全担负在项目核心成员上，这样的操作方式比作坊软件生产方式强不了很多。