2019云计算开源产业大会丨武倩聿：企业级开源治理标准解读_云资讯

大家下午好，今天我为大家带来“企业级开源治理标准解读”。

武倩聿

这项工作是中国信通院去年底开始做的，大概持续到2019年上半年做了首批试评估，这一年时间内，我们在持续探索企业级开源治理的路径，欢迎业界跟我们做共同的探讨和研究，帮助我们持续进步。

背景。

国内开源项目也是近几年来开始较多的，之前一般是聚焦国外的项目。（表）华为、腾讯、阿里，包括今天上午主会场也给很多企业开源项目进行了颁奖，国内开源氛围已经慢慢形成了，看到很多优秀的国内开源项目正在涌现，包括很多开源项目数也不少，有很多人在使用，并且在持续地贡献，而且国内一些项目贡献到国际顶级基金会，可以看到国内这方面开源精神，包括国内科技企业开源热潮有一个较好的上升趋势。

用户侧开源使用

开源的使用以前考虑问题是到底要不要用开源，现在考虑的问题已经变成了用开源有没有什么问题，关注一些风险点，大家已经接受了我们必须要用开源的这个事实。

开源软件对于企业来讲，以前是可以选买商业的BI软件，封闭式的一些巨头等等，但现在云计算、大数据、人工智能这些领域里面比较新的技术，包括比较热的技术，都是开源的，因为只有通过开源这种模式才能够快速去占领市场。

今天是云计算开源产业大会，云计算里OpenStack等这种顶级的项目，包括他们在市场上的占有率基本是No.1，开源已经成为一种趋势，用户不可避免要用开源。由此看到我们用开源并不代表一定就要用社区版的，直接从GitHub或官方下载下来自己用，而是可以选择买一些服务基于开源的商业产品。

基于OpenStack提供服务和产品的企业，这些年这些企业非常多，基于开源提供产品或提供服务的方面做得越来越好。跟行业用户、金融机构去聊，大家愿意买这种产品或服务，其实对于用户侧企业来讲，编程或信息系统并不是它的产品，而是为它提供前台业务的一个手段。在这种情况下，大家其实愿意通过这种方式去购买服务活产品来保证自己的核心信息系统稳定运行。

开源的风险。

自发开源企业风险，如科技公司，腾讯或阿里等公司把自己的项目贡献出去其实是有风险的。如，安全，企业内部一些数据、IP或企业内部一些信息如果在开源之前不去查，放到GitHub上会有信息泄露的。合规和知识产权问题，今天我们邀请到了中国信息通信研究院专门做知识产权的老师毕春丽主任，也会专门针对这一块对大家做分享。

我们简单讲一些开源知识产权方面的问题，如许可证、知识产权专利、开源规则变化。2018年出了很多大家比较关心的事情，一些非常有名的开源软件修改许可证，当然原因可能跟云服务商有很大的关系，希望通过修改许可证的方式去限制云服务商对开源软件的使用，而不去贡献社区的这种行为。自发开源企业来讲这方面要重点关注。

管理风险。

自发开源企业对于开源如果都是项目组自己愿意开源就开源，没有统筹管理，里面涉及到的风险没有办法把控，如果代码里有专利等问题，没有做一些提前的申请，对企业来讲后续会有一些困扰。

用户风险。

包括管理方面的风险，今天上午给几家企业做了开源治理评估，也把优秀案例分享到了《金融行业开源治理白皮书》中，欢迎各位关注我们的成果。在里面邀请了很多企业写他们企业怎么做开源的，一会儿也有专家分享。我们认为，开源方面的风险首先要管，要知道自己企业里有什么开源软件，不能什么都不知道，这个风险其实大。

再有是运维和技术风险，用户核心诉求并不是这个软件，而是基于这种软件和信息系统去提供前台业务，其实没有那么多开发人员，也没有那么多精力去做软件的运维，包括技术支持，所以对于用户侧来讲虽然没有花钱买软件，但反而付出了更多其他的成本。

安全漏洞和缺陷问题。我们讲安全漏洞并不是开源软件和闭源软件哪个安全问题更严重，只是开源软件有安全问题、有漏洞问题，大家要关注。之前购买软件是有厂商提供运维支持，包括安全方面的支持，但很多开源软件这方面需要你自己持续跟踪、持续更新，包括社区会针对一些漏洞做版本的更新，如果不跟踪的话，这个漏洞还保存在现在信息系统里，有风险。

开源许可证涉及知识产权问题。

对于用户侧来讲，开源许可证并不是一定要特别深入了解，或一定要对知识产权问题特别懂、特别专，而是要让技术人员去知道有这么一个东西，开源是有知识产权的，是有许可证的，有授权的。这是一个产业科普问题，包括对我们用户侧技术人员是有这方面要求的。

基于以上这些问题，我们去年开始做国内首个企业级开源治理标准，邀请20余家企业参与我们讨论和编制，里面涉及到用户侧企业，也包含科技类企业，这个标准已经在CCSA立项，上半年已经完成了首批试评估工作，欢迎大家持续关注我们这个标准，后续会持续做一些修正或补充，进一步扩充这个标准，希望能够更满足、更贴近大家的实际需求。

