此篇由内部分享Session整理所得

Open Source这个topic很大，大家对这个词也已经耳熟能详了，此篇主要从以下几个方面来讲Open Source 第一是介绍下一般人对Open Source 的一些不怎么注意的地方 第二是介绍下我参与Open Source 的一些真实体会 最后，是从我个人角度来总结下我们能从Open Source的开发模式中学到哪些东西，希望能给大家在软件开发方面带来一些思考

第一个问题： 当人们在讨论Open Source的时候，他们到底在讨论什么？

我猜大多数人马上想到的一个词是”Free”。 Free有两种解释，一个是免费 一个是自由 我猜这是很多人对开源软件的一个认知，那么事实是不是真的是这样?

我们先来谈谈钱， Open Source是不是真正意义上的免费？

首先如果你花钱买了一个软件，你遇到问题的时候总会有人来帮你解决问题，因为你付了钱了 但是如果你用的是一款开源软件，你基本上就靠你自己了。当然了，你可以向社区求助，但是并不一定能得到很快地应答。 甚至你还是可以另外付钱找人来帮你解决问题，其实现在有很多公司就是做开源软件的support工作，那就不是免费的了 另外，如果你用了开源软件，用自己的品牌包装了一下，客户只会认你的品牌，如果这个开源软件出了什么问题，客户可不管开源不开源的, 出了事儿, 责任就是你的,这是潜在损失

总的来说，使用开源软件的成本来自两大块： 一个是开源软件的质量造成的成本。 虽然开源软件都会有很多测试，但有时候一些真正上线跑得业务逻辑还是会超出Open Source开发人员的想象。 而且不同的开源软件有不同的质量水平，插播一个小故事： 我有一位朋友，后来跳槽去创业公司了，开发语言从Java 变成了PHP, 我问他你是喜欢Java 还是PHP?他说当然是Java，生态系统好多了，开源的东西质量更可靠。 PHP虽然也有很多开源包 但很多就是那个开发人员今天很高兴，就开源了，质量不怎么靠谱的。

另一个就是企业参与开源的时候其实是面临着管理维护成本的 这里举了一些例子： 比如你有一个fix你是贡献还是不贡献？ 如果你不想贡献 那么怎么维护？ 怎样和社区同步代码？ 怎样把自己产品的发布周期与社区同步？？ 等等等等

前面讲了很多成本，事实上最直接的，任何人都是可以卖开源软件的，只要你卖得掉。 开源软件从来没有要求说一定要免费，有兴趣等等可以看看这个链接 http://www.gnu.org/philosophy/selling.html

到这里我们有个小结论：开源软件从钱这个角度来讲，不是free的，甚至比商业软件管理起来更复杂。

下面我们来谈谈自由，Open Source 自由吗？

当然不了！因为有license这个玩意儿

世界上的license 数不胜数，看这个链接 http://en.wikipedia.org/wiki/List_of_software_licenses 我猜大伙儿平常在安装软件的时候看到license信息，基本都是accept, accept 个人来说，除了道德上的不妥，倒是很少有真正的法律后果，但是对于公司来说就不一样了。 下面介绍几个重要的license, 其真正的法律定义非常复杂，有兴趣可以深入研究，这里只把最重要的点说一下

GPL

GPL的全称是GNU General Public License 它的主要要求就是，你只要用了它的code就必须以GPL开源，你即使是动态链接上去，你也得开源，而且要以GPL license开源。 你改了它的代码，重新发布，你也得开源，当然，必须GPL。 所以我们说GPL就像病毒一样的 大家感受下，有没有感受到发明这个license的人的理想？他希望这个病毒可以传播到全世界，然后软件就都开源了，相当有理想

LGPL

可以看到GPL实在要求太高，对于商业公司来说，完全没法用啊，所以出现了一个改良版：LGPL L就是 Less的意思，Less在哪呢，就是动态链接上去的时候，就不用开源了，其它的使用方式还是和GPL一样的

Apache

