Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 「このプロジェクトの未来は危ういのか?」
タイムライン — 検証可能な事実だけ
リリースケイデンスの実測 — 揺らいだが、途切れはしなかった
いまFluxを作っているのは誰か — CORE-MAINTAINERSファイルを読む
金はどこから出ているか — オープンコアモデルとその境界線
Flux 2.9に実際に入ったもの
正直なリスク評価 — 残っているもの
導入者の立場から — 何を確認し、何を決めるか
おわりに
参考資料

はじめに — 「このプロジェクトの未来は危ういのか?」

2024年1月14日、fluxcd/flux2リポジトリにまさにその題名のディスカッションが立ちました — "Is the project future at risk?"。本文は短く直截でした。Weaveworksがプロジェクトの予算を使い切り、Fluxにフルタイムで取り組んでいた開発者たちが別の職を探すか、自腹で貢献を続けるかという瀬戸際にある、と。翌日、コアメンテナのStefan Prodanが自ら答えました — 「はい、その通りです(Yes this is accurate)」。そして、公式の回答をまもなく期待してほしいと付け加えました。

数週間後に実際に起きたことは、もっと悪いものでした。Fluxを作った会社Weaveworksが2024年2月初めに商業運営を停止すると発表したのです。GitOpsという言葉を作った会社であり、Fluxメンテナの大半の雇用主が消えました。

本稿はその後の2年半に実際に起きたことの記録です。きっかけは2026年6月30日に出たFlux v2.9.0です — スポンサー崩壊以降6本目のマイナーリリース。「オープンソースプロジェクトは企業スポンサーを失うと死ぬのか?」という問いに対して、Fluxはいま最もデータの豊富なケーススタディです。憶測ではなく、リリース日、メンテナ名簿、公式発表文といった一次資料だけで再構成してみます。

タイムライン — 検証可能な事実だけ

日付はすべて公開資料から直接確認したものです。

2022-11-30 — FluxがCNCFの卒業(Graduated)プロジェクトになる。当時は誰も知りませんでしたが、このガバナンス上の地位が1年後の生存に決定的でした。
2024-01-14 — コミュニティから「プロジェクトの未来は危ういのか」というディスカッションが提起される。翌日、Stefan Prodanが事実だと認める。
2024年2月初め — Weaveworksが商業運営停止を発表(CNCF発表文の表現では "announced that it would cease commercial operations at the start of February")。
2024-02-15 — 英国のセキュリティコンサル企業ControlPlaneがコアメンテナのStefan ProdanとSoule Baを正社員として雇用すると発表。同時にFIPS準拠のエンタープライズFlux配布版事業を開始。
2024-03-19 — CNCFがKubeCon EUでFluxを支える企業の一覧を発表。Aenix、Aviator、Microsoft Azure、ControlPlane、Edgecell、Fairwinds、Giant Swarm、Gimlet、GitLab、Nearform、OpsMx、OpsWorks、OSO、Teracloud、TNG — 15社。Microsoftのコメントがとりわけ実質的でした。「FluxはAzure上の複数のGitOps体験を動かすエンジンだ(Flux is the engine that powers several GitOps experiences on Azure)」。
2024-05-13 — シャットダウン以降で最初のマイナーリリース v2.3.0。
2026-06-30 — v2.9.0リリース。シャットダウン以降6本目のマイナー。

ここで目を留めるべき箇所があります。GitLabはWeaveworksが崩れる前の2023年初めにすでに、自社Kubernetesエージェントの推奨GitOpsソリューションとしてFluxを統合しており、MicrosoftはAzure(AKSのGitOpsアドオン)の基盤として使っていました。つまりFluxは「一社の製品」ではなく、すでに複数の大企業製品の部品になっており、その依存が救済作業の動機になりました。フランスの通信事業者Orangeも、CNCFの発表文で自社テレコムネットワークのGitOpsフレームワークはFluxだと明言しています。

リリースケイデンスの実測 — 揺らいだが、途切れはしなかった

