原文来自：http://www.osbzr.com/1312
作者：开阖软件 Jeff 王剑锋
还是从开源的定义说起，这次发中文版：开源是充分利用分布式同行评审和流程透明化的一种软件开发方式。开源有助于更好的质量，更高的可靠性、灵活性，更低的成本，避免掠夺性的厂商锁定。
OSI把分布式同行评审放在开源定义里，因为这正是开源的核心竞争力。
前不久，我的一个朋友，某openerp在中国区合作伙伴签下了一个订单，竞争对手是一家行业软件供应商。两家公司拿出的软件从功能、架构上不分伯仲，在 最后PK过程中我的朋友说了这样一句话 —— 开源软件的质量要优于作坊软件。据说这是最后取胜的决胜关键。撇开市场因素，我觉得这个论断是有根据的。
之前看到 @出版人周筠 关于吴军先生建议让新人code review的微博及其评论，发现很多人并不知道什么是同行评审。这里分享一个链接， 同行评审常见问题解答。很喜欢开头的一段话 技术工作之所以需要接受同行评审就好比铅笔需要橡皮一样。
可见，同行评审是保证成果工作质量的重要手段。做过外包项目的都知道code review的重要性。而在开源项目里，这个流程更是至关重要。常见的开源项目平台都提供code review的功能，而且作者一般在申请review的时候并不指定具体的reviewer，而是通告给所有人。这就叫 分布式同行评审 。
在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研究不多，但我所在的openerp-community邮件列表总是收到社区成员申请merge代码到官方的review request，然后官方的review意见也会自动发送到邮件列表里。
当然，开源项目的同行评审不只限于code review，由于开源项目的流程透明化，整个开源软件的生命周期都接受任何社区成员的评审。从愿景、蓝图、技术方案选型、版本计划、代码到项目管理过程 和人员配置，把这些都开放地发布出来是为了接受更多的eyeball共同把问题和风险扼杀在萌芽阶段。
分布式的同行评审正契合了自由软件的那句名言：啤酒收费、发言免费。为了让更多关注此开源项目的人能有机会提供评审意见，开源软件项目组建立了公共的信息 发布和交流平台，并尽量使用简单的工具降低发布意见的门槛。快速对评审意见做出反馈（其实解释和拒绝也是反馈），并通过投票等民主方式决策。
开源在传递一个声音：您的意见，我们在倾听。可现实是，这种基于网络的陌生人之间的协作方式面对的是沉默的大多数。公司内的同行评审作为质量控制的一个环 节，会指定专人负责。而这种网络协作的过程里，谁都可以做也就意味着谁都可以不做。ibm dw有篇文章说开源社区里指望10%的人参与贡献已经很奢侈了。
大部分我们熟知的开源项目，contributor比例要远低于5%。而这些活跃的contributor大部分都在欧美或印度，中国的凤毛麟角。不仅是 因为语言障碍，更是文化差异。在民主国家的集会上，人们更看重自己的speech机会而不是beer。而在集权国家，笑而不语是成熟的表现。
Reviewer比Developer多，这是开源软件实现可靠、灵活、低成本、非厂商锁定这些承诺的前提。现在很多项目并没有满足这个前提，这也 是开源 软件为最终用户诟病的主要原因，也是大部分开源方案现阶段在同类应用软件中缺乏竞争力的根本原因。现阶段的解决方案大部分是“铅笔自带橡皮”。
在主导开源项目的公司工作，主要工作除了写代码，还包括评审社区的创意和代码。当然，开源项目组内部成员也会互相review。但是，这种解决方案把本来 就有限的资源投入到了本应众包到社区里的工作上，而且质量责任和开发工作完全担负在项目核心成员上，这样的操作方式比作坊软件生产方式强不了很多。
我这里想要提出的解决方案是“speech for beer”。谁做免费的发言就给谁一杯啤酒，就像电视节目上送给发言的观众小礼物一样，用物质刺激激发参与热情。对于主导开源项目的公司，与其把人力资源 放在提供评审意见上，不如外包这些工作给社区成员。因为是需方定价，这部分经费很容易控制，成本应更低。
一年前我曾为实现这个想法试图搞一个网站，希望从开源作者出钱找人有偿code review为起点激发群众参与开源的热情，但后来意识到在这些项目作者自己都没有盈利模式的现阶段，这个步子迈得太大了。做出的调整就是我自己组织基于 openerp的二次开发团队，并把我们开发的模块放到网上标价寻求code review。
code review的报酬我们按开发的工作量计算，如一个人天的工作产品拿出100元人民币作为code review的预算。任何人只要在googlecode上对这段代码找出10%的defect，我们就会依照其修正并支付给reviewer。一般来说这 100块1小时就可以赚到。没有出现过纠纷。
实际上，除了我出面请求，很少有人主动来给我们做code review。我相信这是因为他们其实并不理解我为什么要这样做，所以有此文。去年看《怪诞行为学》，知道这100块可能把参与开源这种社会行为变成了商业行为。但我相信节目上有十几个观众为纪念品而举手乱说总会带来一个忍无可忍（不求回报）的真知灼见。
如果这一点点投资和解释能够令更多人投入到共同改善开源软件的事业中来，增强开源软件和服务在市场上的竞争力，我个人认为是值得的。