Apache总的来说是商业友好的，为什么呢？ 因为Apache背后有很多大公司的身影,它必须商业友好嘛 他的主要要求是: 你如果用了,你必须还是保留这个Apache License。 你不能拷贝一份 然后把license删掉 或者改成其它license 但是对于你自己做出的改动 你是可以用其它License的 这个就比较tricky了，比如说我改了，然后用GPL把我的改动发布了 这算怎么回事儿？我也不知道 估计只有律师懂

BSD MIT

来自于大学，基本和Apache差不多 这几个事实上到是近似于真正的自由的

听完这些大家是不是已经头大了？ 所以有人也发飙了 估计是个程序员 有这样一个license： Wtfpl 全称就是Do what the 敏感词 You want to public license 这不是玩笑，是真的 你们可以去这个网站看一看 http://www.wtfpl.net/ 到这里我们可以得出开源一点也不Free 既不免费也不自由 尤其对公司来说更是如此，因为树大招风嘛

第二个问题: 为啥企业要参与开源?

我们可以从参与开源有不同角色去理解 如果企业是开源项目的一个消费者，那大概都是为了降低成本，如果一个开源软件已经很稳定了，然后我刚才谈到的那些风险你也能接受 ，那显然可以降低成本 如果你是作为贡献者，当然这里有理想主义还有企业形象这方面的考虑，但我觉得大公司参与开源主要还是想影响业界，比如一些领域有垄断，开源通常能撬开这一块铁板，所以说开源经常被企业用作战略武器 而且是站在道德制高点上。 有一些案例 我们就不详细阐述了，大家有兴趣可以深入了解 当年的Sun是把Java 以GPL license开源的，为什么？大家可以思考下 当年IBM把Eclipse开源，名字是日食，而Borland躺枪被搞死了

第三个问题：参与开源社区是怎样一番体验

在社区里，尊重和权力都是通过自己的努力和贡献换来的，贡献越大，权力越大。 以Apache为例，一开始你只能把Patch贴上去 作为contributor, 贡献的多了，社区会吸收你作为committer，自此有了写权限; 然后再上一层 成为PMC全称是Project management committee可以和其他PMC一起参与讨论项目的发展方向。 我知道在Linux社区也是金字塔结构，顶端就是Linus。

开源社区不是企业，没有所谓规章制度，但是commit code change还是非常严肃认真的，它有自己的规则和文化

关于改代码

产品的直接使用者和简介使用者可以报bug。如果这个使用者同时又是开发人员呢，Ta甚至可能连fix也准备好了，如果有fix，直接就进入review了 如果没有fix 那么首先要重现 然后fix&test locally 再让committer去review； 只有committer review过的code change才能进去 一般来说即使贡献者是committer你也要找另一位committer review下；这还不算完，任何code change都会触发一系列自动化测试，只有所有测试都过了 才会出现在build中。一般每天出的那个叫nightly build,过一段时间也会出一些milestone build.

关于Patch

Patch是交换信息的最基础的单位 有个玩笑说Apache为啥叫Apache,因为一开始老说 A patch :)

关于做决定

在开源社区，做决定一般都是通过+1 -1 这样的方式做出的 小到一个fix 要不要commit大到项目的方针政策都是通过这样的方式在邮件列表上做出决定的

第四个问题： 我们能从开源社区的开发模式学习到什么？

总的来说，就是怎样开发软件 具体的说就是回答这两个问题。如果让你从头开发一个软件，你需要什么最基本的工具？ 以及那些最基本的规则是你要遵守的 这张图是我参与Apache的时候涉及到的一些基本infrastructure

我们看到邮件列表也就是信息渠道，bug tracking也就是JIRA，有源代码管理，当时我们用的是svn，然后是自动化的build和测试,当时用的是ant 可以看到邮件列表被用户用来报告问题或者询问问题，也同时被社区内的人员用来讨论问题；当然这分成了不同的邮件列表，有些你可以自由地选择要不要监听，有的是要你有一定权限才能监听的比如committer邮件列表

那么一个issue被正式确立以后就会在Jira里面开一个issue 追踪它从生到死的过程，任何的更新都会到相应地邮件列表，比如comments, code commit, build/test result 等等 这里邮件列表有点像message bus,感兴趣的人会监听和处理相应的信息