「プロジェクトが生きているか」について最も操作しにくい指標がリリースケイデンスです。v2.0 GA以降のすべてのマイナーリリースの日付と間隔をGitHub Releasesから直接拾いました(同じ日付をendoflife.dateが独立に確認してくれます)。

バージョン	リリース日	直前マイナーとの間隔
v2.0.0	2023-07-05	— (GA)
v2.1.0	2023-08-24	50日
v2.2.0	2023-12-12	110日
v2.3.0	2024-05-13	153日 ← シャットダウン区間
v2.4.0	2024-09-30	140日
v2.5.0	2025-02-20	143日
v2.6.0	2025-05-29	98日
v2.7.0	2025-09-30	124日
v2.8.0	2026-02-24	147日
v2.9.0	2026-06-30	126日

読み取れること。

最も長い空白(153日)は、まさにシャットダウンを貫く区間です。v2.2.0(2023年12月)とv2.3.0(2024年5月)のあいだ — メンテナたちが雇用主を失い、新しい巣を探していたまさにその期間です。
ただしその最悪の区間ですら、次に長い間隔(2.7→2.8の147日)よりわずか6日長いだけです。崩壊というより「1サイクル遅れ」の水準でした。
年単位で見ると、2023年は3本(2.0, 2.1, 2.2)、2024年は2本(2.3, 2.4)、2025年は3本(2.5, 2.6, 2.7)、2026年は上半期だけで2本(2.8, 2.9)です。Fluxの公式リリースポリシーは「少なくともKubernetesと同じ速度(年3回のマイナー)」を掲げていますが、シャットダウンのあった2024年だけがこの目標に届かず、2025年から回復しました。

数字だけを見れば「生き延びた」というより「ほとんど揺らぎもしなかった」に近い。しかし、この滑らかな表面の下にある構造を見なければなりません。

いまFluxを作っているのは誰か — CORE-MAINTAINERSファイルを読む

FluxプロジェクトのCORE-MAINTAINERSファイル(2026年7月現在の基準)には9人が載っています。所属を数えてみると。

ControlPlane 3人 — Stefan Prodan、Matheus Pimenta、Leigh Capili
SUSE 1人 — Paulo Gomes
NexHealth 1人 — Aurel Canciu
Associmates 1人 — Max Jonas Werner
無所属(Independent) 3人 — Hidde Beydals、Sanskar Jaiswal、Soule BA

2つのことが目を引きます。

第一に、書類上は多様化していますが、活動量はそうではありません。 v2.9.0のチェンジログを開いてPR一覧をざっと眺めると、機能開発の相当数がStefan ProdanとMatheus Pimenta — どちらもControlPlane所属 — の手から出ています。CLIプラグインシステム(RFC-0013)は提案も実装もProdanです。ファイルに書かれた9人と、実際にロードマップを引っ張っている人の数は違います。

第二に、雇用関係は動き続けます。 2024年2月にControlPlaneへ一緒に雇用されたと発表されたSoule Baは、2026年7月現在、ファイル上では無所属と表記されています。「会社がメンテナを雇用した」というニュースはスナップショットにすぎず、2年後もその構造が維持される保証はないことを、このファイルがそのまま示しています。

金はどこから出ているか — オープンコアモデルとその境界線

Weaveworksの失敗からコミュニティが得た教訓は「グッドウィルだけではフルタイムのメンテナを維持できない」でした。いまのFluxの資金構造は、大きくこう要約できます。

アップストリームはCNCFプロジェクトのまま残しつつ、商業配布版がメンテナの給与を賄う。 ControlPlaneはEnterprise for Flux CDという名前でFIPS準拠ビルド、旧バージョン互換、24/7サポートを売る会社になり、その売上でメンテナを雇用しています。この境界線は公式リリースノートにも明示的に登場します — v2.9.0のリリースノートは、Fluxプロジェクトは最新3つのKubernetesマイナーバージョンのみをサポートし、より古いKubernetesとOpenShiftの後方互換はControlPlaneのようなベンダーが提供する、と書いています。

