开源 - Tony Bai

本文永久链接 – https://tonybai.com/2026/01/22/why-are-we-still-talking-about-containers-in-ai-age

大家好，我是Tony Bai。

“如果你在 2014 年告诉我，十年后我们还在讨论容器，我会觉得你疯了。但现在是 2025 年，我们依然在这里，谈论着同一个话题。”

在去年中旬举行的 ContainerDays Hamburg 2025 上，早已宣布“退休”的云原生传奇人物 Kelsey Hightower 发表了一场发人深省的主题演讲。在这个 AI 狂热席卷全球的时刻，他没有随波逐流地去谈论大模型，而是回过头来，向所有技术人抛出了一个灵魂拷问：

为什么我们总是在追逐下一个热点，却从来没有真正完成过手头的工作？

烂尾工程的诅咒——技术圈的“海啸”循环

Kelsey 首先回顾了他职业生涯中经历的三次技术浪潮：Linux 取代 Unix(AIX、Solaris等)、DevOps 的兴起、以及 Docker/Kubernetes 的容器革命。

他敏锐地指出，技术圈似乎陷入了一个无休止的“海啸循环”：

热点爆发：一个新的技术（如 Docker）出现，VC 资金涌入，所有人都在谈论它。
疯狂追逐：为了抢占市场，大家都只做“足够发布”的工作，追求速度而非完美。
未竟而散：还没等这项技术真正成熟、稳定、标准化，下一个热点（如 AI）就来了。于是，半数工程师跳船去追新热点，留下一地鸡毛。

“我们就像一群踢足球的孩子，看到球滚到哪里，所有人就一窝蜂地冲过去，连守门员都离开了球门。结果是，球门大开，后方空虚。”

这就是为什么 10 年过去了，我们还在谈论容器。因为我们当年并没有真正“完成”它。我们留下了无数的复杂性、不兼容和“企业级发行版”，却忘了初衷。

Apple 的“非性感”工作——这才是未来

在演讲中，Kelsey 分享了他最近的一个惊人发现：Apple 正在 macOS 中原生集成容器运行时。

这不是 Docker Desktop，也不是虚拟机套娃，而是操作系统级别的原生支持。这就是 GitHub 上的一个名为 apple/container 的 Apple 开源项目：

Kelsey 提到 contributors 中有 Docker 元老 Michael Crosby ，Michael Crosby 正在 Apple 做着这件“不性感”但极其重要的事情。

Kelsey 认为，这才是容器技术的终局：

标准化：容器运行时将成为像 TCP/IP 协议栈一样的操作系统标配，无论你是 Linux、macOS 还是 Windows。
隐形化：你不再需要安装 Docker，不再需要关心运行时。它就在那里，像水和电一样自然。
应用商店的重构：未来，App Store 分发的可能就是容器镜像，彻底解决依赖冲突和安全沙箱问题。

这正是那些没有去追逐 AI 热点，而是选择留在“球门”前的人，正在默默完成的伟大工程。

关于 AI——不要做“盲目的复制者”

作为 Google 前员工，Kelsey 对 AI 并不陌生。但他对当前的 LLM 热潮保持着清醒的警惕。

他现场演示了一个有趣的实验：询问一个本地运行的 LLM “FreeBSD Service Jails 需要什么版本？”
* AI 的回答：FreeBSD 13（一本正经的胡说八道）。
* 真相：FreeBSD 15（尚未发布）。

Kelsey 指出，现在的 AI 就像一个热心但糊涂的路人，它不懂装懂，只想取悦你。

他的建议是：

不要迷信生成：不要因为 AI 生成了代码就直接用，就像你不会盲目复制 Stack Overflow 的代码一样。
上下文为王：AI 不是魔法，它只是一个强大的搜索引擎。如果你想得到正确答案，你必须先给它提供正确的上下文（Context）。
先训练自己，再训练模型：在成为“提示词工程师”之前，先成为一名合格的工程师。只有当你自己深刻理解了问题，你才能判断 AI 的回答是天才还是垃圾。

给技术人的最后忠告

演讲的最后，Kelsey 回答了关于开源、职业发展和未来的提问。他的几条忠告，值得每一位技术人铭记：

