亲历MinIO被归档：我们如何Fork并重建了完整的社区版

MinIO 官方的开源仓库已在 GitHub 上正式归档，标志着原项目的终结。但开源的精神并未因此熄灭。通过 Fork 原代码、恢复被移除的管理控制台、并重建完整的二进制分发渠道，我们让 MinIO 得以在社区中浴火重生。

MinIO 的死亡证明

2025年12月3日，MinIO 在 GitHub 上宣布进入“维护模式”。彼时已有预警。

2026年2月12日，MinIO 在 GitHub 仓库首页将状态从“维护模式”更新为 “不再维护”，随后正式将仓库归档（Archived）。该仓库变为只读，不再接受 PR、Issue 或任何贡献。一个拥有六万 star、超过十亿次 Docker 拉取的项目，就此变成了一座数字墓碑。

如果说去年12月的公告是 临床死亡，那么今年2月的这次提交就是 正式开具了死亡证明。

随后，一篇题为《How MinIO went from open source darling to cautionary tale》的长文开始广泛传播，详细复盘了 MinIO 从开源宠儿到反面教材的完整时间线。

Percona 创始人 Peter Zaitsev 也在 LinkedIn 上表达了对此事的关注以及对开源基础设施可持续性的忧虑。国际社区的共识已然形成：MinIO 完了。

这不是简单的“停止更新”，而是 彻底的、不可逆的、由官方盖棺定论的终结。

回顾过去18个月的时间线，你会发现这并非一场意外，而是一场蓄意的、分阶段的自毁过程：

一家融资过亿、估值十亿美金的公司，花费数年时间，亲手将自己建立的开源生态一砖一瓦地拆除干净。

这比单纯的“跑路”更令人难受——因为“跑路”往往是一次性的，而 MinIO 选择了一种近乎“凌迟”的方式。

但开源不死

故事讲到这里，按常规剧本该以一声叹息收场，然后大家各奔东西。

但我想讲一个不一样的故事——这不是一篇悼词，而是一次复活宣言。

MinIO 公司可以归档一个 GitHub 仓库，但它无法归档 AGPL 协议赋予社区的合法权利。

颇具讽刺意味的是，AGPL 正是 MinIO 自己当年选择的许可证。他们从 Apache 2.0 转向 AGPL，本意是将其作为武器打击竞争对手。然而，AGPL 是一把双刃剑——同一份许可证，如今也保障了社区进行 Fork 的完全合法性。代码一旦以 AGPL 发布，其许可便不可撤销。你可以将仓库设为只读，但你收不回已经发出的自由。这恰恰体现了开源协议设计的深意：公司可以抛弃项目，但不能带走代码。

所以，结论是：MinIO 已死，但 MinIO 也可以复生。

不过，也别急着热血沸腾。Fork 按钮谁都会点，那只是一秒钟的事。真正关键的问题不在于“能不能 Fork”，而在于 有没有人能真正承担起维护责任，让它成为一个可靠的生产级组件。

为什么是我？

我本无意接手这个“摊子”。但观望了一两周，社区里并无他人明确表态愿意牵头维护。于是，我便决定自己动手。

简单介绍一下背景：我个人维护着整个 Pigsty 项目——这是一个全功能的 PostgreSQL 发行版，包含 451 个扩展，并支持 14 个 Linux 发行版的交叉构建。同时，我还维护着 270 多个 PG 扩展、数款 PostgreSQL Fork 以及几十款 Go 软件的全平台构建工作流。

我对 MinIO 也并不陌生。早在 2018 年，我们在探探内部就维护过一个 MinIO 的内部分支（当时它还采用 Apache 2.0 许可证），该分支支撑了约 25 PB 的数据，曾是国内最早、规模最大的 MinIO 部署之一。

更关键的是，MinIO 本身就是 Pigsty 中真实使用的组件。许多用户将其作为 PostgreSQL 的默认备份仓库，运行在生产环境中。因此，对我来说，这并非一个“要不要做”的选择题，而是 不做不行 的必答题。事实上，早在 2025 年 12 月 MinIO 宣布进入维护模式时，我就已经开始了相关工作。

我们具体做了什么？

截至目前，我们主要完成了三件核心工作。

1. 复活管理控制台

这是最让社区用户愤怒的改动之一。

2025年5月，MinIO 将完整的管理控制台（Admin Console）从社区版中移除，只留下了一个功能残缺的对象浏览器。用户管理、桶策略、权限配置、生命周期管理等核心管理功能一夜之间全部消失。想要？请购买企业版。

我们已经把完整的管理控制台恢复了。

讽刺的是，这甚至不需要任何复杂的逆向工程。你只需要将 minio/console 这个子模块的依赖版本号回退到改动之前的版本即可——本质上只是两行代码的修改。这意味着，MinIO 当初所做的，仅仅是修改了一个版本号，从而为用户关上了通往完整功能的大门。代码都在那里，他们只是把门锁上了。

他们拆掉了门窗，我们负责把它装回去。

2. 重建二进制分发渠道

2025年10月，MinIO 停止分发预编译的二进制文件和官方的 Docker 镜像，只提供源代码。他们的建议是：“请用 go install 自己编译”。

对于绝大多数用户而言，开源软件的价值远不止于一份源代码副本——供应链的稳定性和可用性才是命脉。用户需要的是一个可以写入 Dockerfile、放进 Ansible Playbook、或集成到 CI/CD 流水线中的稳定制品，而不是在每次部署前都要先搭建 Go 编译环境。

我们已经重建了完整的分发渠道：

