如何用AI技术降噪? QCon 广州“音视频架构实践”专场给你答案! 了解详情
写点什么

CentOS 社区如何发展才能“加速创新”?

  • 2022 年 7 月 27 日
  • 本文字数:4875 字

    阅读完需:约 16 分钟

CentOS 社区如何发展才能“加速创新”?

2020 年 12 月,CentOS 社区宣布 2021 年底停止维护 CentOS 8,2024 年 6 月 30 日停止维护 CentOS 7,并推出了 Centos Stream 项目,承担 CentOS 的功能,从此进入“向 CentOS Stream 迁移”的后 CentOS 时代,这一变化在市场上引起了持续不断的反映。比如,CentOS 社区如何发展以加速创新?Linux 操作系统生态发生了哪些变化?为什么 CentOS Stream 是进一步推动 Linux 创新的最佳方式?

 

近日,在红帽举办媒体沟通会上,开源布道师、社区和开发者业务策略师 Brian Exelbierd,CentOS 社区委员会成员 Thomas Oulevey 及 Linux 中国创始人王兴宇就 CentOS 社区变化和创新进行了圆桌讨论,一起探讨了 Linux 生态的未来发展。本文对圆桌现场对话进行了整理,以下:

Q1 王兴宇:首先我们来回顾一下两年前的历史背景上,历史上 CentOS 和 Red Hat 的关系如何?CentOS 在 Red Hat 的产品线中的定位什么样?

 

Brian:大概 7 年前,我们收购了 CentOS ,雇佣了 CentOS 项目的工程师,这就是红帽和 CentOS 项目的关系。我们这么做的目的是提供一个平台给某些特定的高级开发比如虚拟化、其他工具等运行于操作系统之上的组件开发,我们希望借此鼓励这些项目(虚拟化、其他工具)能够以开源项目的方式健康发展。随着时间的推移,我们逐渐意识到上层项目越来越依赖于底层操作系统的变化。我们发现 CentOS 正好可以作为这个底层操作系统,是一个可以孵化其他项目的好地方,借此我们可以在做 RHEL 开发的同时,也去做 RHEL 之上其他组件的开发,与广大社区开发者一起,每个人都可以促进底层操作系统与上层组件的协调发展。这就是我们发展 CentOS 项目,大概在 3 年前提出 CentOS Stream 的原因。

 

关于第二个问题,红帽对待 CentOS,始终保持着“一臂”距离。从红帽产品线的视角来看,CentOS 不是红帽的产品,红帽不提供对 CentOS 的支持,我们不对 CentOS 提供保障,我们也不对 CentOS 使能。但 CentOS 确实对红帽的产品很重要,因为红帽做的所有工作都是基于开源的代码库,所以我们需要这个项目作为工作地来产品化这部分代码,比如在虚拟化领域,RHEL 就是基于 CentOS Stream 而制作出来的。

Q2 王兴宇:什么原因促使 CentOS 做出来关闭 CentOS 的决定,并且发展出来 CentOS Stream 这样一个想法的?

 

Thomas:我大概三年前加入 CentOS 董事会(治理委员会),当时大家在讨论如何提高对 CentOS 社区的参与度问题,“如何给用户更好的使用体验”等很多提议被提出来,最后大家认为 CentOS Stream 是我们在未来的一个正确的努力方向,通过这种模式可以提高 CentOS 的社区参与度。CentOS Stream 的模式对社区版的企业级操作系统发展也至关重要,总体来讲之所以会做出这样一个决定,就是想要改善社区的参与度。

Q3 王兴宇:关闭 CentOS 的决定应该是 CentOS 社区自发做出的,在做这样决定的时候,社区内部有没有反对意见?最大的反对意见是怎么样的?你们怎么平衡这样的反对意见的?

 

Brian:CentOS 的治理模式和很多其他开源项目的运作模式有所不同。CentOS 董事会需要每个人都对一个新的决策达成共识才可以,这个共识可以是 yes,也可以是 No,甚至可以是中立的意见,但最重要的是一定要达成一致。

 

Thomas:我们的唯一目的是希望 CentOS Stream 的社区变得越来越好,真正地实现“开源”,所以这个“一致意见”必须是要有利于社区的未来发展或能为用户带来更好的体验。从长期的角度来看,我们希望 CentOS Stream 代替 CentOS Linux 后,可以让所有人都能满意。

 