关于职业：“你的职业生涯不应该是一场马拉松，而应该是一场接力赛。当你到达巅峰时，想的应该是如何把接力棒交给下一个人，而不是霸占着位置直到倒下。”
关于开源：“不要被商业公司的许可证游戏迷惑。如果代码是公开的，你可以 fork，可以学习。真正的开源精神在于分享和协作，而不在于谁拥有控制权。”
关于专注：像那家只做钳子的德国公司（Knipex）一样，专注做好一件事。技术圈不缺追风者，缺的是能够沉下心来，把一项技术打磨到极致、直到它变得“无聊”和“隐形”的工匠。

小结

Kelsey Hightower 的这场演讲，是对当前浮躁技术圈的一剂清醒剂。

他提醒我们，技术的真正价值，不在于它有多新、多热，而在于它是否真正解决了问题，是否被完整地交付了。在所有人都在谈论 AI 的今天，或许我们更应该关注那些被遗忘的“球门”，去完成那些尚未完成的伟大工程。

资料链接：https://www.youtube.com/watch?v=x1t2GPChhX8

你的“烂尾”故事

Kelsey 的“海啸循环”论断让人深思。在你的职业生涯中，是否也经历过这种“还没做完旧技术，就被迫去追新热点”的无奈？你认为在这个 AI 时代，我们该如何保持“工匠精神”？

欢迎在评论区分享你的经历或思考！让我们一起在喧嚣中寻找内心的宁静。

如果这篇文章让你停下来思考了片刻，别忘了点个【赞】和【在看】，并转发给那些还在焦虑中奔跑的同行！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/12/04/minio-enter-maintenance-mode

大家好，我是Tony Bai。

“这个项目目前处于维护状态，不接受新的更改。”

近日，GitHub 上拥有近 60k Star、Go 语言生态中最著名的开源对象存储项目——MinIO，悄然修改了其 README。这一行看似平淡的声明，标志着 MinIO 开源版实际上已经被宣判了“死刑”。

曾经，MinIO 是自建 S3 兼容存储的首选，是开源界的宠儿。如今，它转身拥抱了企业级市场和 AI 浪潮，留下了一脸错愕的社区用户和无数依赖它的开源项目。这究竟是一场无奈的求生，还是一次蓄谋已久的“收割”？

突如其来的“维护模式”

MinIO 官方在没有任何预警的情况下，将其开源仓库置于“维护模式”。这意味着：

功能冻结：不再接受任何新功能或改进。
社区关门：不再接受 Pull Request，现有的 Issue 和 PR 也不会被积极审查。
安全补丁随缘：关键的安全修复“可能”会根据具体情况进行评估，不再有保证。

官方建议很明确：“对于企业支持和积极维护的版本，请参阅MinIO AIStor。”，而AIStor则是MinIO的企业版对象存储产品。

这一举动在 Hacker News 上引发了轩然大波。用户感到被背叛，一位评论者愤怒地写道：“太恶心了。构建一个产品，通过开源获得动力，等你做完了就完全抛弃它。我为曾经推广这个项目感到羞耻。”

为何“背叛”？—— 商业化的必然与 AI 的诱惑

MinIO 的转向并非无迹可寻。从更换为更严格的 AGPL 协议，到此次事实上的闭源，其背后的逻辑清晰而冷酷：

开源无法变现的困境

MinIO 作为一个高性能、单二进制文件的存储服务，太容易“被集成”了。云厂商、集成商可以轻松地将其打包进自己的产品中获利，而 MinIO 公司却难以从中分一杯羹。AGPL 协议虽然意在限制云厂商的“白嫖”，但也未能从根本上解决其商业化难题。

AI 浪潮的巨大诱惑

MinIO 的新产品名为 AIStor。这不仅仅是一个改名，更是一次战略转型。在 AI 时代，数据存储是基础设施的核心。MinIO 试图通过重新包装，将自己定位为 AI 基础设施的关键组件，从而向更有付费能力的企业客户（尤其是 AI 公司）靠拢。

正如一位 HN 用户指出的：“他们在上一轮融资中估值 10 亿美元，要想成功退出，必须有深口袋的买家（如 Nvidia, Dell 等）。现在的开源版本只会拖累他们的财报。”

社区的反击与法律迷局

MinIO 的做法也引发了法律层面的争议。

贡献者的权利：MinIO 曾要求贡献者签署 CLA（贡献者许可协议）。这意味着 MinIO 公司拥有代码的版权，他们确实有权改变许可证或停止开源。
AGPL 的约束：但对于那些没有签署 CLA 的早期贡献者，或者包含在代码库中的第三方 AGPL 代码，MinIO 是否有权单方面“私有化”？这是一个复杂的法律问题。