境界線の位置を具体的に確認しておくのがよいでしょう。 アップストリーム(無料)側は。

CLIとコントローラの直近3つのマイナーリリースのサポート — ただしドキュメントの表現をそのまま移すと、バックポートは「コミュニティが最善努力ベースで(best-effort basis)提供」します。SLAではありません。
最新3つのKubernetesマイナーバージョンとの互換(v2.9基準で1.34/1.35/1.36)。

商業(有料)側は。

旧バージョンのKubernetes/OpenShift互換ビルド、FIPS、サポート契約。
Flux Operator — Fluxのインストール・ライフサイクルを管理し、Web UIを提供するオペレータ。これはCNCF FluxプロジェクトではなくControlPlaneのGitHub組織(controlplaneio-fluxcd)にあるAGPL-3.0プロジェクトであり、エンタープライズ配布版には商業ライセンスで束ねられて出ていきます。

この構造を批判したいのではありません — Weaveworks方式(VC資金で無料開発を補助する)より正直で持続可能に見えます。ただ導入者は、「Flux」と呼んでいるものの中にCNCFガバナンスの下にある部分と、一社の製品である部分が混ざっていることを知って線を引く必要があります。UIが必要になってFlux Operatorに寄りかかり始めれば、その部分はCNCFではなくControlPlaneの持続性に賭けることになります。

Flux 2.9に実際に入ったもの

ガバナンスの話から離れて、リリース自体も見る価値があります。v2.9.0リリースノートと公式ブログを基準にした主な項目。

CLIプラグインシステム — RFC-0013として提案されたkubectl/krewスタイルの拡張。flux-<name> という実行ファイルをプラグインディレクトリに置けば flux <name> サブコマンドになります。GitHubにホストされた中央カタログから flux plugin install でインストールし、SHA-256チェックサムを検証します。最初のプラグインはMirror(チャート・OCIアーティファクト・イメージレジストリのミラーリング)とSchema(JSONスキーマ・CELルールに基づくマニフェスト検証)です。注意点として、RFC文書が自ら明かしているとおり、v1beta1ではチェックサム検証のみで、Cosign/SLSA署名の検証はありません。 そしてOperatorプラグインはFluxプロジェクトではなくControlPlaneが管理します — 上で述べた境界線がCLIの中にまで入り込んでいるわけです。
Server-Side Applyのフィールド無視ルール — Kustomizationで特定の管理フィールドをドリフト検知から除外できます。HPAが触るreplicasのようなフィールドのせいで永遠にドリフトが立っていた古典的な苦痛に対する公式の解法です。
SOPSのAgeポスト量子暗号サポート — シークレット復号の経路に耐量子暗号のオプションが入りました。
OpenBao/VaultのWorkload Identity認証、SSH鍵ベースのGitコミット署名・検証、シークレット不要のOIDC Webhook Receiver — 3つとも「長期保管されるシークレットを減らす」という同じ方向の変化です。
Helmのポストレンダー戦略とチャートフックのサポート、helm --set-literal に相当するリテラル値モード。
APIの削除 — image.toolkit.fluxcd.io/v1beta2 と notification.toolkit.fluxcd.io/v1beta2 がCRDから削除されました。この旧バージョンAPIを使っているなら、アップグレード前に移行が必要です。

機能一覧から読めるプロジェクトの方向は明瞭です — 新領域への拡張よりも、セキュリティチェーン(署名、アイデンティティベースの認証、シークレットの除去)と運用のエッジケース(ドリフト、フック、モノレポ)を埋める成熟期のリリースです。スポンサー崩壊の2年後のリリースとしては健康な姿です。

正直なリスク評価 — 残っているもの

生き延びたという事実は、リスクが消えたという意味ではありません。2026年7月時点で私が見る残余リスク。