社区的用户很多,每年我们也会开一些会议或组织一些活动,这里聚集了许多有趣的人,我们可以在一起工作或交流生活。至少到目前为止,我们觉得 CentOS Stream 这个模式比之前更好了,有更多的人愿意向社区做出贡献,所以我们开的会议也都是完全透明的,所有人都可以在 youtube 上看到我们的讨论内容。

Q4 王兴宇:我们看到在后 CentOS 时代整个开源操作系统市场格局已经发生很大变化,在这种情况下,对于 CentOS,对于 RHEL 的产品迭代有没有影响?目前来说,把 CentOS 换成 Stream 以后,是否社区对 Stream 的贡献更多, RHEL 是否因此变得更好?是不是可以给出一些数据来说明这个变得更好?

 

Thomas:从社区的角度讲,整个流程变得更开放了,你可以参与所有的讨论,通过 CentOS Stream 可以直接参与对 RHEL 发展方向的讨论,在 Stream 里所看到的就是即将发布的 RHEL。举个具象一些的例子,CentOS Stream 9 是 RHEL 9 的上游,通过 CentOS Stream,你可以直接参与到 RHEL 的开发当中,如通过 bugzilla 提交问题、提交补丁。与你一起工作的还有很多红帽的开发者,他们会和你一起检查代码,你写的补丁也要通过 RHEL 的测试流程,红帽会评估补丁是否满足 RHEL 的质量要求,这决定着它是否能被加入到 CentOS Stream 里。

 

Brian:从红帽的角度来看,最值得一说的是 CentOS Stream 里有非常强大的 SIG 小组,通过 SIG 小组也形成了 CentOS 项目的生态,SIG 小组的人们会提出很多想法,这些想法提出的初衷并不一定和 RHEL 相关,更多的是与社区参与者自己相关,或者是他们对 RHEL 的期待,红帽也是以旁观者的身份去看待这些反馈,一些好的想法就会在 RHEL 的大版本中落地。

Q5 王兴宇:之前对于 CentOS Stream 一直在宣传 Stream 模式会让社区更容易参与到 Stream 的贡献之中,所以,CentOS Linux 8 去年底停止服务以后、Stream 出现以来,社区对 Stream 的贡献是不是更多了?这里从你们的管理层来说有没有这样一个数据或者图表可以证明这些东西?

 

Brian:我看这个问题从两方面来看,一是贡献量的衡量,我们现在其实能够实实在在的看到越来越多的公司、个人他们都在直接的参与到对社区的贡献当中,这些贡献要么最终被收录到 RHEL 的代码当中,要么这些讨论依然保留在 SIG 小组里面。另一方面,Stream 出现以来是不是贡献量更多的问题,其实这并不是“变更多”的问题,而是“从无到有”的问题。

 

要知道,之前对于 CentOS 项目贡献,只有两个途径:第一个途径就是你的代码先被上游社区接受,然后被 Fedora 集成,然后被 RHEL 集成,最后出现在 CentOS 里,这是一个漫长的路径,而且不是对 CentOS 做贡献;第二个途径就是你必须是红帽的客户或合作伙伴,在打造 RHEL 的过程中,你的想法如果是一个高优先级的事情,那么会被优先加到 RHEL 里,然后出现在 CentOS 里。

 

有了 Stream,实际上是有了第三个途径,通过 Stream 可以直接把贡献集成到 RHEL 里。关于数据,CentOS Stream 的代码日志都在 gitlab 里。对于 CentOS Stream 8 来说,因为是处在 CentOS Linux 模式到 CentOS Stream 的模式转变的过程当中,几乎所有的贡献都来源于红帽。但对于 CentOS Stream 9 来说,你可以通过 git log 看到所有的贡献,对于每一个贡献,你可以去查看代码的修改轨迹、社区的讨论,bugzilla 上的讨论。

Q6 王兴宇:去年 CentOS Linux 8 停止更新以后,红帽这边接到的最多的反馈是什么?红帽或者 CentOS 接到的最多反馈是什么?你们做了哪些回应?

 

Brian:确实有一些人的反馈是“你们怎么敢这样做?这让我很愤怒”。那么我们的回应是,“冷静下来,考虑一下 Fedora Linux 与 CentOS Stream 的价值主张”。

 

