如何选择开源项目?

文章目录

★License(授权协议、许可证)
★技术层面的因素
★普及程度(用户的人气)
★活跃程度(开发的人气)
★其它的风险

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

★License(授权协议、许可证)

  License 是很多人容易忽略的一个问题,所以我们先来聊一下 License 的问题。因为公司里面开发的软件大都属于商业软件(更严谨的叫法是“专属闭源软件”),根据开源协议和商业的冲突程度,可以分为三种:非常友好、不太友好、很敌对。下面分别介绍一下:

◇对商业闭源软件“很敌对”的协议

  先说说“很敌对”的协议:GPL(详细解释请看“这里”)。GPL 和闭源软件是有严重冲突的。通俗地说,如果某个软件使用了基于 GPL 协议的【动态库或静态库】,则【整个软件】必须也用 GPL 协议发布(这就是大名鼎鼎的【GPL 传染性】)。也就是说——如果你开发的是【闭源】软件,一旦发现自己想用的某个开源库属于 GPL 协议,即使功能再强再好用,也只好忍痛割爱了。
  在此郑重提醒大伙儿,【切莫】抱侥幸心理,偷偷使用。一旦被雪亮的群众眼睛所发现,不光害了自己的名节,公司的名节也不保。

◇对商业闭源软件“不太友好”的协议

  因为 GPL 对于商业闭源软件太不友好了,估计当年很多开源库的作者怨声载道。GNU 组织为了缓和一下矛盾,搞出了一个折衷的 LGPL 协议(详细解释看“这里”)。这个协议相对 GPL 来说,宽松了一些:商业闭源软件在【不公开】代码的前提下,可以在产品中使用 LGPL 的开源库。所以 LGPL 属于商业“不太友好”的协议。

◇对商业闭源软件“很友好”的协议

  最后来说一下“非常友好”的协议,比较出名的有这几种:BSDMPL(Mozilla)ApacheMIT。这些协议不但允许项目的使用者使用开源库,有些还允许对开源库进行修改并重新分发。因此用起来特别爽。上述这几个协议在细节上有些小差异,大伙儿可以去它们官网瞧一下。
  另外,有些开源软件使用公共域授权(Public Domain,详细解释看“这里”)。简单说,就是不作任何限制,软件的使用者可以为所欲为 :)

◇其它协议

  上面提到的几种协议都是知名协议。还有少数开源项目不是采用知名协议,而是自己搞了一套协议。如果你碰到这种情况,就得硬着头皮认真读一遍协议上的洋文,看看它对于使用者有些什么限制了。

★技术层面的因素

  由于技术层面的考量和你所开发的软件密切相关,因此这方面的评判依据千差万别。我只能挑几个比较通用的说一下。
  假如你开发的是跨平台的项目,那么你选择开源项目就得考虑它支持哪些平台(硬件平台、操作系统平台、数据库平台)。如果你需要支持的平台它不能支持,那就赶紧另找一个。
  有时候编译器的支持也是考虑的指标之一。比如俺曾经实施一个 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 的影响不小。

  上述提到的几个考量指标,排在越前面的,权重越高。你在选型时需要综合考虑这几个因素。