当然，这已经是几年前了，现在事情发生了些变化。我们看到QA论坛 比如stackoverflow正在部分替代邮件列表的功能；以前的committer在github里面感觉就是merger,去merge 别人的push request, 当然啦本质上还是commit code change。 但是说实话QA还是不能完全替代邮件列表，所以我看到现在Apache 内部有人做了些工具去同步GitHub里面的comments到邮件列表里面

到这里总结一下，开发软件的一些基本组件

1. 信息传播的渠道，在这里是邮件列表
2. 源代码管理，当时是svn现在更多的是git
3. Issue/task tracker 这里是JIRA
4. 自动build/test 这里是ant

有了这些基本组件,你就可以开发软件了 成功率会高很多；当然工具一直在发展，但这几个组件解决的问题目前来看是必须要有的，也是我们这个行业的前辈们多年总结的结果

有了这些工具组件，我们相当于有了肉身了，但还缺少灵魂，灵魂是啥？ 就是一下这些规则：

1. Code Review is important——tough people are lovely.

什么意思呢？因为一个人的思维终归是有盲点的，多一双眼睛就多一个发现问题的可能性；有本书上还说，即使你拿一个洋娃娃放在那里，然后对着它解释你的code就这样也还能提高软件质量。 Tough people is lovely，翻译成中文就是事儿事儿的人其实是很可爱的。我刚工作的时候和欧美的人合作，开始还有点小不适应，因为他们说话比较直接，你代码啥啥啥问题，有啥说啥；到后来习惯了以后我后面的团队里 我倒是一直希望有这样一个tough的人，像门神一样把着源代码库的大门；如果你所在的team里面有这样一个人，请好好珍惜！

2. 单元测试

极端重要,而且单元测试要自动化，要能简单地部分跑，全部跑，出report 只有全部自动化了，才能鼓励开发人员多跑，单元测试能把一些比较低级的错误扼杀在摇篮里，很重要

3. 透明

开源社区里面因为讨论相对透明，所以大家参与讨论的积极性很高；企业里面就可能没那么透明了，manager们有自己聊的内容；员工们有自己聊的内容；当然这也是应该的，商业公司有些事儿就是要控制的；但我们还是要做到尽量地透明

那么以上这些rules其实就扮演了一个项目经理的角色。schedule,scope商量着来，quality通过review和test 保证。 我们在企业里面常常听到Process这个词，一听就觉得好重，对吧？事实上通过Open Source社区里面的经验，通过infrastructure + culture这样的方式其实更自然，更好。 infrastructure: build/test 挂了就是挂了，没啥好说的；culture,无论多牛逼的人在贡献代码的时候还是要找人review下； 这些东西形成了以后就不是负担，而是大大的助力了

附加问题: 商业软件和开源软件,你们觉得哪个质量更高？

其实这是个伪问题 当然每个人可能有不同的想法。我的答案是一个软件的质量高低和开源闭源没有直接的因果关系 我认为决定软件质量的时以下因素： 首先是Large user base,就是你这个软件有没有很多人在用，这决定了是不是边边角角的issue都能被发现 第二个是沟通渠道是不是畅通，用户能不能迅速报bug? 能不能及时得到回应？因为不畅通的话，用户可能就不报问题了，对吧? 第三个是自动化，也就是自动跑测试，自动build，自动发布等等。其实程序员都知道要做这几件事情，但如果做这几件事情的effort很大的话，势必会主观上影响积极性，客观上项目紧的时候也就会打折扣，只有把这几步都自动化了，执行起来才是最有效的 最后一个是透明，内部的开发氛围是不是够透明，有问题能够开诚布公地讨论？比如一个老大的一个patch, 菜鸟review中发现问题了能不能直言不讳？ 我认为以这四个作为基石，支撑起来的就是quality

最后推荐一篇文章，也是一本书，叫做《大教堂与集市》，里面深入探讨了开源开发模式，对软件工程产生了深远的影响，大家有兴趣可以读一下。