ハクソク

世界を動かす技術を、日本語で。

MinIOは死んだ、万歳MinIO

51日前原文(blog.vonng.com)

概要

  • MinIOの公式リポジトリがアーカイブされ、メンテナンス終了
  • pgsty/minioとしてフォークされ、管理コンソールやバイナリ配布が復活
  • AGPLライセンスのもと、コミュニティによる存続が可能
  • 新機能追加は行わず、安定供給とCVE修正に注力
  • 今後もユーザー主導でオープンソースの精神が継続

MinIO公式リポジトリの終焉とその経緯

  • 2025年12月3日、MinIOがGitHub上でメンテナンスモードを発表、終焉の兆し
  • 2026年2月12日、リポジトリは「メンテナンス終了」となりアーカイブ、以降は読み取り専用
  • 60,000スターと10億回以上のDockerプルを誇ったプロジェクトがデジタル墓標化
  • 2021年以降、ライセンス変更・法的措置・機能制限・配布停止など段階的な縮小
    • Apache 2.0 → AGPL v3へのライセンス変更
    • NutanixやWekaへの法的措置
    • 2025年5月、CE版から管理コンソール削除
    • 2025年10月、バイナリ・Docker配布停止
    • 2025年12月、メンテナンスモード宣言
    • 2026年2月、リポジトリアーカイブ
  • 5年間かけてオープンソース・エコシステムを段階的に解体

オープンソースは死なない

  • AGPLライセンスの不可逆性により、コミュニティのフォーク権利は保証
  • MinIO Inc.がリポジトリをアーカイブしても、ソースコード自体は消滅しない
  • 「フォークは簡単、維持こそが本当の挑戦」
  • pgsty/minioとしてフォークし、管理コンソールやバイナリ配布を復活
  • 供給の継続性確保のため、独自にCVE修正済みバイナリを作成・運用

pgsty/minioで実施したこと

  • 1. 管理コンソールの復活
    • 2025年5月にCE版から削除されたフル機能の管理コンソールを復元
    • 単純にsubmoduleのバージョンを戻すことで実現
  • 2. バイナリ配布パイプラインの再構築
    • Docker Hubでpgsty/minioイメージを配信
    • 主要Linuxディストリ向けRPM/DEBパッケージを提供
    • GitHub ActionsでCI/CD自動化、供給安定性を担保
    • pig（PG拡張パッケージマネージャ）やpigsty-infraリポジトリ経由で簡単インストール
  • 3. コミュニティエディションのドキュメント復元
    • minio/docsをフォーク、リンク修正や削除されたコンソールドキュメントを復元
    • CC Attribution 4.0ライセンスで公開

コミットメントと運用方針

  • 新機能追加なし、安定供給に専念
    • S3互換オブジェクトストアとして機能的に完成済み
    • バイナリ・管理コンソール・CVE修正を含む安定ビルドの継続提供
  • アーカイブではなく実運用ビルド
    • 自身のPigstyや本番環境で実際に運用、問題があれば即時修正
  • CVE対応・バグ修正も継続
    • GitHub Issuesで報告受付、商用SLAではないができる限り対応
  • 商標問題には柔軟対応
    • MinIO®はMinIO, Inc.の登録商標
    • 商標問題が発生した場合は名称変更も検討（例：silo, stow等）

AI時代のオープンソース保守

  • AIコーディングツールの進化で保守コスト大幅削減
    • Claude CodeやCodex等の活用でバグ修正効率向上
    • 新機能追加せず、テストとバリデーション重視の運用が現実的
  • 大規模チーム不要、一人とAIで十分な時代
    • 本番運用で互換性・信頼性・セキュリティ検証が可能

オープンソースの「フォーク」の力

  • 企業がプロジェクトを終了しても、コミュニティの需要は消えない
  • AGPLはフォークに寛容、法的グレーゾーンなし
  • Terraform→OpenTofuのように、MinIOもコミュニティ主導で再生可能
  • 「Fork it」——オープンソース最大の武器

参考資料

  • MinIO Is Dead
  • MinIO Is Dead, Are There Alternatives?
  • From AGPL to Apache: Reflections on Pigsty’s License Change

免責事項

  • 本記事はClaudeによるzh-cnからの翻訳・編集版
  • pgsty/minioはMinIO, Inc.とは無関係の独立コミュニティフォーク
  • 商標等の権利関係には十分配慮の上、必要に応じて対応予定

Hackerたちの意見

