大约在五年前，闭源和开源软件公司之间的冲突还是比较显著的，而今天可以看到几乎所有的闭源软件公司都在采用开源的方法提供服务，像微软、甲骨文、IBM等都在拥抱开源，甚至砸出了数以十亿、百亿美元计的收购案。不过在大家争相拥抱开源之时，往往也会忽视一些潜在隐忧，万万急不得。
安全分析软件Black Duck曾对超过1000个商业代码库进行了扫描，发现其中有96%的商业应用在使用开源组件，平均每个应用会调用257个开源组件，开源代码库的使用率也显著提升。从Linux到OpenStack，再到Kubernetes，都在印证着开源这一理念对世界的贡献。
然而如前文所述，选择开源方案的时候先要了解什么是开源，并且熟知开源代码的相应风险，尤其是对于项目采购或负责人来说。首先开源是需要许可证的，是的你没有看错，代码免费不代表背后的商业模式免费，而且开源也会有一些附加信息，Open Source Initiative公布的数十种开源许可证（license）就是一种，借助其版权所有者有权是否允许他人免费使用、修改、共享版权软件。
换言之，如果版权所有者禁止共享，那么用户就只有看看代码，不能直接拿来使用，否则就是侵权。在当前80多种开源许可证中，基本都可以让用户免费使用，但使用条件则更有不同，例如permissive类的许可证可以让用户在修改代码后做闭源处理，但有些是要著名原始作者的。再如像另外一些常见的许可证，只有在分发的时候才要遵守许可，如果自己用（公司内部）就不用遵守。
其次，SAS曾对英国和爱尔兰地区的数百名高管进行问卷调查后发现，开源技术通常也伴随着隐性成本，这些企业往往会直接看到开源能够以低廉的价格创造新的功能，但他们并不清楚要开展部署软件工具需要花费多少资金，而且因此还会额外的漏洞风险。同时，企业还要在新技术应用前在员工培训、业务适配等方面做足准备。一般情况下，开源技术和专有技术的配比是40%：60%。
造成这些问题的一大原因是，企业不知道使用开源工具的隐性成本，那么如果企业在选择IT架构之初就设立一定的标准或者等级划分，就可以对预期开销进行评估，并且对潜在的风险做出预测，一旦成本入不敷出就能及时选择替代的方案。要知道，当用户选择开源框架时会被第三方服务商要求取得合法授权，而这笔费用通常并不低。如果有人试图躲过License，就会承担可能出现的法律风险。
此外，使用开源框架还要考虑到最终的应用程序是否可用，尽管开源部分可能在整个业务系统中占有较小的部分，但要是遭遇兼容性的问题，就会大幅降低产品或服务的稳定性，直接影响使用体验。对于企业的技术人员来说，他们有责任在产品架构设计之初找到开源可能产生的漏洞，但事实却是：44%的开源项目从未进行过安全审计。
显然，这对业务的可用性造成了困扰，而且即使上游社区推出了最新补丁，开发商也不一定都会及时更新，更不要说企业内部的自查的。此时，企业的IT管理者有必要建立一道审查机制，对在核心系统中运行的开源框架进行严查，及时对补丁进行更新升级。要知道，业内因为补漏不及时而发生的数据泄漏事件成堆，而其中多数是可以被预见的。
当大家对开源的态度持续升温，其背后的隐藏问题也随之暴露，对于那些积极拥抱开源框架的公司尤其是小规模企业来说，切不可心急，否则就是心急吃不了热豆腐。
本文属于原创文章，如若转载，请注明来源：拥抱开源急不得 稍有不慎就会掉入这些坑https://cloud.zol.com.cn/703/7036838.html
