社区规模的进展:

对于由华为发起的开源社区,openEuler 社区一直在努力推动社区真正的开放式运作, 最近,通过数据的统计,我们有了一些令人欣喜的发现。为了保证数据的可靠性,我们收集了两个数据来源,可以发现:

月份 提交pull requsts数量 外部贡献占比
  gitee统计 om.osinfra.cn统计  
6 1809 2228 18.80%
7 1823 2650 31.20%
8(截止到24日) 1748 2455 28.80%

从 7 月的统计看,openEuler 全月的所有 PR 中,有略超 30% 来自华为员工之外;8 月因为要准备 20.09 新版本发布,华为员工的提交比过去两个月同期增加了不少,但是其它公司和个人的贡献依然比较稳定的接近 30%。对比 4 月的报告中只有大约 6% 的工作来自其它公司和个人,这是个不小的进步。我们可以骄傲的宣称,openEuler 已经进入到真正的社区运作模式中了。

在 4 月的报告中,我们统计 openEuler 有 2215 个组件项目;截止到 8 月 24 日,src-openeuler 中包含组件项目有 6211 个。6000 个以上的软件包也是一个标志性的事件,一个完整的服务器操作系统通常都包含 5000-6000 以上的软件包,只有越过了这个阈值,才能使得操作系统成为一个能过够独立演进的系统。至此,我们相信 openEuler 已经具备了一个完备的 OS 的全部要素,后续的发展会呈现出加速性的成长性。

8 月新增的 SIG 中,已经正式合入的有 4 个。

  • 湖南麒麟申请成立 sig-KIRAN-DESKTOP。因为和 sig-mate-desktop 一样,这个 sig 的工作也是在 mate-desktop 基础上做增强,技术委员会协调两个 SIG 做了一次线上沟通对齐,最终明确了两个 SIG 的分工协作方式,并同意 sig-KIRAN-DESKTOP 成立。

  • Java 领域的最大进展来自 中科院软件所的雒海波,他主导申请成立了 sig-Java。这个 sig 将围绕 Java 生态中的软件包,尤其是 Maven 中的软件包,降低 openEuler 集成与管理的门槛。Java 生态中融入 openEuler 这个目标有望得到实现。

  • sig-OKD 是麒麟软件申请成立的,目标是移植 Redhat 的开源企业级容器云 PaaS 平台到 openEuler 上。这和其他几个 SIG 形成了有趣的互补。技术委员会希望看到 sig-openstack,Virt,iSulad,sig-OKD 在后面的配合中能激发出新的化学反应。

  • sig-OS-Builder 是 openEuler 团队开发人员申请成立的,目标是通过自动化的工具,方便使用 openEuler 的厂商和爱好者能够快捷的自定义构建和安装。

4 个新成立的 SIG 中,有 3 个来自生态合作伙伴。

此外,在各个 SIG 的进展中,华为的贡献主要集中在 LTS 版本的软件升级和维护,以及基础软件的引入;而值得一提的是,统信软件的 DDE 也已经完成了在 OBS 环境中的完整构建。openEuler 在开源大半年以后,已经能够提供比较丰富的桌面环境选项。

本月的报告,技术委员会在肯定社区进展的同时,还是要指出几个值得关注的风险:

构建系统的改进

上月的报告中,技术委员会指出 openEuler 社区的安全漏洞修复与披露流程存在较大的风险。经过流程的梳理,技术委员会认为,openEuler 社区的安全应急响应技术能力是得到验证的,但是例行的安全投入和流程上存在明显的瑕疵。最大的问题在于安全漏洞修复的及时性和版本的发布中间产生了断层,虽然问题修复很及时,但是后续的制作软件包,软件包的及时发布上出现了问题。这昭示了另外的一个问题,就是社区版本的构建问题。

在当前 openEuler 的发布流程中,我们会先构建出补丁版本,然后再补丁版本发布的同时发布安全公告。但是由于若干原因,实际上在 6 月下旬开始,openEuler 的 LTS 就没有成功的完整构建过。开发团队的初步反馈如下:

  1. firefox 这个包的 CVE,社区没有给 LTS 版本的补丁,但因为版本跨度非常大,无法 backport,所以只在迁移最新版本解决了漏洞。开发团队考虑同步升级 LTS 版本的 firefox 版本,但因为依赖关系,又必须同步升级 LLVM、nss、nspr、rust 等若干软件组件。由于担心 LLVM 等组件的升级影响,开发团队又反过来等待各家使用 openEuler 的厂商沟通反馈。
  2. 其他 CVE 已经解决,但这些 CVE 修复会涉及 60+的包需要 rebuild 并发布新版本,这个目前主要是依赖人工来改的,并且修改后触发 OBS 全量编译。而全量编译过程中,又由于码云无法控制对 LTS 分支的代码合入,反复出现个别软件新版本临时合入导致的构建失败。
  3. 安全漏洞的修复触发了安装系统的 bug,因此还需要额外的稳定性补丁,并且再次触发全量构建。