みんながこれを取り上げてるのはいいことだし、オープンソースの大きな利点の一つだよね。ただ、一人の人間だけで成功するかはちょっと疑問だけど、こうやって新しい命を吹き込むことができるかもしれないし、世界に価値を加えようとする人を止めるつもりはないよ。でも、最近はAIが生成した記事にはすごく嫌悪感を抱いてる。長くて読むのが面倒だし、そこに書いてあることが本当に真実なのか疑わしくなっちゃう。もっと下手でも要点を押さえた記事の方が好きだな。
└
完全に同意だね。みんなAIの批判には疲れてるけど、この文章にはLLMが何度も書いたっていう明らかな兆候がある。メンテナーがAIに作業をさせないと発表すらできないのは、プロジェクトの未来にとって良くないよね。高い努力で慎重に維持されるフォークに変わるといいけど、今のところAIを多用するメンテナーからの新しいフォークにはかなり懐疑的だよ。
└
作者が発表文を書くことすらしなかったのに、そのフォークがしっかりメンテされているとは信じられないよ。
└
> そこに書かれていることが本当に真実なのか疑わしいよね。 確かに、「皮肉なことに、Apache 2.0からAGPLに切り替えるとプロジェクトがフォーク可能になる」という部分は誤解を招くね。Apache 2.0ライセンスのソフトウェアも同じようにフォーク可能だよ。
もしかしたら、著者はChainguardがMinIOのCVEをずっとパッチ当て続けることを知らないのかもね。 https://www.chainguard.dev/unchained/secure-and-free-minio-c... この記事の他の変更（例えば、管理コンソールの復元）は反映されないけど、それはちょっと別の話だね。
└
たぶん、統合できると思うよ。
Chainguardがしばらくの間フォークを維持していて、こういうフォークをサポートしてきた歴史があるってことを言っておくよ。 https://github.com/chainguard-forks/minio ウェブGUIについては、このプロジェクトを使ってたんだ。 https://github.com/huncrys/minio-console でも今週からrustfsに切り替えたから、もう戻る気はないかな。小規模な使用にはおすすめだよ。急速に成長していて、期待できそう。
└
rustfsのセキュリティ姿勢はちょっと怪しいから注意してね。いい例として、https://github.com/rustfs/rustfs/security/advisories/GHSA-h9...を見てみて（ハードコーディングされた静的トークンがあるよ）。
└
READMEが更新されてないみたいだけど、今使える更新されたDockerイメージはあるのかな？ 編集: https://hub.docker.com/r/pgsty/minio OPのリンクから
> MinIOはS3互換のオブジェクトストレージとして、すでに機能が完璧なんだ。完成したソフトウェアだよ。これらの二行が一緒に書かれる理由がわからない。目標はS3互換のままでいるか、サービスの現在のインターフェースを永遠に凍結することだ。今のままだと、このフォークのS3との互換性、そして公式のMinIO自体との互換性は、どちらかがAPIのアップデートを押し進めると壊れちゃう。既存のユーザーには問題ないかもしれないけど、時間が経つにつれてプロジェクトがどんどん離れていくと、新しいユーザーは参加できなくなるだろうね。
└
S3 APIはかなり安定していて、ほとんどの新機能はオプトイン（例えば、ApplyIfModified）か補助的（例えば、S3Tables）だよ。将来的なAPIの変更でS3がクライアントとの後方互換性を壊す可能性は非常に低いと思う。だから、既存のS3クライアントと連携する基本的なオブジェクトストレージが必要なだけなら、MinIOで十分だよ。このフォークはCVEをパッチ当て続けて、コミュニティの衛生を維持する必要がある（小さなバグ修正のための新しいPRを受け入れるとかね）。著者が指摘しているように、これはAIの時代では以前よりもずっと簡単になってる。
あと、Garage S3も見てみてね。 https://garagehq.deuxfleurs.fr/
└
Garageに移ったけど、実際に使うのは結構簡単だよ。公式のDockerイメージが環境変数からデフォルトのバケットとアクセスキーを初期化できるようになったらもっと良いんだけど、コンテナに入ってhttps://garagehq.deuxfleurs.fr/documentation/quick-start/に従う必要があるのはちょっと面倒だね。でも、致命的ではないよ。ちなみに、私はシングルノードのインストールだけが必要だったから、これかSeaweedFSのどちらかだった。過去にはMinIOやZenkoも使ったけど、後者はほぼ死んでるみたいだね。
真剣に（マルチノード）で使うなら、MinIOよりCephを使う理由がわからなかったな。確かに最初の設定は簡単かもしれないけど、Cephの方がうまくいく可能性が高いと思う。シングルノードのユースケースについては、 https://github.com/uroni/hs5 に取り組んでるよ。S3 APIの範囲は広いけど、今のところ基本的な部分はカバーしてる。目標を絞ることで、維持可能になることを願ってる。
それよりもseaweedfsや他の選択肢に貢献してほしいな！ ローカルでホストされるS3には他にもたくさんの選択肢があるし、minioはもう長い間ベストな選択肢じゃないよ。入門記事や例では一番使われてたかもしれないけど、もっと良い選択肢があったからね。
ここでの作者です。 • これは私の元の中国語の投稿から翻訳したものです。英語を磨くためにClaudeを使いましたが、ネイティブスピーカーではありません。LLM風の批判は公平です；もっと引き締めます。 • このフォークは、MinIOが私のPGディストリビューション（Pigsty）のプロダクション依存関係だから存在しています。動作するバイナリとCVEパッチが必要でした。主に自分のために使っていて、他の人も同じ問題を抱えているかもしれないから共有しています。 • われわれは意図的に保守的です — 新しい機能はなし、最後のOSSリリースのように振る舞うドロップイン置き換えです。コンソールも復元しています。初期のコミットは薄く見えるかもしれません。
> 一度AGPLの下でコードがリリースされると、ライセンスは取り消せません。リポジトリを読み取り専用に設定することはできますが、与えられたライセンスを取り戻すことはできません。 > これがオープンソースライセンスの設計上の美しさです：企業はプロジェクトを放棄できますが、コードを持ち去ることはできません。これは無料のライセンスで、単なるオープンソースではありません。オープンソースにプラスアルファです。
作者がAGPLの再ライセンスや施行をプロジェクトが死にかけてる証拠みたいに扱ってるのがマジで嫌だな。AGPLはFOSSプロジェクトには全然問題ないライセンスだし、ライセンスの施行は健全なプロジェクトには必須だよ。彼が言いたいことは分かるけど、機能を削ったり、全体的に縮小してるのと同じカテゴリーに入れるのは…なんか違う気がする。プロジェクトを救おうとするのを「死にかけてる」って言うのはおかしいよね。とはいえ、復活おめでとう！[1]: 大手テックが触りたがらないのはライセンスのせいじゃなくて、大手テックの問題だからね！
└
後期の再ライセンスは、前のライセンスのユーザーコミュニティにとっては常に rug pull のように感じるんだろうね。