这个之外,我更想讨论一下 RHEL,或者很多其他 的 Linux 发行版。RHEL 和 RHEL 衍生版如 CentOS,有很多用户。我们的客户和我们讨论的通常是 RHEL,事实上我们没有通过 CentOS 服务客户,因为我们的产品是 RHEL,我们收到的客户反馈也通常是 RHEL 小版本发布相关的问题,比如有些客户想尽早知道我们是如何在下一个小版本中修复 bug 的,这样他就可以早一点将他的系统和红帽的操作系统做持续集成,而不必等到 RHEL 的下一个发布。

 

当然,早期我们也听到另一种声音,类似于“现在在我的桌子上就有一台 Linux 服务器,我一直使用的是 CentOS Linux,那么现在我该怎么办?”那么,我们的回答是,“您可以使用免费的 RHEL 的个人开发者版本。”因为我们的目的只有一个,就是促进开源社区的发展,诚然,开源社区发展好了,对我们的产品也有益,但所有解决方案的出发点都是促进开源社区发展。

 

Thomas:我从社区角度回答这个问题。最初我们确实听到了一些抱怨或担忧,比如“ Red Hat 是不是从源头上杀死了制作 CentOS 的可能性 ”,关于这点我要澄清的是,任何人都可以按按照 CentOS Linux 的做法制作 CentOS Linux,有一些人已经这样做了。有些人已经和我们取得了联系,并且获得了我们的帮助。这是大家的自由,我们不会去阻止人们去做他们想做的事情,相反,我们欢迎大家到 CentOS 社区讨论。

 

另一点,就是关于 CentOS Linux、CentOS Stream 的稳定性问题。我之前频繁使用 CentOS Linux,我把 CentOS Linux 用在了开发测试环境上。从我的经验来看,CentOS Stream 是稳定的。CentOS 是一个社区项目,大家有绝对的自由去决定 CentOS 用在什么场景中。

Q7 王兴宇:在做出 CentOS 停止服务这个决定之前,你们是否预料到如今会出现多个替代品,这些替代品既有像 RockyLinux、AImalinux 这样的原位替代的 CentOS 的替代品,也有像中国的 openeuler、anolis os 这样的并非原位替代的,但是从某种意义上可以取代原有 CentOS 市场占有的这样一些发行版,你对这两类发行版有什么看法?

 

Thomas:现在一切都是开放的,所以实际说现在比起十年前如果有人想要打造一个我们的替代品,相当于更容易、更简单了,但我们一点也不怕这个,我觉得这是别人的自由与权利,而且我们也非常希望看到这样的发展态势。

 

Brian:作为一个以开源模式制作企业软件的公司,我们深知任何人都可以拿到这个代码做他们想做的事情,这是很 Cool 的。但我们希望的是,如果你拿到这个代码,你去添加了新的功能或修复了 Bug,你也像其他人一样,将你的改动回馈到社区里去。

 

从红帽的角度,我还想强调两点,一是我们在制作 RHEL 这个产品的时候,我们更多考虑的是我们客户群他们有什么样的特殊需求、特殊场景需要满足,解决他们的问题。RHEL 就是以“心怀用户”的初心去开发的一个操作系统。二是开源软件公司为客户提供的价值不仅仅是代码本身,更多的是位于代码之上的东西。因为代码是开源的,任何人都可以获取这个代码并使用它。所以我想鼓励人们去思考,当你在选择一个操作系统的时候,你最看重的他的价值是什么。因为在源代码之上有很多价值,比如解决问题的能力、服务能力。

 

另外,说到市场占有,像其他替代品,这个市场占有实际上做衡量很困难,第三方机构呈现的可能不是最真实的市场占有率数据。

Q8 王兴宇:如果企业在自己的产品环境中要应用 Stream 作为他的基础操作系统,您这边有什么最佳实践可以分享给大家?

 

Thomas:我们确实在自己的环境中使用了 CentOS Stream。我们首先要评估自己想要做的事情,特别是在一个大的公司里面,每个部门可能诉求都不尽相同。在我们的评估中,我没有看到 CentOS Linux 和 CentOS Stream 的表现有什么不一样。对很多企业来说,你可能要使用一致的操作系统,满足安全、稳定性的要求,这些在我看来,CentOS Stream 和 CentOS Linux 都是一样的。对于用户来说,可能有些特殊的工作负载、工作流程,那么做好测试,确保操作系统能够满足要求即可。

