如何选择开源项目？
如何选择开源项目？
近几年开源项目越发普及，很多商业软件都逐渐引入开源项目。由于俺负责的产品线采用了不少开源项目（主要是 C++、Java、Python），这几年就经常会碰到开源项目选型的问题（从几个具有类似功能的开源软件项目中进行抉择）。今天我就大概聊一下自己的几点看法，供大伙儿参考。
License 是很多人容易忽略的一个问题，所以我们先来聊一下 License 的问题。因为公司里面开发的软件大都属于商业软件（更严谨的叫法是“专属闭源软件”），根据开源协议和商业的冲突程度，可以分为三种：非常友好、不太友好、很敌对。下面分别介绍一下：
先说说“很敌对”的协议：GPL（详细解释请看“ 这里 ”）。GPL 和闭源软件是有严重冲突的。通俗地说，如果某个软件使用了基于 GPL 协议的【动态库或静态库】，则【整个软件】必须也用 GPL 协议发布（这就是大名鼎鼎的【GPL 传染性】）。也就是说——如果你开发的是【闭源】软件，一旦发现自己想用的某个开源库属于 GPL 协议，即使功能再强再好用，也只好忍痛割爱了。
在此郑重提醒大伙儿，【切莫】抱侥幸心理，偷偷使用。一旦被雪亮的群众眼睛所发现，不光害了自己的名节，公司的名节也不保。
因为 GPL 对于商业闭源软件太不友好了，估计当年很多开源库的作者怨声载道。GNU 组织为了缓和一下矛盾，搞出了一个折衷的 LGPL 协议（详细解释看“ 这里 ”）。这个协议相对 GPL 来说，宽松了一些：商业闭源软件在【不公开】代码的前提下，可以在产品中使用 LGPL 的开源库。所以 LGPL 属于商业“不太友好”的协议。
最后来说一下“非常友好”的协议，比较出名的有这几种： BSD 、 MPL（Mozilla） 、 Apache 、 MIT 。这些协议不但允许项目的使用者使用开源库，有些还允许对开源库进行修改并重新分发。因此用起来特别爽。上述这几个协议在细节上有些小差异，大伙儿可以去它们官网瞧一下。
另外，有些开源软件使用公共域授权（Public Domain，详细解释看“ 这里 ”）。简单说，就是不作任何限制，软件的使用者可以为所欲为 :)
上面提到的几种协议都是知名协议。还有少数开源项目不是采用知名协议，而是自己搞了一套协议。如果你碰到这种情况，就得硬着头皮认真读一遍协议上的洋文，看看它对于使用者有些什么限制了。
由于技术层面的考量和你所开发的软件密切相关，因此这方面的评判依据千差万别。我只能挑几个比较通用的说一下。
假如你开发的是跨平台的项目，那么你选择开源项目就得考虑它支持哪些平台（硬件平台、操作系统平台、数据库平台）。如果你需要支持的平台它不能支持，那就赶紧另找一个。
有时候编译器的支持也是考虑的指标之一。比如俺在“ C++ 的可移植性和跨平台开发 ”里面提到的老式编译器问题。再比如俺曾经实施一个 Java 项目，用户的环境是 JDK 1.4。那么有些用了 Java 1.5 新语法的开源库就不能使用。
假如你开发的软件是性能敏感的，那选型的时候就要测试一下几个候选项目的性能指标。
现在安全问题越来越严重。如果你比较在意安全性的话，还得顺便调查一下候选项目是否有安全问题（比如缓冲区溢出的 bug、比如跨站脚本注入等）。
所谓的普及程度，就是看开源项目的用户占有率。当然大伙儿不是搞市场调查的，花钱请市场调查公司也不现实。简单的办法就是用搜索引擎大致搜一下，就能看出几个候选项目使用的广泛度了。
还有另外一个判断普及程度的方式，就是看某个开源项目是否被知名的软件或者公司采用。比如 Firefox（算是知名软件）采用 Sqlite 来存储页面缓存和 cookie，这至少可以从侧面反映出 Sqlite 项目的优秀程度。
对于若干个候选项目，显然要优先考虑普及度高的那个。因为某个项目普及度高，至少说明（但不绝对）它比较成熟、稳定、安全。而且用的人多了之后，相应的文档也会多一些，碰到问题也容易找到人咨询。
这里说的“活跃”，是指开发层面而言。
一般来说，一个项目越活越，则新功能的推出越快，对提交 bug 的响应也越快。还有些项目，由于开发人员不再继续开发（可能开发人员厌倦了、可能开发人员太忙了），从而导致活跃度很低。
不过也有例外——有些项目由于已经非常完善了，因此反而活跃程度很低。俺印象中：最近几年 bzip2 就很少有更新，但它是非常优秀的压缩库。
最后来说说一些其它的风险。一般来说，只有当前几个因素都差不多的时候，才会来考虑其它风险。
（如果你【不】清楚“单点故障”是啥意思，先看“ 这篇博文 ”）
很多项目过于依赖【个人英雄主义——光靠着一两个大牛完成整个项目。一旦大牛出现意外，必然导致整个项目受到严重影响。典型的例子就是 ReiserFS 文件系统的创始人 Hans Reiser。这位老兄由于谋杀妻子的罪名成立，被判入狱15年（对 IT 八卦有兴趣的同学可以看“ 这里 ”）。导致 ReiserFS 项目受到严重影响。
顺便说一下：
这类风险在开源界有个专门的术语叫“ Bus Factor ”，翻译成“巴士因子”或“卡车系数”。指的是——项目中有多少个关键人物【同时】出车祸，才会导致项目瘫痪。
还有些开源项目被商业公司收购后，由于种种原因（商业、管理、政治等）导致该开源项目受到不利影响。比如上星期听说 Michael Widenius（MySQL 共同创始人）和 Marten Mickos（MySQL 前任 CEO）从 Sun 离职。再加上去年10月走掉了的 David Axmark（MySQL 共同创始人）。估计对 MySQL 的影响不小。
上述提到的几个考量指标，排在越前面的，权重越高。你在选型时需要综合考虑这几个因素。
俺博客上，和本文相关的帖子（需翻墙） ：
《 澄清“自由软件、开源软件”相关概念及许可证的误解 》
《 聊聊【单点故障】——关于“德国空难”和“李光耀”的随想 》
★License（授权协议、许可证）
License 是很多人容易忽略的一个问题，所以我们先来聊一下 License 的问题。因为公司里面开发的软件大都属于商业软件（更严谨的叫法是“专属闭源软件”），根据开源协议和商业的冲突程度，可以分为三种：非常友好、不太友好、很敌对。下面分别介绍一下：
◇对商业闭源软件“很敌对”的协议
先说说“很敌对”的协议：GPL（详细解释请看“ 这里 ”）。GPL 和闭源软件是有严重冲突的。通俗地说，如果某个软件使用了基于 GPL 协议的【动态库或静态库】，则【整个软件】必须也用 GPL 协议发布（这就是大名鼎鼎的【GPL 传染性】）。也就是说——如果你开发的是【闭源】软件，一旦发现自己想用的某个开源库属于 GPL 协议，即使功能再强再好用，也只好忍痛割爱了。
在此郑重提醒大伙儿，【切莫】抱侥幸心理，偷偷使用。一旦被雪亮的群众眼睛所发现，不光害了自己的名节，公司的名节也不保。
◇对商业闭源软件“不太友好”的协议
因为 GPL 对于商业闭源软件太不友好了，估计当年很多开源库的作者怨声载道。GNU 组织为了缓和一下矛盾，搞出了一个折衷的 LGPL 协议（详细解释看“ 这里 ”）。这个协议相对 GPL 来说，宽松了一些：商业闭源软件在【不公开】代码的前提下，可以在产品中使用 LGPL 的开源库。所以 LGPL 属于商业“不太友好”的协议。
◇对商业闭源软件“很友好”的协议
最后来说一下“非常友好”的协议，比较出名的有这几种： BSD 、 MPL（Mozilla） 、 Apache 、 MIT 。这些协议不但允许项目的使用者使用开源库，有些还允许对开源库进行修改并重新分发。因此用起来特别爽。上述这几个协议在细节上有些小差异，大伙儿可以去它们官网瞧一下。
另外，有些开源软件使用公共域授权（Public Domain，详细解释看“ 这里 ”）。简单说，就是不作任何限制，软件的使用者可以为所欲为 :)
◇其它协议
上面提到的几种协议都是知名协议。还有少数开源项目不是采用知名协议，而是自己搞了一套协议。如果你碰到这种情况，就得硬着头皮认真读一遍协议上的洋文，看看它对于使用者有些什么限制了。
★技术层面的因素
由于技术层面的考量和你所开发的软件密切相关，因此这方面的评判依据千差万别。我只能挑几个比较通用的说一下。
假如你开发的是跨平台的项目，那么你选择开源项目就得考虑它支持哪些平台（硬件平台、操作系统平台、数据库平台）。如果你需要支持的平台它不能支持，那就赶紧另找一个。
有时候编译器的支持也是考虑的指标之一。比如俺在“ C++ 的可移植性和跨平台开发 ”里面提到的老式编译器问题。再比如俺曾经实施一个 Java 项目，用户的环境是 JDK 1.4。那么有些用了 Java 1.5 新语法的开源库就不能使用。
假如你开发的软件是性能敏感的，那选型的时候就要测试一下几个候选项目的性能指标。
现在安全问题越来越严重。如果你比较在意安全性的话，还得顺便调查一下候选项目是否有安全问题（比如缓冲区溢出的 bug、比如跨站脚本注入等）。
★普及程度（用户的人气）
所谓的普及程度，就是看开源项目的用户占有率。当然大伙儿不是搞市场调查的，花钱请市场调查公司也不现实。简单的办法就是用搜索引擎大致搜一下，就能看出几个候选项目使用的广泛度了。
还有另外一个判断普及程度的方式，就是看某个开源项目是否被知名的软件或者公司采用。比如 Firefox（算是知名软件）采用 Sqlite 来存储页面缓存和 cookie，这至少可以从侧面反映出 Sqlite 项目的优秀程度。
对于若干个候选项目，显然要优先考虑普及度高的那个。因为某个项目普及度高，至少说明（但不绝对）它比较成熟、稳定、安全。而且用的人多了之后，相应的文档也会多一些，碰到问题也容易找到人咨询。
★活跃程度（开发的人气）
这里说的“活跃”，是指开发层面而言。
一般来说，一个项目越活越，则新功能的推出越快，对提交 bug 的响应也越快。还有些项目，由于开发人员不再继续开发（可能开发人员厌倦了、可能开发人员太忙了），从而导致活跃度很低。
不过也有例外——有些项目由于已经非常完善了，因此反而活跃程度很低。俺印象中：最近几年 bzip2 就很少有更新，但它是非常优秀的压缩库。
★其它的风险
最后来说说一些其它的风险。一般来说，只有当前几个因素都差不多的时候，才会来考虑其它风险。
◇“单点故障”的风险
（如果你【不】清楚“单点故障”是啥意思，先看“ 这篇博文 ”）
很多项目过于依赖【个人英雄主义——光靠着一两个大牛完成整个项目。一旦大牛出现意外，必然导致整个项目受到严重影响。典型的例子就是 ReiserFS 文件系统的创始人 Hans Reiser。这位老兄由于谋杀妻子的罪名成立，被判入狱15年（对 IT 八卦有兴趣的同学可以看“ 这里 ”）。导致 ReiserFS 项目受到严重影响。
顺便说一下：
这类风险在开源界有个专门的术语叫“ Bus Factor ”，翻译成“巴士因子”或“卡车系数”。指的是——项目中有多少个关键人物【同时】出车祸，才会导致项目瘫痪。
◇商业风险
还有些开源项目被商业公司收购后，由于种种原因（商业、管理、政治等）导致该开源项目受到不利影响。比如上星期听说 Michael Widenius（MySQL 共同创始人）和 Marten Mickos（MySQL 前任 CEO）从 Sun 离职。再加上去年10月走掉了的 David Axmark（MySQL 共同创始人）。估计对 MySQL 的影响不小。
上述提到的几个考量指标，排在越前面的，权重越高。你在选型时需要综合考虑这几个因素。
俺博客上，和本文相关的帖子（需翻墙） ：
《 澄清“自由软件、开源软件”相关概念及许可证的误解 》
《 聊聊【单点故障】——关于“德国空难”和“李光耀”的随想 》
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/02/how-to-choose-opensource-project.html
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者 编程随想 和本文原始地址：
https://program-think.blogspot.com/2009/02/how-to-choose-opensource-project.html
文章版权归原作者所有。
