■ 1. Embulkの「メンテナンス・モード」発表
- 発表の経緯:
- 2025年10月15日、GitHubのembulk organizationに入っていたメンバーにメールを送付
- Embulkというオープンソースプロジェクトの「メンテナンス・モード」への移行を提案
- 背景となった問題意識:
- RubyGems周辺で発生したセキュリティ事件から教訓を得た
- 「複数の利害関係者が交わるオープンソース・プロジェクトでは、問題が起こる前にコミュニティで平和的に民主的に話し合えるうちにプロジェクトのガバナンスを実態に即して整えて形にして明示しておくべき」
- 特にセキュリティが重要な課題となりえて、かつ営利企業や金銭が関わる場合には重要
- Embulkの現状:
- 著者がメンテナーとして非アクティブとなり「アクティブなメンテナーはいない」状態になって既に半年が経過
- 本体に近いところでは著者と佐藤さんのみが見ている状態
- ときどきJDBC関係で@hito4_tさんにお声をかけて見てもらっている
- embulk-output-bigqueryについては独立したメンテナーが何人かいる
■ 2. メンテナンス・モードの具体的内容
- 対応内容:
- GitHub orgのメンバーやCore Teamを「今後もそれなりには関わり続ける気がある人」の最小限に絞る
- 「もう積極的にメンテナンスを続けられる状態ではない」ことを残るメンバー間で合意する
- 管理する対象自体（Zulipチャットなど）を減らす
- Embulkそのものについて引き継ぎたいと手が挙がったときは残るメンバーで検討する
- 以上をもって「メンテナンス・モード」とし外部に見える形で宣言する
- 今後の見通し:
- Embulkがアクティブにメンテナンスされることを期待しないでほしい
- pull requestなどを送っていただいてもレビューもマージもされないかもしれない
- Embulkはもともと無保証のApache License 2.0でライセンスされている
■ 3. organizationに残るメンバー
- 最終結果:
- 18人にメールを送付し、10人から期日内に返信があった
- 最終的に4人のみがGitHubのembulk organizationに残ることになった
- @frsyuki（原作者）、@hito4t、@hiroyuki-sato、@dmikurube（アナウンスの書き手）
■ 4. 更新の見込み
- 今後の更新について:
- 「二度と」更新しないというつもりはない
- 気が向いたときには更新するかもしれないが期待はしないでほしい
- ちょっとした改善や整理は入れるかもしれない
- もっと先のJavaへの追随や非互換ライブラリの更新（Jackson 2から3など）のような大きな更新を入れるのは現実的ではない
- 引き継ぎの可能性:
- 引き継ぎたいという人から手が挙がれば残るメンバーで議論する
- ただし実現しないだろうと個人的には思っている
- 昨年にはアナウンスを出していたが積極的な提案や反応はなかった
- 引き継ぎの難しさ:
- 「引き継いでくれるのなら誰でも、私たちが知らない人でも引き継ぐ」という態度は必ずしもユーザーのためにはならない
- 機密データの転送にもEmbulkを使っている組織がある
- 悪意を持つ誰かにEmbulkを引き渡してしまったら問題が起きる
- 悪意を持った引き継ぎの提案は拒否して単純にプロジェクトを継続しないほうがユーザーにとっても良い選択肢かもしれない
■ 5. ミドルウェアの定義と特性
- ミドルウェアの特徴:
- ミドルウェアを直接「使う」のは人間よりも主に誰か他の人が書いたソフトウェア・プログラム
- 「複数のソフトウェア・プログラムから同時に使われる・依存される」ソフトウェアという整理ができる
- ライブラリとの違い:
- ライブラリなら非互換を少し入れてしまっても「アプリケーション・コードのほうを直してね」で済む
- ミドルウェアではそうはいかない
- 典型的なミドルウェアであるRDBMSがいきなりSQL文法や接続プロトコルを変えてしまったら依存関係を考慮した複雑な対応が必要になる
- ミドルウェアの宿命:
- 依存関係グラフが深く複雑になるほど対応も複雑になる
- GuavaやJacksonのような「いろいろなJavaライブラリやミドルウェアから推移的に依存され互換性問題で悲鳴が上がるようになってしまったライブラリ」はミドルウェア的な宿命を背負わされて「ミドルウェア化」してしまった哀しきライブラリと見ることもできる
- 多様なプラグインから依存され、そのプラグインとEmbulkを組み合わせて使う多様なユーザーがいたEmbulkは正しく「ミドルウェア」だった
■ 6. オープンソースとメンテナンス
- メンテナンスの長期性:
- あるソフトウェアがミドルウェアであることと「長期間メンテナンスされ続けてきた」ことはほぼ不可分
- あるソフトウェアが他のソフトウェアから依存され互換性を気にされることはそのソフトウェアがそれなりに長期間メンテナンスされ信頼されてきた証
- オープンソースの現状:
- 近年では使われるミドルウェアの多くをオープンソースが占めるようになった
- この十年強の間に新しく生まれたミドルウェアは企業のsource-availableソフトウェアを除けば大部分がオープンソース
- 大規模なミドルウェアをメンテナンスする苦悩にはオープンソース・プロジェクト運営の苦悩も同時につきまとうようになった
- Honoの例:
- YAPC::Fukuoka 2025でHonoのYusuke Wadaさんが「OSS開発者の憂鬱」というトークをされた
- 「クリエイターからメンテナーへ」「作っていればよかったのが保守しなくてはいけなくなる」「Noを言うには体力がいる」「政治に巻き込まれる」
■ 7. Linux開発者の見解
- Linus TorvaldsとDirk Hohndel氏の発言:
- 「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題
- Linuxカーネルのメンテナーはその必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている
- 「オープンソースの世界はプログラミングがすべてだと思っている人も多いが、実はコミュニケーションが占める割合も大きい」
- 「メンテナーの仕事は翻訳であり、それは必ずしも言葉を翻訳するということではない。文脈、つまりそのコードであるべき理由を説明するということであり、それは大変な仕事だ」
■ 8. 悪意の存在
- サプライチェーン攻撃の現実:
- オープンソース・プロジェクトがソフトウェア・サプライチェーンの重要な位置を占めるようになった
- 悪意を持つ攻撃者にとってオープンソース・プロジェクトは格好の攻撃対象になっている
- サプライチェーンの根っこのほうを乗っ取れれば攻撃者にとって得るものが大きい
- XZ Utilsの事例:
- XZ Utilsに悪意のあるコードが挿入された問題（CVE-2024-3094）が確認されたのが2024年3月
- これは偶然にも氷山の一角が見つかった幸運な事例
- おそらくいくつかの攻撃は既に成功していて私たちのソフトウェア・サプライチェーンには悪意のあるコードがとっくに入り込んでいると認識しておくべき
- Embulkでの経験:
- 確実な証拠や確信こそ無いものの「これは攻撃だったんだろうな」という事例があった
■ 9. 個人によるメンテナンスの限界
- 現状の問題:
- 多くのオープンソース・ミドルウェアや「ミドルウェア化」したオープンソース・ライブラリが「個人」の手になるメンテナンスに依存
- 多くのメンテナーが「疲弊」している
- この数ヶ月の間だけでもcurlやlibxml2の話題が挙がっている
- エコシステムの持続性への疑問:
- 個人で続けられるか疑問
- 私たちのソフトウェア・エコシステムがいつまで保つか
- 2025年の日本各地で問題のクマ対応とも相似形の問題を感じる
■ 10. Embulkの場合の詳細
- 著者の状況:
- 半年ほど前にTreasure Data（TD）を退職
- Embulkの「アクティブ」なメンテナーから「降りて」いる状態
- この時点でEmbulkには「個人」のメンテナーしか残っていない状態だった
- 新しい職場でEmbulkを使う見込みはなかった
- 以前からの活動:
- 「オープンソースとしてのEmbulkのメンテナーを他にも割り当ててちゃんと引き継げる状態にしませんか」という活動を社内で数年前からしていた
- 社外でもEmbulkを使っていると対外的にも知られた企業さんなどに「一緒にメンテナーやりませんか」と言ってきた
- Core Teamのような形を作って少しずつでも関わってもらおうという取り組みもしていた
■ 11. プロジェクトをたたむ決断
- 決断の背景:
- 引き継ぐ意志を明示的に示す人や組織が現れない限り既定路線だった
- 当時の勤務先から積極的なサポートも見込めなかった
- 自分はオリジナルの作者でもない
- 個人として続けても安定した収入に結びつくわけでもない
- メンテナンスを続けるしんどさだけがそこにある
- 「これは攻撃だったんだろうな」の件も最後の追い打ちになった
- たたみ方の方針:
- 「メンテナンスを静かに止めて言及も止めてアナウンスもせず、いつの間にかフェードアウト」のような態度を取るべきでないと考えた
- 企業などで重要データを運ぶこともあるEmbulkのユースケースを考えれば盛大に事故る前に落ち着いて切り替えができるうちに公式なアナウンスをしておくことがメンテナーの責務
- 悪意を持った人や組織にプロジェクトを引き継いでしまうくらいなら、プロジェクトをちゃんとたたむほうが結果的にユーザーにとっても良い
■ 12. 軟着陸のための方針
- 取り組み内容:
- 「このままだと続かないよ」という広報を陰に陽に続け、引き継ぐという人や組織が現れれば歓迎し、引き継ぐために労力を割く意志も示す
- 引き継ぎやすくするために今のEmbulkの設計について「なぜそうしたのか」を記録したドキュメント（Architectural Decision Record的なもの）をなるべく書き残す
- 「メンテナンス・モード」になっても即座に「使えなく」はならない程度に「塩漬け」の準備をする
- 評価:
- 100%狙いどおりにいったとは言えないが、たたみ方として悪くない着地になった
- Embulkのコア機能やSPI（Service Provider Interface）の設計はよくできている
- もうしばらくはこのままでもいちおうは「使える」
- ただし無保証のオープンソース・ソフトウェアなので保証はない
- 「いちおうは使える」うちに落ち着いて移行や社内forkなどを進めることをおすすめする
■ 13. 引き継ぎの困難さ
- 現在の引き継ぎの可能性:
- いまからでも引き継ぐ道筋はいちおう残している
- ただし当時ほど現実的な選択肢ではもうない
- 困難な理由:
- 「引き継ぎのために著者が割けるのは100%プライベートの時間のみになった」こと
- 「引き継ぎを申し出た人や組織に『悪意がない』ことを確認するのが難しい」こと
- それらを乗り越えてでも引き継ぐ意志のある組織の方がいれば連絡してほしい
■ 14. メンテナーの仕事と責任
- メンテナンスの困難さ:
- オープンソース・プロジェクトを、中でも「ミドルウェア」的な立ち位置になったソフトウェアのメンテナンスを「個人」の手のみによって続けるのは無理
- これは一つのオープンソース・プロジェクトのメンテナーを十年近く続けてみることで得た当事者としての結論
- 開発とメンテナンスの違い:
- 新規のオープンソース・ソフトウェアを開発するとか定期的に「コントリビューションする」とかはけっこう「個人」でできる
- しかし「メンテナー」の役務はこうした「開発」とはまったく異なる
- オープンソース・ミドルウェアのメンテナーが担うのは聞き取り、コミュニケーション、判断、意思決定、その意思決定の末にやってくる結果に責任を負うこと
- 責任の本質:
- オープンソースは「無保証」でありユーザーが損害を被ってもメンテナーはその損害に責任を負うものではない
- しかし「俺は俺が公開したいコードを好きに公開してるだけだし、ユーザーのことなんか知らね」と考える開発者なら最初からオープンソース・ミドルウェアの開発やメンテナンスなんかやっていない
- 「あのときの自分の判断と意思決定の結果、どれだけのユーザー開発者がどのような影響を受けたのか」に向き合い続けるのがオープンソース・ミドルウェアのメンテナー
- Linuxからの教訓:
- メンテナーは異なる意見を持つ開発者間の調停役を務めたりベンダーやユーザーとやり取りをする必要もある
- 「開発者を見つける方はずっと簡単だ。開発者はたくさんいる」
- 「メンテナーになるためには、他人のコードの善し悪しを判断できるだけのセンスを持っていなければならない」
- 「それは通常、単に十分な経験があるかどうかの問題だ」
■ 15. 企業・組織の貢献と責任
- 企業ユーザーの困難:
- 「企業ユーザー」が依存し始めた「ミドルウェア」のメンテナンスを「個人」の手のみによって続けるのは無理
- しかし「企業ユーザー」は無理では困ってしまう
- コントリビューションの誤解:
- 「もっと積極的に『コントリビューション』します」と考えるなら記事を読み返すべき
- 徒に「コントリビューション」（pull requestなど）ばかりを増やすのはむしろメンテナーの負担を増やすだけの結果になるかもしれない
■ 16. オープンソース・プロジェクトの現在地とポリシーを知る
- 把握すべきこと:
- 依存しているそのオープンソース・プロジェクトはどこの誰がどう開発やメンテナンスをしているか把握しているか
- 様々なケース:
- 一個人が趣味で開発・公開しただけのまだ「メンテナンス」という段階ですらないもの
- 開発者自身がオーナーシップを握って互換性など気にせず変えながら外部からのコントリビューションも入れず好きなように開発したいと思っているもの
- 個人や数人レベルで開発しつつそろそろライブラリやミドルウェアとして安定してきていろんな人に使ってもらいたいと思っている段階のもの
- 企業発のオープンソース・プロジェクトだが社内で作ったコンポーネントをせっかくだからと公開しただけで広く使ってもらおうという気は特になく社外の互換性都合など気にするつもりもなく外部からのコントリビューションを受け付ける気もないもの
- 企業からオープンソース・プロジェクトとして公開しているが外部からのコントリビューションを受ける気はなく自社プロダクトを購入してもらうための導線として公開しているだけのもの
- 企業発の門戸を開いたオープンソース・プロジェクトとして主導権は持ちながらエコシステムとともに発展させたいと考えているもの
- 個人や企業から始まったオープンソース・プロジェクトだが大規模化して複数の個人や企業関係者が意思決定に参加するはっきりしたガバナンスを持つプロジェクトになっているもの
- 個人発でも企業発でも今後のメンテナンス継続に限界を感じている状態のもの
- これらのケースの間のグラデーションのどこかに位置するあいまいな状態のもの
- 判断の必要性:
- 一口に「オープンソース・プロジェクト」といってもいろいろ
- 「オープンソース」はただのライセンスでしかない
- あなたの企業はそのオープンソース・プロジェクトに依存しても大丈夫か
■ 17. オープンソース・プロジェクトが求める貢献の形
- pull requestの誤解:
- プロジェクトをGitHubに公開すると問答無用でpull requestを受け入れる状態にさせられてしまう
- 「オープンソース・プロジェクトにはpull requestという名の『コントリビューション』を送るものなんだ」という「誤解」がすっかり広まってしまった
- オープンソースであってもすべてのプロジェクトが外部からのpull requestを実際に受け入れているとは限らないし受け入れていても喜ばれるとは限らない
- 求められる貢献の形:
- ただ応援してほしいだけかもしれない
- スターがつくと嬉しいプロジェクトもあるかもしれない
- いろんな人からのpull requestが嬉しいプロジェクトかもしれない
- バグ報告は欲しいがpull requestは求めていないかもしれない
- スポンサーのほうがpull requestよりも嬉しいかもしれない
- 最終的には自社プロダクトを購入してほしいかもしれない
- メンテナーとして共に持続的に役務を負ってくれる人を求めているかもしれない
■ 18. お金をとおしてメンテナンスに貢献する
- スポンサーの方法:
- GitHub SponsorsやOpen Collectiveをとおしてスポンサーするのが話が早い
- このような形でスポンサーを求めていないプロジェクトにスポンサーするのはややこしいが求めているプロジェクトには遠慮なく支払える
- 企業としての検討:
- 企業としてスポンサー支出に正当性を持たせるのが難しいのはわかる
- すべての依存プロジェクトをスポンサーするのは不可能
- ただし「もしこのプロジェクトのメンテナンスが途絶えたらビジネスの継続にも支障が出る」というオープンソース・プロジェクトはないか
- そういう単一障害点すら特定できていないのであればまずその特定をしたほうがいい
- オープンソース・プロジェクトなんていつ止まってしまうかわからない
- その単一障害点にあるプロジェクトくらいスポンサーを検討してもいいのではないか
- 製品購入:
- そのオープンソース・プロジェクトがあくまで製品への導線で企業ユーザーとしてそのプロジェクトに依存するレベルで使おうとしているならちゃんと製品を購入すべき
■ 19. スポンサーの限界
- スポンサーの現実:
- お金をとおして貢献できるプロジェクトばかりではない
- そのメンテナーが人生をかけて個人でやっているのならスポンサーによってメンテナーの命と生活が助かるかもしれないがそんなプロジェクトはごく少数
- 個人メンテナーにとってスポンサーはお小遣いくらいにはなるかもしれないが安定した収入として生活を支えられるようなものにはそうそうならない
- Embulkの場合:
- 企業発という出自もあってスポンサーを募ったりはしていなかった
- 仮にTreasure Dataとは独立にスポンサーを募って個人としてメンテナーを続けたとしても自分や家族の生活を支えられるとは思えない
- 本質的な問題:
- 多くのオープンソース・プロジェクトにとってスポンサーは継続そのものの助けにはならない
- 多くのオープンソース・プロジェクトには結局本来そもそも持続に必要なだけのメンテナーが「いない」
- 多くのメンテナーが手弁当でメンテナンスを続けている（そして続けられていない）
- Linuxにおいてすらそうである
■ 20. 雇用をとおしてメンテナンスに貢献する
- 課題の本質:
- 私たちの「足元」があとどれだけ保つか
- そこにある課題は「持続とメンテナーの安定」
- 「持続と安定」に対して企業に期待される最もわかりやすい貢献は結局「雇用」
- 現実的な提案:
- ほとんどの企業にとって「オープンソース・ソフトウェアのメンテナーをフルタイムで雇用する」なんていうのは難しい
- しかし強く依存する途絶えては困るオープンソース・ソフトウェアが今後も持続するために雇用コストのごく一部でも正式に割くことはそんなに難しいか
- ほとんどのオープンソース・ソフトウェアはかならずしもフルタイムでメンテナンスに従事するほどのメンテナーを必要としてはいない
- 一方で個人の業務時間外の時間のみで持続できるものでもない
- 具体的な提案:
- 自社が依存するオープンソース・プロジェクトとその現状を把握する
- その維持が苦境にあれば会社としてその「メンテナンス」に貢献する意志を示す
- 従業員がメンテナーとして継続的にそのプロジェクトに関与することを推奨する
- その従業員の勤務時間のn割はメンテナンス活動に使うことを認知する
- それを正式に評価する
- フルタイムではなくこれだけでもメンテナーの状況はかなり改善する
- 危機感:
- 世のbig techな企業はそれとはむしろ逆の方向に舵をきっていそう
- 「たたむ」オープンソース・プロジェクトはこれからおそらく増えていく
- その「足元」であなたの会社のビジネスは継続できそうか