现状和问题
软件项目开发中，为了不重复发明轮子，不可避免的会用到不少第三方类库、框架等开源技术实现，而面对同一种需求场景，往往有多种开源技术实现可供选择，即便同一种实现，也有很多种版本。这些实现间存在功能上的重合点，同时也存在其独有的特性，面对多种选择，如何才能选到最适合的是需要仔细考虑的。
在一些企业中，开源技术选型方面尚没有统一的标准和指导原则，众多项目组独立选型，系统开发所用的开源技术五花八门，版本也千差万别。选型质量的好坏不但直接影响着软件的质量，同时，也会给应用的维护带来了不小的麻烦。
开源技术选型和管理意义重大，本文在开源技术的选型上提供一些参考，并就如何使用提出建议。
开源技术选型原则
开源技术选型需要遵循以下4个原则：
技术特性优秀
选型都是在功能特性有极大重合度的开源技术实现间来做，若只有少部分功能特性重合，则说明开源技术实现的定位不同，不具备可比性，优先选择与我们定位需求一致的开源实现。
面对功能特性大面积重合的两个开源实现，则再比较其实现方式。实现方式包含编程语言、技术架构等。不同实现方式带来的差别是非功能特性不同，这些非功能特性包括可用性、可靠性、伸缩性、可维护性、可扩展性等多个方面，其中前4个是重点，可扩展性在某些可预见未来不需要扩展的场景下可不考虑。
优先采用技术成熟的产品，技术成熟表现在有发布GA版本，版本号不小于1.0，发布时间不短于1年，有比较多的使用案例，尤其是在大企业中被使用过。若没有成熟技术实现或者面对多种成熟技术实现时，则比较其软件发布的RoadMap（路线图/蓝图），优先选择未来有企业级特性的更新计划，版本更新较快速的产品，那些超过半年不更新的、未来没有明确的升级更新计划的不予考虑。
运作模式稳定
运作模式包括License模式、开发模式、测试模式、决策模式四个方面。
有些开源技术实现其实是部分开源，其软件分为社区版、企业版，一些高级特性只在企业版中才有，而企业版并不是开源的，是需要License的，若非必要，这种开源实现不予考虑。例如：大家都以为Java是免费的，其中Java SE 包括免费的是JDK 和 JRE，但是 Advanced Desktop、Java SE Advanced 和 Java SE Suite 具备额外的功能，比如 Java Mission Control 和 Flight Recorder （也叫 JRockit Mission Control 和 JRockit Flight Recorder），这几个版本都是付费的。对用任何一个开源软件，都要考虑如果收费了怎么办,要有替换方案。
不同开源技术实现的开发模式不尽相同，有些开源技术实现有专门的团队负责更新维护，有的则是纯依赖社区力量，相比较而言，社区力量具备不确定性。
与开发模式相应的，测试模式也不同，大企业贡献出的开源软件往往是内部正在使用的，每一个版本的更新都是经过内部测试的，有独立的测试团队。而社区力量为主的开源软件测试往往不够严谨，测试的成本转移到使用者身上，所以大企业负责维护的开源技术更具优势。
项目运作是被一家公司掌控还是松散的社区决策，以前都说大教堂不如集市，那是因为以前大教堂基本上不搞开源，搞开源的大教堂和集市，就难说哪个好了。
提供者背景强大
考量开源软件实现的提供者背景，需要从三个方面考虑。第一，是否在某行业有长期耕耘的经验，这个行业与我们所属行业有什么区别吗，比如用户体量。第二，开源项目的需求来源是什么，当初主要是为了解决什么问题才上马的，这类问题是我们要解决的主要问题吗。第三，该开源软件是否在提供者内部使用，若正在内部使用，则软件的质量、后续的软件更新维护就有很大保证，否则难以保证。例如，Google发布的开源产品大部分都是自己内部使用并测试过的，质量都非常好。
生态环境良好
生态环境是考量软件未来发展前景的十分重要的因素，有些开源软件得到了社区的极大关注，并且得到了很多IT巨头的大力支持，未来发展前景一片光明，典型的例子如OpenStack。现在已表示支持OpenStack项目的大型硬件厂商包括：IBM、AMD、Intel和戴尔等。微软在2010年10月表示支持OpenStack与Windows Server 2008 R2的整合。2011年2月，思科系统正式加入OpenStack项目，重点研制OpenStack的网络服务。OpenStack成为Ubuntu未来在堆栈方面的云网络化方案。2012年4月，IBM宣布加入OpenStack项目，并作为主要赞助商。2012年10月，Viacloud互联云平台加入OpenStack项目，研制OpenStack公有云平台和私有云平台。IBM在2013年举行的 IBM Pulse大会宣布将基于OpenStack提供私有云服务以及相关应用。像OpenStack这种具有良好生态的开源实现是我们的优先选择。
生态环境还包括社区的活跃度，使用者就越多，活跃度就越高，整个生态环境会非常的完整。
一项技术是否拥有广泛的“朋友圈”也是我们需要重点考虑的，而这点往往又容易被忽视。短时间内不会有大的问题，关键是能否长期的可持续发展，和生态环境就有着密切的关系。
原则的原则
以上四个原则没有优先级关系，每个原则的权重都是一致的，各占25%。一个开源技术或产品要从不同的维度和视角去考量，并持续的进行总结和经验的积累。
开源技术使用策略
建立统一的技术基线
建立统一的技术基线的意义在于，在同一个基线内的三方库之间是有稳定兼容保证的。比如commons-logging、slf4j和log4j这几个常用的日志记录开源库，常常组合在一起使用，若没有统一的技术基线，升级其中一个版本可能带来Jar包冲突，相反，采用统一的技术基线，同一个基线下的这三个Jar肯定是稳定兼容的。当基线内有类库存在重大升级或者满足一定数量的更新时，经过仔细的兼容性和稳定性测试后，将基线版本提升后统一发布。就像Spring Cloud一样，可以把Spring Cloud的大版本当做技术基线，在这个基线内Spring Cloud的各个组件如Eureka、Zuul、Rebon、Sleuth等都具有自己的版本，版本号并不一致，但是全部相互稳定兼容，当这些组件有较大的升级后，Spring Cloud相应提升一下大版本即可。
技术基线内不应仅包含开源类库、框架等，还要包含内部自己开发的组件，这些组件具备复用价值，有扩展或改进的可能就有版本管理的需求，作为二方库，与三方库同样纳入基线。
技术基线的管理在行内应有专门的团队统筹管理，这个团队负责技术基线的日常维护，包括基线内容扩充、版本升级、稳定性测试、兼容性测试、变更影响评估等工作。
功能验证及测试
为了避免一些开源软件本身存在安全漏洞，首先应使用安全扫描工具进行排查。针对该软件的核心功能进行功能验证和测试，是否和宣称的功能一致。例如：Mycat官方说支持prepare预编译指令，但实际情况是传递给Mycat的数据准备发往客户端时，仅做一个协议包转换，将普通文本结果集协议包转换成二进制结果集协议包并发往客户端。就是这样，让客户端看起来Mycat是真正地实现了预处理。其实Mycat宣称的预处理并不是真正的预处理，最后发往后端（数据库）时还是利用了普通协议，而不是真正的预处理协议。这一点可以从分析数据库的预编译性能指标（parse time elapsed和hard parse elapsed time）上看出来。
最后，建议有必要查看开源软件的源码，优秀开源软件的代码是非常规范的，例如：spring的源码，从代码规范、设计模式、软件架构等多方面都是非常优秀的，完全可以当做模板进行参考。而有些开源软件的代码良莠不齐，开发者既有在校的大学生，也有经验丰富的程序员。当然分析源码虽然不是衡量的标准，但需要关注，因为代码是不会骗人的。
技术框架考核
技术框架需从用户和系统两方面进行考量。第一，站在用户的角度，第二，从系统的属性看。如上图，正代表不矛盾的，可以放在一起。负代表有冲突的，例如，平台是高效的，那一定和操作性是冲突的。
基于开源项目做二次开发
二次开发过程需要先确定开源软件跟随策略，再设计编码，测试发布。开源软件跟随策略一般分为两种。一种是“私有分支”策略，一种是“社区先行”（Upstream First）策略。
私有分支策略即在公司内建立基于开源社区某个版本的私有的产品版本分支，并在其上增加定制功能，经测试后发布给用户使用。后续私有分支的版本随开源社区版本发展而发展。私有分支版本前进一个版本时，选择社区的一个新版本（不一定跟随每个社区版本），然后合入以前开发的定制功能。这种策略为国内外很多厂家采用。其主要优点是可以比较迅速的反应用户的需求，及时的提供可用的解决方案和软件给用户使用。同时，作为差异化竞争力的私有定制功能可以不开源，增强产品功能方面的竞争力。缺点是由于存在私有定制功能，导致跟随社区版本发展时每次都需要进行功能整合并进行大量测试。这会消耗很多的工作量。而且存在未来社区中也出现了类似功能，导致私有功能与社区实现不兼容的问题。
社区先行策略指商用产品中所需的所有功能均首先在开源社区中进行开发，并贡献到开源社区。商用版本直接继承开源社区版本的功能，并根据产品需要进行模块和功能裁剪。同时进行商用标准的测试工作。在测试中发现的故障，经修改后也及时贡献到社区。这种策略的主要应用厂商是红帽(Red Hat)。此策略的优点是，可以快速的跟随开源社区版本。防止每次版本跟随时需要额外合入大量自行开发的私有功能，消耗大量工作量。缺点是因为社区版本节奏相对比较慢，从而导致商用版本在响应用户需求方面有时会滞后。另一方面讲，这也保证了企业用户可以使用到更成熟稳定的开源技术产品。