我们可以从产品、治理、文化和社区四个视角来看开源。产品层面上，越来越多的公司参与到开源里，那么有些公司是以开源作为一个技术的创新，或者打造自己的一个生态，或者作为企业的战略来推动；有些公司可能是作为一个使用者参与到开源治理中。治理层面上，我们要考虑到开源软件的安全、合规、运维和专利风险。社区层面上，有主体的运营，还有参与，打造一个共同体。现在在国内，我们能看到很多开源的同仁一直在鼓励或参与社区的交互，这一点非常重要，无论是对于开源的使用者还是输入方，都会形成一个比较好的良性互动。文化层面上，从企业的角度、个人的角度，我们都希望通过开源的一个方式，可以打造一个开放、协作和共享的这样一个文化氛围。

开源已经占据了整个软件领域非常重要的一个位置，那么在这样的一个前提下，从治理层面来看，我们需要从外部的驱动，转变为内部驱动，最终变成业务的驱动。在外部驱动方面，比如与供应商合作的时候，需要提供一个供应清单，说明你提供给我的这个软件里有哪些开源的组件、有哪些许可证；有些公司要上市或收购的话，针对软件这一块儿有一个尽职调查，尤其是针对软件资产，针对开源有一个追溯；还有最近个人的一个GDPR，那么从外部来看，有很多因素会推动我们去做。

此外，我们更希望看到企业从内部去驱动它，包括现在整个团建是DevOps的一个概念，即追求软件更快的部署，包括现在像云原生、Serverless这样的一个模式，在这个前提下，如何让我们在使用开源软件的过程中安全可信？我们看到很多国内外的公司从内部非常重视开源的安全可信的治理，越来越多的公司也成立了开源治理委员会，去推动协调整个的资源。

最后我们也看到有一些公司，把开源作为企业的一个战略，形成商业的一个模式，推动创新，推动整个业务。

在使用开源的时候，也有很多的挑战。首先，我们看到很多的公司，对使用的开源组件缺乏透明度，不了解公司里使用开源的情况。第二，缺乏企业级的开源政策或治理框架。第三，各个部门大多自行评估和管理其开源需求，但很少真正形成系统化，需要更多的重视。第四，我们在使用开源的时候，对于风险的认知是有限的。现在越来越多的公司走向海外，那很多原先可能没有意识到的问题摆在了我们面前，比如合规的风险、知识产权的问题等等，愈发突显。还有就是和开源社区缺乏互动，这导致运维非常困难。最后，希望管理层能足够重视开源，推动开源治理往前走的步伐。

开发人员如何为他们的项目寻找开源软件？

企业如何评估和批准拟纳入软件库的开源软件组件？

• 实施开源审批流程，以洞悉法律、架构和安全风险

比如从律师的层面来讲，他们可以从解析许可证的这个维度来看；从架构师的层面来看，他们可以判断开源组件的性能、设计的架构是否可以扩展、有没有可以替换的，这些都需要思考。在使用开源软件时，可以考量社区对于安全风险的披露情况和安全漏洞的修复情况。

企业如何监视和控制通过软件供应链引入的开源软件组件？

• 审查供应商的安全治理计划

• 供应商提供清单，说明使用的开源组件及许可证

• 与公司设定的规范比对，如有冲突，进行必要的沟通与协调
  

• 将软件供应商的开源使用事宜写进合同，对双方都是一种保护

企业如何跟踪和管理包含在软件库中的开源软件组件？

• 设置开源组件的持续扫描和监控流程，以识别出安全、许可和运营风险。

• 针对开源制定编码文档记录标准

企业如何维护包含在软件库中的开源软件组件？工程师如何就这些组件获得技术支持？

企业如何确保包含在软件库中的开源软件组件符合开源许可证的规定？

如果企业的软件库中包含了某个开源社区制作的开源组件，或者某个开源社区制作的开源组件与企业的目标市场密切相关，那么，企业应如何与该等社区展开互动呢？

业务部门经理、工程经理和公司法律顾问应如何对开源软件进行适当的管理监督呢？

针对轻量级的解决方案，首先，通过工具扫描得出一个基础数据，如果发现某个开源组件有高风险，请开发同事来做确认。再者，要做规则检查。另外，从合规的层面来讲，需要法务部门的参与，因为法务与专利、知识产权的关系很密切。在产品上线后，还需要对许可证违规和安全漏洞做持续的监控。对于许可证来说，根据产品型态的不同也需要有所改变，比如当一个产品从内部开源变为外部分销时，许可证的等级会提高 ，这时我们需要关注许可证合规的风险。

针对中长期的解决方案，需要有更多的人加入进来，每个人的角色不同。比如，安全工程师要制定安全合规的规范；质量工程师除了做功能性回归测试之外，还需要针对开源形成质量管理的一些指标。第二个，从流程上来说，如果打通了研发过程的构建，那么发现问题之后，会触发不同的流程，进行治理。举个例子，比如安全漏洞被发现后，安全工程师加入进来，将漏洞进行分类，形成漏洞修复的一个建议和报告，反馈给开发，开发在修复之后再给出一个建议并提交，形成这样一个闭环的管理。