MinIO开源项目宣布进入维护模式，商业化转型引发社区争议

作为一个在GitHub上获得接近60,000颗星的知名开源项目，高性能分布式对象存储服务MinIO在12月3日突然调整了其开源政策，宣布项目进入“维护模式”：该代码库未来只会进行维护性更新，不再提供新功能或改进，现有的Issue和Pull Request将不再被主动处理。

这一消息让许多人感到意外，瞬间在社区中引发了各种反响。

有人表示理解，有人困惑，有人批评，甚至有社区论坛直接判定“MinIO已死”，创建了「RIP MinIO」的帖子来表达不满。

那么，这个在许多对象存储场景中仍然被广泛使用的项目，为何会做出这样的决定？让我们深入探讨。

一个下载量突破10亿次的开源项目成长历程

对于MinIO，许多技术从业者都见证了它的发展，并曾使用过它。

MinIO最初于2014年成立，由Anand Babu Periasamy、Garima Kapoor和Harshavardhana等人共同创立，最初目标是满足私有云和混合云环境对高性能对象存储的需求。

在那个时期，企业云存储需求迅速增长，AWS S3成为事实上的标准，但许多企业希望在本地或私有云环境中使用类似S3的对象存储。MinIO正是在这种背景下诞生的。

MinIO团队选择使用Go语言开发，将其设计为轻量级、高性能，并与Amazon S3 API完全兼容的对象存储服务。这样，依赖S3的应用程序或基础设施可以更容易地迁移到自建环境或私有云中。

同时，MinIO从一开始就采用Apache License 2.0开源协议，方便开发者和企业自由使用。因此，它迅速在开发者社区和企业用户中流行起来。

数据显示，MinIO在开源社区中表现活跃：它拥有超过1,400个依赖包，在GitHub上获得了约58.9K星标和6.5K Fork。在Docker Hub上，MinIO镜像下载量已超过10亿次。就国内市场而言，此前有统计显示，MinIO被阿里巴巴、腾讯、百度、中国联通、华为、中国移动等超过9,000家企业采用，尤其在构建私有云存储、混合云存储和分布式存储方面展现出显著优势。

MinIO此前的三次重大变更

然而最近，MinIO的“思路”逐渐转变，导致其后续动作频繁，先后变更了项目的开源协议、删除了开源版本中的部分功能，以及停止了社区版二进制分发，逐渐偏离开源理念，并向商业化战略靠拢。

一变开源协议：从Apache 2.0改为AGPLv3，理由：避免“白嫖党”

如上文所述，MinIO原本采用Apache 2.0协议，允许用户自由使用、修改和再发布。

2019年，MinIO决定将开源协议改为AGPLv3，要求使用者在提供服务时必须开放自己的源代码。

这样做的原因是，随着项目受欢迎程度提升，部分大公司可能直接使用MinIO提供商业SaaS或云服务，而几乎不回馈社区，这给MinIO的维护方带来了巨大资源压力。MinIO变更协议，旨在保护项目利益和社区贡献。

在争议中，MinIO最终在2021年完成了协议变更。

二变功能范围：删除开源版部分功能，迁移到商业版本中

今年5月，MinIO团队再次“出手”。他们在当时的Minio CE版本中移除了控制台管理功能，理由仍然是：一方面降低免费版本的维护成本，二是推动企业版商业化，让开发团队能更专注于核心存储功能和性能优化。

当时，社区版用户仍可通过源码自行构建控制台或使用第三方工具，但官方不再提供现成的管理界面。

三变开源支持范围：停止社区版二进制分发

时间来到今年10月，我们之前也报道过，MinIO官方作出了“停止分发免费的Docker镜像”的决定。

当时，官方在MinIO GitHub项目的README中写道：

仅源码分发

重要提示：MinIO社区版现在仅以源码形式分发。我们将不再提供社区版的预编译二进制版本。

安装最新版MinIO社区版

使用MinIO社区版有两种方式：

1. 从源码安装（推荐）：go install github.com/minio/minio@latest

2. 使用提供的Dockerfile构建Docker镜像

旧版二进制发布

历史的预编译二进制版本仍可作为参考使用，但不再维护：

• GitHub Releases: https://github.com/minio/minio/releases
• 直接下载: https://dl.min.io/server/minio/release/

这些旧版二进制不会再收到更新。我们强烈建议使用源码构建，以获得最新功能、漏洞修复和安全更新。

MinIO宣布进入“维护模式”：这意味着什么？

