DeepSeek总结的为什么开源可持续性的循环需要是良性的-深圳市維司達科技有限公司

来源： https://www.gabrielebartolini.it/articles/2026/04/why-the-cycle-of-open-source-sustainability-needs-to-be-virtuous/

为什么开源可持续性的循环需要是良性的

2026年4月28日 · 10分钟阅读

PostgreSQL · Postgres · Kubernetes · K8s · CloudNativePG · CNPG · DoK · Data on Kubernetes · 开源 · 可持续性 · pgBackRest · Barman

一个章节的结束

一段富有成效的竞争故事

结构性问题

CloudNativePG 与结构性保护

良性循环

致 David

昨天，David Steele 宣布 pgBackRest——一个他维护了十三年的 PostgreSQL 备份工具——生命周期结束。原因是结构性的，而非个人性的，这提醒我们在开源基础设施中看到了一个过于常见的模式。本文反思了这意味着什么，思考了 pgBackRest 和 Barman 之间的架构竞争，并解释了为什么 CloudNativePG 的用户可以从该项目的 CNCF 治理以及支撑它的商业支持的良性循环中获得信心。

一个章节的结束

昨天，David Steele 宣布 pgBackRest——一个他倾注了十三年职业生涯的项目——将不再维护。他偏偏选择了我生日这天将其归档。这份声明清晰而有尊严：在 Crunchy Data 被出售后，他无法获得一个新的职位或赞助，让他能够继续妥善地进行这项工作。他没有让项目因资源不足的零星维护而衰败，而是选择了一个干净的终止。

一段富有成效的竞争故事

我在这里应该声明一下利益关系。我是 Barman 的创建者，这是一个早于 pgBackRest 的 PostgreSQL 备份和恢复工具。Barman 1.0 发布于 2012 年 7 月，此前经历了近两年的闭源开发，并在欧洲研究基金通过 4Caast 项目的支持下开源。自 2019 年我将全部注意力转向 Kubernetes 以及后来的 CloudNativePG 以来，我便不再参与 Barman 的开发——Barman 仍在 EDB 的支持下持续演进——但它的起源主要归功于我和 Marco Nenciarini，随后在 2ndQuadrant 和后来的 EDB，一个团队围绕着它稳步成长。

项目的名称本身就说明了故事。Barman 代表 Backup and Recovery Manager——选择这个名字是为了填补当时 PostgreSQL 存在的空白，在我看来今天这个空白依然存在。这个名字也有意呼应了 Oracle 的 RMAN，这并非巧合：Barman 在 2ndQuadrant 最早的客户和赞助者正是那些从 Oracle 迁移到 PostgreSQL 的 DBA，他们需要在备份和恢复方面有一个熟悉的参考框架。PostgreSQL 自带了 pg_basebackup，一个用于进行基础备份的可靠工具，但没有对应的 pg_baserecovery。灾难恢复的恢复端一直留给 DBA 用自定义工具或第三方工具来解决。Barman 就是为了提供完整的解决方案而构建的：不仅仅是捕获备份，而是为 PostgreSQL 部署管理备份和恢复的完整生命周期。

在设计 Barman 时，我们做了一个深思熟虑的架构选择：我们不会在工具内部重新发明数据复制机制。我们相信这个功能应该属于 PostgreSQL 本身，备份工具应该围绕数据库已经提供的基本功能来构建——2ndQuadrant 当时正积极为改进这些基本功能做贡献。在早期，这意味着通过 SSH 使用 rsync 与 PostgreSQL 服务器进行文件传输——久经考验、无处不在，不需要我们重写。我们信任 PostgreSQL 及其周边生态系统来处理数据移动；我们的工作是编排、保留和恢复管理。初始许可证特意选择了 GPL 3，知识产权归 2ndQuadrant 所有——这是一个结构性的选择，旨在确保项目能够获得资金支持，并且公司能够围绕它建立一个可持续的商业生态系统，就像当时我们为 PostgreSQL 开发的其他工具（包括 repmgr）一样。

值得注意：Barman 最初作为闭源软件为 2ndQuadrant 客户开发时，pg_basebackup 还不存在。它于 2011 年在 PostgreSQL 9.1 中问世，那时 Barman 已经在使用中了；当我们在 2012 年将其开源时，pg_basebackup 还是全新的。延迟采用它并非疏忽。大约在 2015 年，Simon Riggs、Marco 和我致力于一个提案，希望将原生的增量备份和恢复支持直接添加到 PostgreSQL 中——这是正确的地方，符合 Barman 所主张的一切，甚至预示了一个pg_restorebackup工具的出现，随着时间的推移，它将解决我上面描述的空白。我们未能推动它通过。这次尝试耗费了我们大量的时间，延误了 Barman 的开发，而且我承认，这对我个人造成了影响：我得出的结论是，开发 PostgreSQL 核心并不适合我——或者更诚实地说，我不太适应这项工作。我们最终在 2016 年将 pg_basebackup 集成到了 Barman 2.0 中，这是正确的决定。但我们先尝试了更困难的方式。幸运的是，Robert Haas 最终在 PostgreSQL 17 中从零开始原生引入了增量备份支持——这如果需要证明的话，证明了这个想法从一开始就是正确的。恢复端，包括网络传输，至今仍未实现：这是另一个等待被填补的空白。

