MinIOリポジトリは今後メンテナンスされない

 (github.com/minio)
2 ポイント 投稿者 GN⁺ 2026-02-14 | 1件のコメント | WhatsAppで共有
  • README.md が修正され、プロジェクトが 今後メンテナンスされない ことが明記された
  • 従来の「メンテナンスモード」という文言が削除され、代わりに THIS REPOSITORY IS NO LONGER MAINTAINED という警告が追加された
  • README の冒頭に AIStor Free と AIStor Enterprise の2つの代替オプションが提示された
  • ドキュメント内のリンク不備が修正され、Slack チャンネルの URL も正しく訂正された
  • この変更により、MinIO のオープンソースリポジトリが 読み取り専用のアーカイブ状態 に移行したことが確認された

README.md の主な変更点

  • 既存の「Maintenance Mode」セクションが完全に削除され、新しい注釈ブロック に置き換えられた

    • 新しいブロックには「THIS REPOSITORY IS NO LONGER MAINTAINED」という文言が含まれる
    • 「Alternatives」項目の下に、2つの代替製品が明記された
      • AIStor Free: コミュニティ向けの無料スタンドアロン版
      • AIStor Enterprise: 商用サポートを含むディストリビューション版

  • 既存ドキュメントの AIStor 関連サブスクリプション案内リンク が削除され、簡潔な代替説明に整理された

その他の修正と整理

  • Slack リンク が誤っていた https//slack.min.io から https://slack.min.io に修正された
  • 環境変数の例 のタイプミス（GOARCh）が GOARCH に修正された
  • AGPLv3 ライセンス文言 のスペルミス（liabilites）が liabilities に修正された
  • 「Legacy Binary Releases」セクションに空行が1行追加され、可読性が改善された

リポジトリの状態

  • GitHub ページ上部には「This repository was archived by the owner on Feb 13, 2026. It is now read-only.」という文言が表示される
  • これは、リポジトリが アーカイブ処理され、今後は変更やコントリビュートができない状態 であることを意味する

意味

  • README の修正とともに、リポジトリは公式に メンテナンス終了およびアーカイブ状態 へ移行した
  • MinIO オープンソース版の代わりに、AIStor Free / Enterprise 製品群への移行が案内されている
  • コミュニティサポートは引き続き GitHub と Slack を通じて ベストエフォート方式 で提供される

関連記事