Q9 王兴宇:关于 Fedora、Stream,还有 RHEL 未来的发展计划是什么?可以展示一下路线图吗?

 

Brian:我从两个维度来回答,首先是社会组织的维度:

1)Fedora:主题是如何提高对 Fedora 的贡献,如何使得社区更多样化;

2)CentOS Stream:和 Fedora 差不多,提高社区贡献和是社区更多样化,另外就是发展 SIG(特殊兴趣小组),充分发挥 SIG 的作用;

3)RHEL:进一步繁荣包括社区、合作伙伴、客户的 RHEL 生态。

 

其次是代码的维度:

1)Fedora:

● 集成上游社区最新最好的代码,功能最丰富,做业界的引领者;

● 面向特定的场景,做特色的发行版,如 Fedora IoT, 就是面向物联网场景的 Fedora 操作系统。

2) CentOS Stream:

● RHEL 稳定可靠的持续交付版,用户可以提前看到即将发布的 RHEL 版本;

● 基于稳定的代码基础,通过社区发展 SIG,在特定领域创新。

3) RHEL:我们面向客户的销售团队有很多关于产品的介绍,红帽大中华区可以给到很好的支持。

2022 年 7 月 27 日 11:581

评论

发布
暂无评论
发现更多内容

微信朋友圈的高性能复杂度

smile

架构实战营

朋友圈高性能复杂度分析

风中奇缘

架构实战营 「架构实战营」

模块二作业

Geek_ec866b

架构实战营

Linux之iostat命令

入门小站

微信朋友圈的高性能复杂度分析

tom

微信朋友圈高性能复杂度分析

Geek_f3e842

架构实战营

剑指Offer——你真的看懂无领导小组面试了吗?

No Silver Bullet

面试 offer 2月月更 无领导面试

《人月神话》第十六章阅读笔记:没有银弹

panda

人月神话 阅读笔记 没有银弹

《人月神话》第十七章阅读笔记:再论“没有银弹”

panda

人月神话 阅读笔记 没有银弹

学生管理系统详细架构设计

刘洋

架构实战营 「架构实战营」

架构实战营:模块二作业

刘璐

微信朋友圈架构设计

随欣所遇

#架构训练营 架构训练营5期

作业七-王者荣耀商城异地多活架构设计

曾竞超

架构实战营 「架构实战营」

架构学习【02】——朋友圈高性能复杂度分析

tiger

架构实战营

从冬奥看中国科技(二):造雪突围进行时

脑极体

每天都扫的二维码,你知道它的技术原理吗?

慕枫技术笔记

后端 2月月更

Netflix是如何做决策的? | 7. 学习的文化

俞凡

数据分析 netflix 大厂实践 2月月更

模块二作业

Mr小公熊

聊聊领导力与带团队的那些事

大卡尔

团队管理 领导力 质量保障 2月月更

真正的Kafka多线程消费

dinstone

kafka 多线程 并发消费

在线YAML转CSV工具

入门小站

工具

【第 24 期】前端食堂技术周刊

童欧巴

前端 前端开发 行业资讯 周刊 资讯

欢迎客户支持自动化领域的新兴领导者 Percept.AI 加入 Atlassian 大家庭!

Atlassian

敏捷 Atlassian Jira JiraServiceManagement 客户服务

微信朋友圈的高性能复杂度分析

张逃逃

跨平台移动APP开发进阶(三):hbuilder+mui mobile app 开发心酸路

No Silver Bullet

跨平台 2月月更 mui

开杠面试官-微信朋友圈高性能架构

晨亮

「架构实战营」

微信朋友圈高性能架构分析

IT屠狗辈

架构 高性能 微信朋友圈 架构实战营

架构实战营作业 2

zh

架构训练营

微信朋友圈高性能复杂度分析

孙强

#架构实战营

重学架构之微信朋友圈高性能架构分析

陈华英

架构训练营 架构实战营

微信朋友圈高性能复杂度方案设计

Fingal

架构实战营

「云智公开课」百度沧海·存储

「云智公开课」百度沧海·存储

CentOS 社区如何发展才能“加速创新”?_云计算_鲁冬雪_InfoQ精选文章