如何选择开源项目

      引用自：http://program-think.blogspot.com/2009/02/how-to-choose-opensource-project.html

      近几年开源项目越发普及，很多商业软件都逐渐引入开源项目。由于我负责的产品线采用了不少开源项目（主要是C++、Java、Python），这几年就经常会碰到开源项目选型的问题（从几个具有类似功能的开源软件项目中进行抉择）。今天我就大概聊一下自己的几点看法，供大伙儿参考。

★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来存储页面缓存，这至少可以从侧面反映出Sqlite项目的优秀程度。
对于若干个候选项目，显然要优先考虑普及度高的那个。因为某个项目普及度高，至少说明（但不绝对）它比较成熟、稳定、安全。而且用的人多了之后，相应的文档也会多一些，碰到问题也容易找到人咨询。

★活跃程度（开发的人气）

这里说的"活跃"，是指开发层面。一般来说，一个项目越活越，则新功能的推出越快，对提交bug的响应也越快。有些项目，由于开发人员不再继续开发（可能开发人员厌倦了、可能开发人员太忙了），从而导致活跃度很低。
不过也有例外。有些项目由于已经非常完善了，因此反而活跃程度很低。我印象当中bzip2最近几年就很少有更新。

★判断代码质量

         并非所有的开源项目，都是高手写的，都值得你去学习。事实上，有很多垃圾开源项目，代码仔细一看，写得真是一塌糊涂。所以，试着阅读一下这个项目的代码。至于如何判断一个项目的代码质量，之前我在知乎回答过一个类似的问题《如何让自己写的代码易维护？ 》。推荐各位朋友参考一下。

         当然，更加推荐的，是阅读《Clean Code》一书，非常好的一本介绍如何提交代码质量的书。附一篇书评，可以一读：《写代码犹如写文章 》

★选择合适的版本

         最后，面对已经发展了多年的开源项目，最好不要选择最新的版本。如果你是在工作中要想使用这个项目，当然应该选择最新的稳定版，甚至测试版、beta版。但是如果是出于学习的目的，为了减少复杂度，快速的理解这个项目的核心结构与开发思想，选择第一个稳定版，是一个比较妥当的办法。

        然后，在初步理解了第一个版本的代码之后，再不断的通过阅读changelogs，追踪最新的版本中的代码变更，体会作者修改代码的目的、手法与技巧。这样应该会有很大的收获。

★其它的风险

最后来说说一些其它的风险。一般来说，只有当前几个因素都差不多的时候，才会来考虑其它风险。
有些项目过于依赖个人英雄主义，靠1-2个大牛完成整个项目。一旦大牛出现意外，导致整个项目受到严重影响。典型的例子就是ReiserFS文件系统的创始人Hans Reiser。这位老兄由于谋杀妻子的罪名成立，被判入狱15年（对IT八卦有兴趣的同学可以看“这里”）。导致ReiserFS项目受到严重影响。
还有些开源项目被商业公司收购后，由于种种原因（商业、管理、政治等）导致该开源项目受到不利影响。比如上星期听说Michael Widenius（MySQL共同创始人）和Marten Mickos（MySQL前CEO）从Sun离职。再加上去年10月走掉了的David Axmark（MySQL共同创始人）。估计对MySQL的影响不小。
上述提到的几个考量指标，越前面的，权重越高。你在选型时需要综合考虑这几个因素。

最后附录一篇：How to select open source libraries，教你如何选择开源库。中文翻译可参考这里。