更有趣的是，MinIO 过去曾因 AGPL 许可问题积极“维权”，甚至公开指责其他公司违反协议。如今，它自己却试图摆脱开源的束缚，这种双重标准让社区感到讽刺。

历史的镜像 —— Redis 与 Valkey 的启示

MinIO 的剧变，让人不由得想起了 2024 年初震动开源界的另一场“地震”——Redis 修改开源协议事件。

当时，Redis Inc. 宣布不再遵循开源定义，转而采用限制性更强的 SSPL 协议。这一举动激怒了整个社区和云厂商，Linux 基金会迅速集结了 AWS、Google、Oracle 等巨头，基于 Redis 旧版本 fork 出了 Valkey。如今，Valkey 已经展现出取代 Redis 的蓬勃生命力。

MinIO 与 Redis 的异同：

相同点：两者都面临“云厂商困境”。AWS 直接拿 Redis 做 ElastiCache，拿 MinIO 做兼容 S3 的服务，却无需向原厂付费。原厂为了生存，不得不通过协议（AGPL/SSPL）或停止维护来“筑墙”。
不同点：Redis 选择了“掀桌子”（改协议），引发了激烈的对抗和即时的 Fork（Valkey）；而 MinIO 选择了“冷处理”（维护模式），这更像是一种温水煮青蛙式的告别。

MinIO 会迎来它的“Valkey 时刻”吗？

目前来看，难。对象存储的复杂度和维护成本远高于内存缓存，且市场上已经存在成熟的替代品（如 SeaweedFS, Ceph, Garage）。MinIO 社区或许不会像 Redis 那样迅速集结出一个统一的 Fork，而是会走向分裂和迁徙。

对于开发者而言，Redis 和 MinIO 的连续“暴雷”是一个明确的信号：在基础设施选型时，除了关注技术指标，更要评估其背后的治理模式。由单一商业公司绝对控制的“开源”项目，始终悬着一把达摩克利斯之剑。

自救指南 —— 寻找 MinIO 的替代品

对于现有的 MinIO 用户来说，现在是时候寻找备胎了。社区推荐了几个值得关注的替代方案：

SeaweedFS (Go)

特点：基于 Haystack 论文实现，擅长处理海量小文件，自带 File 和 S3 接口。
适用场景：需要高性能小文件存储的场景。
评价：功能丰富，甚至有点“过度”，但性能强悍。

Ceph (C++)

特点：存储界的瑞士军刀，功能极其强大，但也极其复杂。
适用场景：大规模、生产级、需要块存储和文件存储的场景。
评价：如果你有运维团队，Ceph 是永远不会错的选择。

Versity Gateway (Go)

特点：基于文件的 S3 网关，可以在开发测试环境作为 MinIO 的直接替代品，后端直接对接文件系统。

RustFS (Rust)

特点：野心勃勃的新晋选手，试图在性能和易用性上直接对标甚至超越 MinIO。
适用场景：极客尝鲜、非生产环境的测试与评估。
评价：社区评价两极分化。一方面，它展现了强大的潜力；另一方面，用户反馈其目前稳定性欠佳，且项目要求签署 CLA（贡献者许可协议），这让不少刚被 MinIO 伤过心的开发者担心它未来会重演“养肥再杀”的剧本。“潜力巨大，但需谨慎观望。”

Garage (Rust)

特点：轻量级、自包含、专注于在异构硬件和地理分布的网络上运行。
适用场景：自托管、家庭实验室、中小规模集群。
评价：“非常稳固，简单可靠，没有风险投资背景。”

小结：开源的尽头是商业，还是背叛？

MinIO 的故事，是开源软件商业化困境的又一个注脚。它提醒我们：

没有免费的午餐：由 VC 支持的开源项目，最终都要面临盈利的压力。当增长遇到瓶颈，社区往往是被牺牲的第一个对象。
选择开源项目需谨慎：除了代码质量，项目的治理结构、CLA 协议、背后的商业模式，都是选型时必须考虑的风险因素。

MinIO 虽已“离去”，但开源精神不死。也许下一个更好的 MinIO，正在某个 GitHub 的角落里悄然生长。

资料链接：https://news.ycombinator.com/item?id=46136023