下面简单介绍一下标准主要内容。

本标准分为两部分：

第一部分，自发开源企业，像腾讯或华为这种把项目贡献出去的企业。

第二部分，面向用户，也就是产业界，可能只是把开源软件拿过来用，而不是要把这个代码修改，还要贡献给社区，这个需求其实差异比较大。

首先介绍面向自发开源企业的标准。

为什么把这三项放到一页PPT里？是因为这对于企业来讲是偏基础设施或偏底层的要求。首先要有一个开源治理的组织机制，企业有一个部门或有一些具体人管这个事情，因为只有把这个职责具体分配到个人，才能持续推进下去，包括安全、知识产权、开源许可证，这个工作都是落实到个人或每个部门一些领导的。

开源项目管理制度，审批制度是必需的，企业里以企业名义开源出去是一定要经过审核的。但列成可选的辅导和激励机制是下一步更高级的要求，比如企业是否要设置一些课程或培训，或通过什么途径能够了解开源是怎么回事，怎么才能把一段代码变成一个项目开源到GitHub上，并且以企业的名义，我们对开源一些认识等等，都需要企业建立一些机制去做。

工具平台建设。开源工具平台对于企业来讲是基础设施，代码扫描、原创性等也不一定是只有开源才用得到，可能科技公司都需要做这些扫描。

这些我们认为是开源的基础设施。

再往下列了1234，是开源项目的流程，包括申请、审批、发布和关闭整个完整的链条。

申请。包括业务评估、技术评估和运营计划。其中业务评估主要是指项目一些基本情况，这个项目开源的优势，开源优势指跟竞品或跟同业相比项目优势在哪；开源收益，这个开源对企业有什么益处，是扩大影响力还是这个项目能后续带来一些收入，还是占据比较有利的位置，先占一个坑，这些其实都是需要在项目申请里做的事情；技术评估一般是直系领导，技术先进性，这个技术开源对整个公司生态有没有影响，包括专利申请是比较核心的问题，我们了解到科技公司不走完专利审批流程，这个项目肯定不可以开源。大家可能有一些误区，开源是没有专利或开源就是随便用的，其实不是这样的，开源里面是有专利的，如GPL2.0没有明确授予你专利的使用权，其实这种是有风险的，GPL3.0明确授予用户使用专利的权利，所以这部分也要持续做一些关注。运营计划。对于一个项目来讲很有可能虎头蛇尾，我们开出去之后就不管了。所以我们认为项目申请时要做一个人力、物力，包括整个项目宣传的规划，这在项目申请期都应该由项目组去做这个事情。

审批。业务、代码、知识产权、安全和存档都需要做。

发布。这个项目通过审批之后，可能需要通过公司公开的口径去发布，需要项目内部做统一的整合，给你一个项目地址，进一步对项目的说明、贡献机制等必备要求都需要满足。

关闭。我们认为没有一个项目是可以持续不灭亡的，一定会有关闭的一天，技术是在不断变革的，我们认为在开源项目出生的时候就要想起它可能会有一天被关闭。所以从企业管理来讲，会要求它有这方面的制度去完善项目关闭之后要告知社区成员，要做项目归档。

最后两个可选内容，社区管理和运行维护是一个更高的要求，如提供一些公开的沟通渠道、及时回复反馈、版本更新、贡献管理等。

面向开源用户方面的标准。

管理制度和组织机制方面需要一个实体或虚拟组织做这个工作，管理制度包括引入、使用、风险管理、版本更新和退出全流程企业内部规章制度去做个事情，相当于有据可依。

从选型问题上来讲，是用户侧可能面临比较重要的一个问题，分为产品的活力度、行业认可度、软件质量和服务支持能力的评估。

产品活力度方面，包括产品的star、commits等，它的趋势，会不会这个产品慢慢就没有人关注了，社区是否活跃，行业支持度，如这个软件有没有一些比较大的企业在里面做支持工作。

行业认可度方面主要是关注一些同业的商业化实践和案例，还有一些企业内部已有应用和第三方公司评估。

软件质量，不同软件差别会很大，应用到系统级的，如中间件操作系统，和一个小组件肯定有很大差别。我们现在简单列出几条仅供参考，服务支持能力是用户侧比较关注的一个方面，如果不去购买第三方服务的话，可能服务支持能力对于用户侧来讲就是一个社区和文档，所以我们要关注社区自己说明文档的质量，包括有没有相应的中文社区等等。对于第三方来讲，可能买了服务，考察第三方一些运维服务能力、第三方公司在社区的贡献程度，包括软件接口是否兼容等问题。

风险是用户侧强调比较多的问题。分为四个部分：统一引入管理，包括统一管理平台、统一审核流程，到风险识别，包括开源许可证的风险、安全的风险。我们认为这个软件用了什么许可证，这个许可证是什么，首先要有记录，其次要有基本的企业内部的规则，做存档和审批，包括安全漏洞，我们也认为应该做安全漏洞的扫描，要了解这个开源软件里到底有多少漏洞，安全情况是什么样的。

