代码改变世界

如何选择开源项目

2012-08-11 14:15  coodoing  阅读(590)  评论(0编辑  收藏  举报

      引用自: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属于商业“不太友好”的协议。
最后来说一下“非常友好”的协议,比较出名的有这几种:BSDMPL(Mozilla)ApacheMIT。这些协议不但允许项目的使用者使用开源库,有些还允许对开源库进行修改并重新分发。因此用起来特别爽。上述这几个协议在细节上有些小差异,大伙儿可以去它们官网瞧一下。
另外,有些开源软件使用公共域授权(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,教你如何选择开源库。中文翻译可参考这里