単一企業への集中が形を変えて再現されています。 Weaveworks時代の問題は「メンテナの大半が一社所属」でした。いまコアメンテナ9人のうちControlPlane所属は3人ですが、コミットとRFCの重心はその3人の側にあります。ControlPlaneのエンタープライズ事業が揺らげば、同じ映画をもう一度見ることになりかねません。違いがあるとすれば — 今回はMicrosoftとGitLabが自社製品の部品としてFluxを使っているので、最悪の場合でも受け止める手がもっと多いという点です。

「コミュニティのbest-effort」はSLAではありません。 3つのマイナーのサポート・バックポートのポリシーは、ドキュメントに明示的に最善努力ベースだと書かれています。規制産業でパッチの保証が必要なら結局は商業契約に向かうことになりますが、その契約相手は事実上一社です。

エコシステムの偏りも依然として残ります。 同じ期間にArgo CDは3.3.0(2026-02-02)、3.4.0(2026-05-05)を出し、複数のベンダーで分担する開発体制を維持しています。ツール選定の観点からの比較はGitOps 実践ガイド: ArgoCD vs FluxCD アーキテクチャ比較とプロダクションデプロイ戦略で扱ったのでここでは繰り返しませんが、「メンテナの雇用構造」という軸では2つのプロジェクトの形がいまかなり違う、という点だけ指摘しておきます。

UI・ライフサイクル管理のような利便レイヤはCNCFの外にあります。 純粋なアップストリームFluxは相変わらずCLIとコントローラの束であり、ダッシュボードが必要ならControlPlaneのFlux Operator(AGPL + 商業ライセンス)かサードパーティに行くしかありません。Weave GitOpsという無料UIがあった時代より、この部分はむしろ後退しました。

導入者の立場から — 何を確認し、何を決めるか

この事例から得られる実務的なチェックリストを整理すると。

依存しているオープンソースのメンテナ雇用構造を確認してください。 MAINTAINERSファイルに所属が書かれているプロジェクトは思ったより多いです。「CNCF卒業プロジェクトか」よりも「フルタイム貢献者の給料はどこから出ているか」のほうが敏感な先行指標です。Fluxが生き延びたのはCNCFガバナンスのおかげが半分、大企業の製品がすでに部品として使っていたおかげが半分です。
アップストリームのサポート窓を運用計画に反映してください。 Fluxは直近3つのマイナーだけをサポートし、年に2〜3回マイナーが出ます。おおよそ1年前後でサポート窓から押し出されるという意味です。v2.9のリリースとともにv2.6はEOLになりました。「入れて忘れる」運用とは両立しません。
無料/有料の境界線の上にあるコンポーネントを区別しておいてください。 CNCF Flux(CLI + コントローラ)とControlPlaneの製品(Flux Operator、旧バージョン互換ビルド)をアーキテクチャ文書で別の色に塗っておけば、後のベンダー交渉やリスク評価がずっと綺麗になります。
すでにFluxをうまく使えているなら、乗り換える理由はありません。 2024年の恐怖が色褪せるほどケイデンスは回復し、2.9は中身のあるリリースです。「Weaveworksが潰れたからFluxは危ない」という判断は、2026年現在のデータと合いません。

おわりに

2024年1月の「このプロジェクトの未来は危ういのか?」という問いに対する2026年7月の答えは、こう整理できます — プロジェクトは危うくなかった。ただしその生存はタダではなく、オープンコアの事業モデルと大企業たちの製品依存という2本の柱の上に再建築されたものだ。

リリース間隔のデータが示すとおり、Fluxは最悪の区間でも1サイクル遅れ程度で持ちこたえ、いまはポリシーのケイデンスを回復しました。同時に、CORE-MAINTAINERSファイルとリリースノートの行間が示すとおり、保守の駆動力の重心は依然として一社に傾いています。オープンソースインフラの持続可能性とはこのように — 劇的な死亡宣告でも、完全なハッピーエンドでもなく — 構造と金の問題として管理され続けるものです。導入判断もその目で行えばよいのです。