1件のコメント

 
GN⁺ 2026-02-14
Hacker Newsのコメント

  • MinIOがオープンソースをやめたこと自体には問題はないと思う
    世界的に見ても、無料でしか使わない人たちが多すぎる
    数か月前から代替を試してきたが、MinIOの次はRustFSが勝者になると思う
    Garage、SeaweedFS、Ceph、RustFSを比較したが、RustFSとSeaweedFSが最も速く、RustFSは導入とコンソールが最も使いやすかった
    Cephは複雑すぎて、ソースコードを深く理解していないとデプロイが難しい
    RustFSのCLAが「おとり」だという批判もあるが、法的リスクを減らすための仕組みとしては過剰ではないと思う
    MilvusでもRustFSを高く評価しており、技術指標で見れば最終的にRustFSが勝つと信じている
    MilvusによるRustFS評価記事

    • Milvusのメンテナーとして、いくつか考えを共有したい
      無料ユーザーの問題は実際に存在し、AI時代にはさらに深刻になっている
      多くのユーザーがプロジェクトを無料で使う一方で、有料顧客に転換する割合は非常に低い
      Milvusは安定性と性能のため、より良いオブジェクトストレージを必要としており、RustFSは有力候補だ
      ただし長期的に見てエコシステムがこれを満たせないなら、自前構築も検討すべきだ
      オープンソースのライセンスモデルについて持続可能性の議論が必要だ
      Apache 2.0時代のモデルには限界が見え始めており、単に「企業が支援してくれることを期待する」やり方はもはや通用しない
      MinIOの決定は、こうした変化のシグナルとして注目に値する
    • 私はCephをk8sクラスターで運用しており、4ノードに4TB SSDを2台ずつ構成している
      設定は複雑だったが、今は非常に安定している
      Claude CodeはCeph管理に非常に優れており、復旧やCRUSHマップの修正も簡単にこなせる
      「ソースコードを深く理解していないとデプロイできない」というのは大げさだと思う
      Cephが用途に合うなら、ぜひ試してほしい
    • Garageの導入はとても簡単だ
      単一バイナリをインストールして、設定ファイル /etc/garage.toml を書くだけでよい
      garage server で起動するか、AIにinitスクリプトを書かせることもできる
      NVIDIAのAIStoreも優れたS3互換システムで、AIStore公式サイトで確認できる
      MinIOより速いが、空間効率はやや劣る
      SeaweedFSは個人プロジェクト色が強く、頻繁にバックアップしないと危険だ
      RustFSはCLAの問題から、MinIO騒動の再現になりそうで避けたい
    • SeaweedFSはFacebookのHaystack設計に基づいており、メタデータ参照を最小化する特定目的向けになっている
      ボリューム単位で動作し、更新もボリューム単位で行われる
      一方、一般的なオブジェクトストレージは分析バックエンドとしても使われるため、高速スキャンが必要になる
      そのためSeaweedFSは、汎用オブジェクトストレージとは異なるトレードオフを持つ
    • RustFSのCLAが法的リスクを減らすと言っていたが、具体的にどんな法的リスクを減らすのか気になる

  • オープンソースサービスを運営してやめたとき、慢性的な疲弊感が消えた
    無料で働くのは楽しくなかったし、有料版とコミュニティ版を並行して維持するのも大変だった
    お金を払わないユーザーとの関係は、結局ストレスだった
    MinIOチームも同じ教訓を得たのだと思う

    • MinIOチームは無料で働いていたわけではない
      COSS(Commercial Open Source Software) モデルで、基本版を無料提供し、企業顧客には有料機能を販売していた
      クローズドソースへの移行は、単なるビジネス判断だ
      私はSeaweedFSを長年プロダクションで使っており、今はWasabiと併用している
      SeaweedFSは今でも高速なローカルストレージ用途には優れている
    • 製品に対価を求めるのは当然だが、最初はFOSSだと宣伝しておいて後からライセンス変更するのは問題だと思う
      最初から計画を明確にしておくべきだった
      そうでないなら、既存の約束を守るのが正しい
    • 私はオープンソースのストレージシステムを何年も維持しているが、今でも楽しんでやっている
      TidesDBというストレージエンジンを管理しており、腰が痛くても好きだから続けている
    • 人気のあるオープンソースプロジェクトを金儲けのために作るのなら、オープンソースの精神をちゃんと理解していないということだ
    • 30年近く自由ソフトウェアに関わってきたが、コミュニティと一緒に働く経験はとてもやりがいがあった
      こうした経験は主観的なものだが、確かに楽しいものになりうる

  • MinIOからCephへの移行に成功した
    SeaweedFSも試したが、Claudeの助けを借りてバグを解析した結果、コード構造がひどかった
    SeaweedFSはテスト以外では絶対に使うべきではない。データ損失のリスクが大きい

    • SeaweedFSは古いプロジェクトなので、単にレガシーコードベースの痕跡を見ただけかもしれない
    • Cephはオブジェクトストレージの元祖(OG) だ
      いくつもの代替の試みがあったが、結局Cephが問題の複雑さを最もうまく解いている

  • 最近MinIOをCephへ移行中だ
    3台のサーバーで構成したCephクラスターをcephadmで構築し、120TBのデータを420MB/sで複製している
    CephはMinIOより複雑だが、スケーラビリティに優れ、安定している
    MinIOのコンソールがなくなったのは残念だ
    ElasticsearchがGarageのS3スナップショットを嫌うため、Cephを選んだ

    • Cephは複雑だが、コンセンサス層が非常に堅牢だ
      ただし、ノードのディスクがいっぱいにならないよう注意すべきだ

  • 多くの人が、まだ本番運用で実証されていない代替を急いで試しているのが印象的だ
    インフラ依存の本当のリスクは、クローズドソースであることではなく乗り換えコストだ
    S3互換でも、実際の移行には微妙な違いのせいで数週間から数か月かかる
    MinIOユーザーのうち、実際に移行計画を文書化しているところがどれだけあるのか気になる

  • MinIOの代替としてAIStoreが挙げられている
    そのほかにも複数のオープンソース代替がある:
    Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph

    • 私はFilestashの作者だ
      S3ゲートウェイを提供しており、S3呼び出しをSFTP、FTP、NFS、SMB、IPFS、Dropbox、Google Driveなどへプロキシする
      完全にstatelessで、さまざまなバックエンドに接続できる
    • RustFSは機能が豊富で、独自のキー管理も可能だが、まだ開発途中だ
      コード内にはすでにライセンス転換のための準備が入っている
      CephはS3機能との類似性が最も高いが、設定が複雑で、レイテンシに敏感だ
      Garageはシンプルな保存用途には良いが、S3の高度なACLやパス制限のような機能が不足している
      クラスタリングはWANフレンドリーだが、Cephのようにラック単位の構成を必要としない
    • MinIO以外ではGarageとCephを使ったことがあるが、単純なローカルテスト用S3ファイルシステムが必要だ
      まだそういうシンプルな代替はなさそうだ
    • SeaweedFSを単一マシンでS3互換ストレージとして使っている
      管理機能は乏しいが、データ整合性の面ではCephの方をより信頼している
      Cephは分散システムを本当に深く理解している人たちが作った感じがする
    • 上の代替一覧をMinIOリポジトリにPull Requestとして追加した
      PRリンク

  • 以前のHNスレッドを見ると、MinIOはすでにmaintenanceモードへ移行していたことが分かっていた
    その時点でクローズドソース化は予告されていたようなものだ

    • ただし、maintenanceモードと「もう保守しない」は別だ

  • MinIOはもともと透明性に欠けており、批判的なIssueを削除したりコメントをロックしたりするなど、オープンソース精神から離れていた
    だからmaintenanceモードになった時点ですぐGarageへ移行した
    PRを準備中だが、まだ提出はできていない

    • こうしたプロジェクトは高度な技術が必要なので、無料ユーザーを相手にする理由はないと思う
      たいていの本格的なオープンソースは産業界の支援を受けており、一般的なWeb開発者が貢献するのは難しい

  • MinIOリポジトリが削除される可能性に備えて、フォークを作ってローカルに保存しておくことを勧める
    GitHubの公開リポジトリは削除されてもフォークは残るが、非公開に切り替わるとフォークも消える
    Rubyエコシステムのprawn_plus Gemでも似たことがあった
    GitHubのフォークポリシー文書 を参照
    MinIOをローカルテスト専用で使っていた人には、徐々に閉じていく罠になりうる

  • Thanos、Loki、Mimir、Tempoのようにオブジェクトストレージを必要とするObservabilityソリューションを運用しているなら
    代わりにVictoriaMetrics、VictoriaLogs、VictoriaTracesを検討する価値がある
    これらはブロックストレージベースで、ペタバイト規模まで拡張可能であり、手動管理を必要としない高い性能と可用性を提供する