David 是 Barman 的早期用户。他根本不同意这种做法。他的信念是复制机制应该存在于备份工具内部，这样就可以完全控制它。他没有提交功能请求或写一篇冗长的文章来争论这一点，而是构建了 pgBackRest。他将自己的信念付诸代码，让社区来评判。

这是我所知道的最诚实的技术分歧形式。多年来，两个项目都蓬勃发展。竞争是真实的，架构差异是真实的，我相信每个项目都因为对方的存在而更加出色。我一直对 David 怀有深深的敬意，正是因为我理解他所做选择的严肃性以及维持这一选择需要付出什么。

结构性问题

但昨天的新闻并非真正关乎 David。它关乎开源软件中一个反复出现的、系统性的模式，这个问题没有得到足够的关注。

构建和维护一个关键的开源基础设施项目不是一个副业。它需要深厚的专业知识、持续的关注以及愿意处理那些只有生产部署才会暴露出来的边缘情况的耐心。它需要有能力拒绝错误的贡献，同时欢迎正确的贡献。这是一份全职工作，而全职工作需要收入。

当企业赞助消失，而社区赞助无法填补缺口时，维护者面临着一个不可能的选择：要么做得糟糕，要么停止。David 选择了后者。他不是第一个，也不会是最后一个。

开源并非免费。从长远来看，它是给世界的一份非凡的礼物。但必须有人为使其可靠的工作付费。Nadia Eghbal 早在 2016 年就在《Roads and Bridges》中详尽地记录了这种模式。自那以后，没有任何根本性的改变。

CloudNativePG 与结构性保护

在这里，我想直接对 CloudNativePG 的用户说几句话。

CloudNativePG 被 CNCF 沙箱接纳，不是架子上的一座奖杯。这是一个结构性的保证。这意味着 CloudNativePG 的治理、知识产权和持续性受到一个供应商中立、透明管理的基金会的保护——独立于任何单一公司、雇主或赞助者。即使 EDB 明天改变方向，这个项目也不能简单地被关闭或被掌控。无论背后的任何单一组织发生什么，软件始终保持开源。

CNCF 的成熟度阶梯在这里很重要。沙箱是入口点：治理被正式化，项目承诺遵守开源原则。孵化——我们正在努力的第二阶段——需要多个组织的采用证明。毕业，即最后阶段，是一个结构性的里程碑，确保没有任何单一组织能够挟持项目的未来：它需要一个健康且超出创始公司的贡献者和维护者基础。这是我们的目标，每一个在生产环境中运行 CloudNativePG 并与社区互动的采用者，都让我们更接近这个目标。

在我看来——我承认我在这里并非没有偏见的观察者——pgBackRest 尽管技术卓越，但是一个单人维护的项目，没有同等的结构性保护。CloudNativePG 则不是。如果你想亲自查看项目的健康状况和贡献者活动，Linux Foundation Insights 提供了一个开放的、实时的视图。这种透明度是供应商中立治理在实践中的一部分。

良性循环

结构性保护是必要的，但它不会自己写代码。

使开源真正可持续的模式——不仅是活着，而且在积极改进——是我所说的良性循环。事实上，这也是我在向客户介绍 CloudNativePG 时总是展示的图示。

开源可持续性的良性循环

一家公司投资于构建和维护开源软件的工程师；该软件为在生产环境中运行它的组织创造真实价值；这些组织从该公司购买商业支持和服务；该公司再投资于工程师。这个链条的每一个环节都必须保持。

我的大部分职业生涯都在实践这种模式。在 2ndQuadrant，在 Simon Riggs 独特的远见下，我们正是基于这一原则建立了一个世界级的 PostgreSQL 服务业务：一个由杰出工程师组成的小团队，由依赖他们所构建软件的组织提供资金。它之所以有效，是因为客户理解他们的支持合同不仅仅是购买访问服务台的权利——他们在资助编写软件并为所有人持续改进软件的人。

EDB 现在正将这一挑战带到另一个层面，规模大得多。如今，EDB 资助工程师全职工作在 PostgreSQL 本身、CloudNativePG、Barman、pgBouncer 以及更广泛的生态系统上。我想毫无保留地公开说：我深深感激 EDB 的领导层维持了这一承诺。这并非理所当然。当回报是分散的且时间线很长时，坚持投资上游开源需要真正的信念。付费客户和开源工程师之间的反馈循环是软件开发中最被低估的力量之一——这些客户关系带来了真正的问题，那些棘手的问题，是那些纯粹由志愿者驱动的项目很少能推动软件前进的那种问题。

如果你是一个 CloudNativePG 的用户，并且拥有 EDB 支持订阅，你就是这个循环的一部分。你的合同帮助维持了我和我的同事工程师，他们维护 CloudNativePG，为 PostgreSQL 上游做贡献，并修复影响整个社区的错误——而不仅仅是 EDB 的客户。这一点值得理解，也值得在续约时向你的采购团队解释。

EDB 将 CloudNativePG 贡献给 CNCF 的原因之一，正是为了鼓励其他供应商参与该项目，并通过他们自己的支持产品来维持他们的贡献。CloudNativePG 支持页面列出了今天为该项目提供商业支持的组织。它们每一个都是这个链条中的一环——每一个新加入的组织都让我们更接近在未来五年内达到 CNCF 毕业的愿望，拥有一个真正分布式的、没有单一公司控制的贡献者基础。

如果你还没有成为这个循环的一部分，我鼓励你考虑加入。不是作为对任何单一供应商的恩惠，而是因为你所依赖的项目，会因每一个选择妥善支持它的组织而变得更好。