我认为,在承认这些客观因素的前提下,问题出现的根本原因还是在 LTS 版本发布的机制设置。理想情况下,安全委员会定期同步待分析的安全漏洞,开发团队定期清理修复安全漏洞,最终这些修复的补丁版本视风险等级如期发布。而在 8 月的运作中,安全委员会认为自己如期完成了漏洞信息同步、分发的工作;开发团队认为自己每两周都会清理一次安全漏洞相关的修复;独独没有人关心最终呈现出来的漏洞修复结果。

另外,openEuler 社区中参与的厂商越来越多,像 llvm 升级这样的案例,在将来也会不断出现。技术委员会需要考虑建立一种更加紧密的例行沟通方式,以保证获得及时有效的反馈。

安全可信的工作,用功在平时。技术委员会希望参与社区的所有人谨记这一点。

容器技术的可获得性影响

Docker, Inc 在 8 月 13 日更新了《服务协议》,在国内开源软件圈子中引起了热议。关于开源项目的风险和对策建议,CRVA(China RISC-V Alliance)和中科院计算所联合发布的报告[1]和中科院计算所联合发布的报告")解读中已经有较详细的分析。

openEuler 社区 Container SIG 的 maintainer @caihaomin 对当前业界容器技术软件栈做了相应的梳理。在容器引擎,镜像仓库,构建工具等领域,虽然 docker 之外还有 podman,cri-o, containerd, buildah 等等备选方案,但这些方案在代码中全都声明受出口管制影响。相对而言,openEuler 社区中托管的 iSulad 项目,是目前可以看到唯一完全脱离 Docker 开源代码,并不受出口管制影响的容器引擎实现。

技术委员会希望 openEuler 社区的参与者一起,继续完整 iSula 生态,一方面补全镜像仓库解决方案,去除 isula-build 对 docker 数据结构的依赖;另一方面通过 SIG 间的合作,构建一个完整的容器解决方案。

如 7 月运作报告中提到,openEuler 技术委员会一直关注所集成组件的供应链管理。Docker 的这次小风波,也是从另一个侧面反应了供应链管理的重要性。

技术委员会还在关注其他领域是否存在类似的情况,后续将组织各个 SIG 梳理。

批量增加软件包的风险和应对 openEuler 社区运作是建立在各个 SIG 各司其职与互相配合之上的。最开始的设想是每个 SIG 有自己熟悉和看护的领域,便于积累和发挥所长。但是,正如在 5 月的报告中提到过的,软件依赖关系的复杂性,使得大型软件的引入过程往往伴随着一次性添加数百个软件包来解决依赖关系的诉求。这样的批量软件导入,本身就有一定的复杂性。因此,各个 SIG 组都希望简化批量引入的流程。

但技术委员会的观点刚好相反。我认为如果没有合适的自动化工具支撑,对这样批量添加的软件需要保持的警惕。因为这些被依赖的软件在引入过程中往往不是开发人员关注的重点,社区对这些软件的理解和实际维护能力有限。如果没有做好充分的准备,引入之后会成为维护的薄弱环节。

为此,在最近的一个PR[2]中,我们希望明确对软件包批量导入的对策。技术委员会认为所有引入的软件包都必须有相应的 SIG 负责管理。如果没有相应的 SIG maintainer 确认,技术委员不会批准相应软件包的引入。当前 community 的 CI 检查工具已经做了相应修改。希望通过这样的方式,更好的管理软件包引入的源头。

从实践看,当前 openEuler 在 perl, python 上已经实现了自动化工具的支持,所以这两类语言的组件作为软件包引入时,可以很顺利的找到归属 SIG。Java 的看起来也有望在近期解决。但 Ruby 和 nodejs 反而成为了主要的风险,在最近引入 jetty 的过程中,各有几十个 rubygem 和 nodejs 软件包需要进行管理。技术委员会希望尽快通过自动化工具来自动生成这类的软件包,并将这些软件包归类到相关的专门 SIG 组中。

总结和展望

在过去几个月中,openEuler 逐步引入了很多的公司和个人参与到了开发中,社区也终于建立初步的开放治理机制,不论是固定时间的技术委员会例会,还是线下的讨论会,都保证了社区的逐步成熟。同时软件规模也在快速提升,这给 openEuler 后续的演进提供了很好的基础。但是我们也发现的安全公告的及时性问题,构建的成熟性问题等,这再次提醒我们,对所有问题的审视和解决要有外部视角。希望大家能对社区的运行加强监督,促进社区的良性发展。

参考资料

[1]

CRVA(China RISC-V Alliance)和中科院计算所联合发布的报告: http://crva.ict.ac.cn/documents/Comments-on-Risks-of-Open-Source-Projects.pdf

[2]

PR: https://gitee.com/openeuler/community/pulls/796/