如今，这算是MinIO第四次也是最后一次对开源项目发展方向进行调整，直接进入了“维护模式”。

在传统开源项目中，“维护模式”指的是开发重心从持续推出新功能，转向确保现有功能稳定和可靠。

一个开源项目进入「维护模式」，通常有多层原因：

1. 项目成熟：功能稳定，已能满足大部分用户需求。
2. 开发者资源有限：原作者或核心团队希望减少工作量，或将精力投入到新项目。
3. 生态被替代：新技术或框架出现，原项目不再是首选，但仍有少部分用户在使用。
4. 战略选择：避免频繁更新带来的不稳定风险。

那么MinIO进入「维护模式」属于哪一种情况？

在GitHub上，MinIO官方给出了明确说明——

该项目目前处于维护状态，不再接受新的更改：

• 代码库仅进行维护性更新
• 不会接收新的功能、增强或Pull Request
• 关键的安全修复可能会根据具体情况进行评估
• 现有的issue和Pull Request将不再被主动处理
• 社区支持将通过Slack以尽力而为的方式继续提供

如需企业级支持和仍在积极维护的版本，请查看MinIO AIStor

其中最后一句成为许多人关注的焦点，这也让公众意识到，一切都在向商业化方向靠拢。

简单来说，MinIO AIStor是商业/企业级版本，需要订阅服务。每年费用为96,000美元，可管理400TB数据。

开源与商业的博弈

归根结底，这是开源与商业可持续性之间长期存在的矛盾。

对于MinIO官方的操作，许多人并不感到意外：

不过，这几乎为MinIO 11年的开源生涯画上了句号：

对此，行业从业者的看法大致分为三派，有人理解MinIO的选择，认为应心怀感激：

对于免费的开源项目，你首先要明白：有人花费时间和精力为你提供软件，却不求回报，你就应该心怀感激。你不应该感到“心里不舒服”或有怨言。如果希望项目能够持续发展，就应该投入自己的时间或金钱去支持它。

也有开发者持批评态度：

• Linux基金会版的Fork很快就会出现。MinIO可能会在1到2年内回归开源，但那时已经太晚：社区会继续前进，不会再回头，他们的声誉也将永久受损。
• Richard Stallman（自由软件之父）当年说得没错。开发者社区到底什么时候才能吸取教训，不要再为这些带有糟糕CLA的项目贡献代码？这次就是被人“抽梯子”了。

还有用户愤怒抨击：“真是好大一出戏。把你商业产品背后的开源项目（许多人为其贡献过）直接EOL（终止支持），然后把它变成一个闭源的MinIO AIStor……说真的，这也太离谱了吧……”

更有开发者从法律角度提出质疑：

• “我没有向MinIO贡献过代码，但如果他们在没有让外部贡献者签署CLA的情况下接受了外部贡献，那么在更改许可证之前，必须征得每位外部贡献者对许可证变更的同意。既然是AGPL，他们仍然必须在某处提供源代码。”
• “有人知道MinIO AIStor的法律状况是否合规吗？据我所知，MinIO并没有采用CLA（贡献者许可协议），而在Git提交历史中有559名邮箱非@minio.io的提交作者。如果他们在更改许可证时没有获得这些贡献者的授权，那可能会构成AGPL的违规。或者，AIStor是一个从零重新编写的全新代码库？”

与此同时，也有人开始推荐替代方案，为当前用户提供更多选择。

「非常感谢MinIO、RustFS和Garage的贡献。话虽如此，MinIO如此突然地关闭开源大门，确实让社区受到了惊吓。但说实话，这也情有可原——开源项目最终都需要找到商业化路径。

我分别评估过RustFS和Garage，情况大致如下：

• 发布节奏：Garage的更新节奏稍慢，而RustFS几乎是每周都有更新。
• 许可证：Garage使用AGPLv3，而RustFS采用Apache许可证（这一点对企业采纳来说非常关键）。
• 稳定性：在分布式环境中，目前Garage略胜一筹。

随着MinIO基本退出开源竞争，我更看好RustFS能后来居上。」

最终，MinIO的操作也让许多人对开源的信任产生了动摇——当曾经免费、开放的项目开始商业化，我们还能像从前那样放心依赖吗？

参考：

https://github.com/minio/minio

https://www.reddit.com/r/selfhosted/comments/1pd97nq/minio_is_in_maintenance_mode_and_is_no_longer/

https://news.ycombinator.com/item?id=46136023