风险的处置，强调处置方面的指导，即发现问题时，这个软件有漏洞，是不是有安全部门指导我如何去修复漏洞，应该怎么反馈，包括其他方面的指导问题。

开源风险记录沟通机制。我们认为所有发现的风险包括处理的风险一定要有一个企业内部统一的记录，以及要建立一个完善的沟通机制，就是发现这个问题时能找到谁，应该谁负责。

二次开发，我们跟企业聊的过程中，用户侧并不太涉及这个问题，大家基本现在还是用的阶段，不会把代码进行修改，更多是强调使用方面和持续跟踪方面的问题。我们强调持续跟踪，像社区、漏洞、版本、许可证这些方面的持续跟踪并不是大家一定要每天盯着社区情况看。如这个版本可能更新一个新版本，把之前漏洞修复掉了，我们到底要不要更新，首先要知道这个事情，才能说后续要不要做一些处置或要不要做版本规划把它规划进去。

社区反馈和退出机制。

社区反馈很有意思，现在国内用户基本不太会直接贡献社区的，这里有一些原因，如国际大社区根本不会理你，这么小的一个企业或这么小的一个个人，不会特别care你贡献了什么代码，也并不能接收到一个比较好的反馈。我们希望从行业角度、从用户侧角度去把大家优秀的经验做一个整合，形成合力去推动整个产业的发展，帮助用户侧更好地用开源。我们没有办法直接跟科技公司或顶级的基金会做沟通时，是否有一个没那么高门槛国内的社区去把这些同行业的优秀经验做一个整合和推广，我们希望做这个事情。

退出机制。据我之前了解，大家现在不太涉及退出问题，顶多是版本更新或版本退出，不会是软件退出。但大家要知道，现在管起来开源软件可能才一年、两年算长的，但最后会持续去管这个东西，不能说这个软件越来越大，软件一定会有退出或有它的生命周期。所以我们认为退出方面分两个部分：

第一部分，自上而下的退出，就是规划型的退出。如有的用户是半年会有一个版本规划或有一个软件企业内部信息系统的规划，我们认为这是自上而下的退出。

第二部分，自下而上的退出，可能真正使用部门慢慢不用这个东西，要有一个反馈机制去告诉架构管理处或真正去管这个软件，统筹管理list的人，告诉他这个东西我不用了，这样其实是比较好的循环。

用户侧开源治理小结。

开源软件与其他非开源软件到底要不要一起管？这是很多用户侧面临的选择，到底单独做一块还是跟其他之前买商业软件做在一起？如果单独管，可能是开源软件单独审核，引入和使用是分离的，如开源软件可能会用，就先让它走一个引入流程，之后把它许可证、安全漏洞都扫了，之后认为可以用，然后找一个靠谱的官方的链接下载下来放大我的代码库里，等到选型时或内部做规划时，我要用了，直接从库里拿，这是一种方法，选型和开源管理比较分立。另外一种是统一的，不管是开源闭源的，在做选型时就根据需求选，可能选出来三款五款，这里有开源有闭源的，统一之后根据功能、活跃度、市场上同行业使用情况等一起去评，最后选择用哪个就用哪个，不敢开源还是闭源的，但是开源可能要多审查一些项目，最后把这些项目所有开源软件放到同一个库里，企业内部统一代码仓库，最后统一构建，这是一种方式。这也是留给我们的一个共同探讨的话题，整个用户侧的开源治理我们认为还是处于一个开始探索的阶段，还有很多方面是需要持续去做的。

今年上半年我们做了一个评估，希望帮助企业规范开源流程，助力企业建立良好的开源治理体系。

首次评估里发现了一些可以讨论的点：

面向自发开源企业，如科技公司。

1.开源知识产权问题相对比较复杂，比如这个软件想开源出去，到底用什么许可证，这个问题可能需要知识产权专家去审，需要很久。各个组件之间涉及到依赖关系，包括开源许可证之间也有兼容不兼容的问题，包括企业会有一些偏好，所以开源比较复杂。后续希望能够推动建立一些方面的通用规则。

2.缺少自上而下的开源规划。国内自发开源企业更多是自下而上的开源，就是这个项目组有一个好的东西，跟领导审批或跟开源管理办公室审批，我想把这个东西开出去，而不是像国外一些企业自上而下有一个规划，从商业布局角度或从生态规划角度我要做哪个方向的开源，这其实是我国自发开源企业后续可以继续考虑的问题。

用户侧。

1.治理流程需要进一步自动化，现在用户侧有一些地方用word、excel邮件去统计。

2.开源软件选型问题相对比较复杂，经常买闭源软件更多是乙方过来跟我们汇报这个软件怎么样，但现在我们用开源软件很多东西需要自己去调研，到底需要考察哪些方面，也是我们需要持续探讨的问题。

3.开源知识产权认识有待增强。现在用户侧对开源相关知识产权问题还有待科普。

首批通过评估的企业，包括用户侧的浦发银行、农业银行、太平洋保险、腾讯，我们今天也邀请了其中两位专家过来跟我们做分享。

后续我们工作主要包括：

评估，会持续推进可信开源治理能力了评估。