一直在使用开源软件，可是真正了解开源代码的使用吗

开源技术使用者可以分为三类第一类是使用开源技术的用户，是开源软件的终端用户;第二类是进行二次开发并使用的开源技术的用户，是使用开源软件代码用于自身业务开发的开源使用者;第三类是进行二次开发并进行售卖的软件厂商，是将开源软件集成在自身产品或解决方案中，向终端用户进行分发销售的软件厂商或集成服务商。
根据开源用户的三种类型，开源技术的使用方式同样可分为三种。第一种是直接使用原生开源技术，第二种是对开源技术进行二次开发再进行使用，第三种是购买基于开源技术的商业软件。
1开源使用技术的风险
不管的英文直接使用开源技术，还是购买开源技术的商业软件都需要考虑开源技术带来的风险，不同的是规避开源技术风险的责任主体不同。
企业在使用或引入开源软件或代码时，需要考虑开源风险，违约风险 知识产权风险，开源许可证兼容性风险，以及数据安全及隐私风险，具体可参见第七章开源面临的问题和挑战
2选择如何开源技术
由于开源软件可以帮助一个公司或者研发机构快速的开发出适合市场需要和科研需求的平台和产品，因此在面临产品研发和项目方案制定时，选用开源软件就是一个非常快速有效的手段。而是否以及如何引入开源软件，就要从以下几个方面来加以考虑：
a）需求满足度：对于终端用户来说，在选择开源技术的时候需要，考虑是否满足自身业务场景需求，对于软件厂商在选择开源技术的时候需要考虑是否满足用户求，如果不完全满足用户，可能要进行二次开发。一般来说，选用的开源软件应满足绝大多数业务需求才能选用。因为一般来说开源软件的方案和代码大多数都不是选用者自己贡献的，因此在后续软件开发和维护中存在因不熟悉开源软件现有方案和代码带来的额外问题及其相关工作量。如果开源软件对产品需求的满足度不够高，则上述问题给选用者带来的额外工作量可能会超过彻底重新自行研发的工作量，这样就得不偿失了。
b）中技术先进性：即这个开源软件的技术在同类闭源或开软件中所处的水平是否先进这点的主要考虑因素是为开源软件众多，而开发者也有自己的技术偏好但这种
，应注意在产品中的使用方式。需要防止GPL系列许可证软件带来的开源传染性问题
.d）软件成熟度。应尽量选择相对比较成熟的主流开源软件，降低后续技术跟随方向偏离业界主流的风险。一般建议选用业界Top3的开源软件
.e）运维能力。在选择开源软件前需要查看是否具有比较完善的开源方案日志，是否具有命令行管理控制台等维护工能够查看系统运行情况，是否有故障检测和恢复能力。
F）商业支持。开源的代码每年都急剧上升和翻倍增长，对于使用免费软件的企业户带来了巨大挑战，涉及技术路线选择，稳定性安全和可持续开发等，需要考虑市场上是否有可以 提供企业就绪型产品与配套服务的开源厂商。
g）社区活跃度：即开源社区是否仍然活跃。从技术上说这个开源软件未来是否可以持续更新，如果已经很多年没有改则有相当可能这个社区已经无人维护，不根据未来的技术发展添加更多功能，保持技术活力
.h）软件生态：应优选生态系统比较完备的开源软件。优选有实力比较雄厚的基金会支持，有业界主流厂商积极参与贡献和选用的开源软件
.6.3如何使用开源技术
由于开源技术在使用过程中存在的风险问题，所以应分步骤，有节奏的使用开源技术。通常先熟悉开源软件进行测试，规划应急预案，为满足业务场景需求进行二次开发。
通读测试。开源项目的设计文档，了解设计原理;核对每个配置项的作用和影响，识别关键配置项;进行多种场景的性能测试;进行压力测试，连续运行程序，分析CPU，内存，磁盘IO等指标;故障测试，模拟断电，拔 线，重启100次以上等故障。
灰度发布。先在非核心业务上使用。
应急预案。对于重要的业务，使用开源技术时，最好有另外一个成熟的方案做备份。
二次开发。二次开发过程需要先确定开源软件跟随策略，再设计编码，测试发布。
确定开源软件跟随策略。开源软件跟随策略一般分为两种。一种是“私有分支”策略，一种是“社区先行” （上游第一）策略。
私有分支策略即在公司内建立基于开源社区某个版本的私有的产品版本分支，并在其上增加定制功能，经测试后发布给用户使用。后续私有分支的版本随开源社区版本发展而发展。私有分支版本前进一个版本时，选择社区的一个新版本（不一定跟随每个社区版本），然后合入以前开发的定制功能。这种策略为国内外很多厂家采用。其主要优点是可以比较迅速的反应用户的需求，及时的提供可用的解决方案和软件给用户使用。同时，作为差异化竞争力的私有定制功能可以不开源，增强产品功能方面的竞争力。缺点是由于存在私有定制功能，导致跟随社区版本发展时每次都需要进行功能整合并进行大量测试。这会消耗很多的工作量。而且存在未来社区中也出现了类似功能，导致私有功能与社区实现不兼容的问题。
社区先行策略指商用产品中所需的所有 能均首先在开源社区中进行开发，并贡献到开源社区。商用版本直接继承开源社区版本的功能，并根据产品需要进行模块和功能裁剪，同时进行商用标准的测试工作。在测试中发现的故障，经修改后也及时贡献到社区。这种策略的主要应用厂商是红帽（Red Hat）。此策略的优点是，可以快速的跟随开源社区版本。防止每次版本跟随时需要额外合入大量自行开发的私有功能，消耗大量工作量。缺点是因为社区版本节奏相对比较慢，从而导致商用版本在响应用户需求方面有时会滞后。另一方面讲，这也保证了企业用户可以使用到更成熟稳定的开源技术产品。
 方案设计。基于开源软件的二次开发的方案设计，除按照普通功能开发流程以外，还应特别关注以下方面：
a。需要看社区中是否已经在进行类似功能的开发，如果已经正在进行开发，则可以等社区开发完成
。需要考虑与社区现有接口的兼容性，防止未来存在不兼容的风险
。使用开源软件中的接口时要注意接口版本问题。防止出现依赖即将被废弃接口的问题。
d。需要考虑开源许可证的要求。对于限制比较严格的许可证，需要考虑新开发功能的存在形式。是直接修改开源代码，或者采用库的形式，还是采用独立服务的形式等。
 编码。基于开源软件的二次开发的编码，除按照普通编码的要求以外，还应特别关注以下方面：
a。编码需要注意遵循开源许可证的要求，特别需要注意不要清除原版权信息，并添加开发者的版权信息
。需要遵循开源社区的编码规范和要求，便于后续在需要时将代码贡献到开源社区。
测试。基于开源软件的二次发测测，除按照普通的要求以外，还应注意尽量引入开源社区原CI等测试系统和工具链。
发布。可采用灰度发布的方式。
运维。采用DevOps运维方式。需要有完善的版本升级案。支持跨社区大版本的，（（尽量）不中断业务平滑升级方式。

 

内容素材来自于：中国信息通信研究院 ---《开源治理白皮书》

转载于:https://my.oschina.net/u/3854774/blog/1858231