• Docker 镜像 : pgsty/minio 已上线 Docker Hub，直接使用 docker pull pgsty/minio 即可获取。
• RPM / DEB 包 : 我们为主流 Linux 发行版构建了与原版规格一致的安装包。
• CI/CD Pipeline : 在 GitHub 上建立了全自动化的构建流程，确保供应链的持续稳定。

如果你原本使用 Docker 镜像，现在只需将 minio/minio 简单替换为 pgsty/minio 即可。

偏好原生 Linux 安装的用户，可以直接从 GitHub Release 页面下载 RPM/DEB 包。也可以通过 Pigsty 的包管理工具 pig 便捷安装（该工具也便于免翻墙获取资源）。当然，你也可以配置启用 pigsty-infra 的 APT/DNF 软件仓库来进行安装。

curl https://repo.pigsty.cc/pig | bash;
pig repo set; pig install minio

一切使用体验将尽可能与之前保持一致。

3. 维护社区版本文档

MinIO 的官方文档站点同样面临风险——其内容可能逐渐转向推广其商业产品 AIStor。

因此，我们 Fork 了 minio/docs 仓库，修复了已失效的链接，并恢复了那些被删除的、关于管理控制台的文档。新的文档站点部署在：https://minio.pigsty.io

该文档采用与原版相同的 Creative Commons Attribution 4.0 国际许可协议，完整保留了所有技术内容，并将持续进行必要的维护与更新。

我们的承诺与原则

有些话需要提前说明，以避免不必要的误解。

我们不做新特性，只保障供应链

MinIO 作为一个高度兼容 S3 API 的对象存储，其核心功能已经相当完善。它是一个 已经完成的软件，当前最需要的不是添加花哨的新功能，而是一个稳定可靠、持续可用的版本。

我们的核心工作就是：确保你随时能获取到一个功能完整、包含管理界面、可直接投入使用的 MinIO 二进制制品。无论是 RPM、DEB 包还是 Docker 镜像，都通过 CI/CD 流水线自动构建，力求与你现有的基础设施无缝对接。你不必担心某天 docker pull 失败，也不必担心 yum install 找不到软件包。

前提是 MinIO 公司不动用商标武器来追究。如果他们追究，我们则需配合更名。

这是真实使用的版本，不是一个归档备份

或许有人会认为：这不过又是一个代码的 Fork 备份罢了？

并非如此。MinIO 在 Pigsty 中是真实被依赖和使用的核心组件，许多用户正将其作为 PostgreSQL 备份仓库运行在生产环境。我们自身使用的正是自己构建的版本——如果出现问题，我们会第一时间发现并修复。这个由我们构建的版本，已经在我们的生产环境中稳定运行了数月。“吃自己的狗粮”，这是最好的质量保证。

我们会修复 Bug，并跟进安全更新

如果你在使用中遇到问题，欢迎在项目仓库提交反馈。如果是我们构建的版本中可复现的问题，我们将尽力修复。对于安全漏洞（CVE），我们同样会积极跟进并发布修补版本——但请注意，这并非商业 SLA 承诺。我们会以开源社区的方式，尽最大努力进行维护。

商标问题：走一步看一步

商标声明：MinIO® 是 MinIO, Inc. 的注册商标。本项目（pgsty/minio）为社区独立维护的 AGPL 开源 Fork，与 MinIO, Inc. 无任何关联、从属或背书关系。本文中对 “MinIO” 的使用仅用于指代该开源软件项目本身，不暗示任何商业关联。

AGPLv3 许可证允许我们合法地 Fork 和分发代码，但商标法是另一个领域。虽然我们已在所有显著位置明确标注这是一个独立的社区维护版本，但 MinIO 公司仍可能以商标侵权为由提出异议。

如果收到正式的商标异议，我们会配合进行更名（可能更名为 silo、stow 之类的名称）。但在此之前，我们认为在 AGPL Fork 中为指代原项目而描述性地使用其名称是合理的。毕竟，我们也不希望用户面对大量需要重命名配置的麻烦。

AI 改变了维护的经济学

或许有人会问：一个人真的能维护得了这样一个项目吗？

现在是2026年，情况与五年前已大不相同。AI 编码工具正在深刻改变开源维护的成本结构。

在一个有经验的开发者手中，借助 Claude Code 等 AI 工具的辅助，定位和修复一个复杂 Go 项目中的 Bug，其效率已提升数个数量级。过去维护一个复杂基础设施项目可能需要一个专业团队，而现在，“一个经验丰富的开发者 + AI” 的模式已具备可行性。要知道，马斯克曾将 X（原推特）这种量级系统的工程团队精简到30人。相比之下，维护 MinIO 这样一个功能稳定的项目，挑战并没有想象中那么大。

既然看到了需求，又具备相应能力，那就自己上。

Just Fork it!

MinIO 公司可以归档一个 GitHub 仓库，但它无法归档那六万颗 Star 背后所代表的庞大需求，更无法抹去那十亿次 Docker Pull 所意味的深度依赖。这些需求不会消失，它们只会寻找新的出口。

历史已有先例：HashiCorp 将 Terraform 许可证改为 BSL 后，社区便 Fork 出了 OpenTofu，并且发展良好。MinIO 的情况其实更为有利——AGPL 比 BSL 对社区更为友好，进行 Fork 几乎不存在法律风险。公司可以决定抛弃一个项目，但开源协议的设计初衷，就是为了防止代码随着公司的决策而“死掉”。

git clone 是开源世界最强大的魔法。当一家公司决定关上门时，社区只需要两个词作为回应：

Fork it.