オープンソース・プロジェクトのたたみ方

本記事は Embulk に関する以下のアナウンスの、非公式日本語版 + α です。

Embulk の「メンテナンス・モード」

去る 2025 年 10 月 15 日、その時点で GitHub の embulk organization に入っていた人に向けて、以下のようなメールを送りました。

Embulk に関係し、中でも Embulk の GitHub org にいる皆さま、

Embulk 関係の git log から確認できた公開メールアドレスや、個別に確認できたメールアドレス宛にお送りしています。

… (中略: 英語でのごあいさつなど) …

ご無沙汰しております。みくるべです。

このところ、一部から RubyGems 周辺の話題が聞こえてきます。

https://rubycentral.org/news/rubygems-org-aws-root-access-event-september-2025/
https://andre.arko.net/2025/10/09/the-rubygems-security-incident/

この件について、私にはなにが正しいとかどちらか悪いとかはわかりませんし、なにかを言う立場でもありません。

ただ、この件から得るべき最大の教訓は、以下のようなものだと感じています。
「複数の利害関係者が交わるオープンソース・プロジェクトでは、こういうことが起こる『前』に、コミュニティで平和的に民主的に話し合えるうちに、プロジェクトのガバナンスを、実態に即して、整えて形にして明示しておきましょう」

「特にセキュリティが重要な課題となりえて、かつ営利企業や金銭が関わる場合には。」

さて Embulk というオープンソースプロジェクトでは、私もメンテナーとして非アクティブとなり、「アクティブなメンテナーはいない」状態になって既に半年が経ちました。

https://www.embulk.org/articles/2025/04/11/dmikurube-is-stepping-down.html

そして Embulk の様子を、実態としてそれなりに (アクティブではないにしても) 見ているのは、

• 本体に近いところでは私と佐藤さんのみです。
• ときどき JDBC 関係で @hito4_t さんにお声をかけて見ていただいています。
• embulk-output-bigquery については独立したメンテナーが何人かいらっしゃいます。

私が Treasure Data 在職中には、ガバナンスの一種として Core Team というのを定義してみたり、実質的にコミュニティでの活動をしていない人 (当時の TD 関係者や退職者を含め) ともコミュニケーションを取って GitHub org から削除させてもらったり、など、ガバナンスや管理のための活動もチマチマとやっていました。

が、私も TD を退職して、自身もメンテナーとして非アクティブになりました。特に GitHub org などに多くの非アクティブなメンバーを多く抱えたままでは、ガバナンスを含む管理活動すらも、自信を持って続けるのは難しくなっています。

あと数年も放置すれば、冒頭の RubyGems のようなトラブルが起きても、おかしくはないでしょう。
(RubyGems ほど多くの人から依存されているわけではありませんが)

そして Embulk は、続いているようなテイではいますが、メンテナンスも実質的には既に止まりつつあります。たとえばセキュリティ関係のレポートが来ても、適時のちゃんとした対応は既に難しいでしょう。

そこで「プロジェクトのガバナンスを、実態に即して、整えて形にして明示する」ためにも、大雑把には以下のような対応をもって Embulk を「メンテナンス・モード」とすることを考えています。

1. GitHub org のメンバーや Core Team を「今後もそれなりには関わり続ける気がある人」の最小限に絞る。
   • といっても「今後もそれなりには関わり続ける気がある人」にしてほしいことは、「メンバーとして GitHub org 上に外部から見える形で所属と名前を出すこと」「なにかあったときには、責任を持つ一人として、内輪の相談に時間をとって参加してくれること」くらいで十分です。
   • が、それすらもけっこう大変だ、ということは、皆さんもうおわかりかと思います。
2. 「もう積極的にメンテナンスを続けられる状態ではない」ことを、残るメンバー間で合意する。
3. 管理する対象自体 (ex. Zulip チャットとか) を減らす。
4. Embulk そのものについて引き継ぎたいと手が挙がったときは、これを残るメンバーで検討する。
5. 以上をもって「メンテナンス・モード」とし、これを外部に見える形で宣言する。
   • このメール自体を、ほぼそのまま https://embulk.org/ などで公開することを考えています。

いかがでしょうか。

これについてご意見や、「自分は残る・残らない」など、このメールへの返信として、なんらかの意思表明をいただければ幸いです。 (必要であれば、私個人宛て限定にしていただいても大丈夫です。)

返信は日本語でかまいません。

皆さんになにかしら意思表明をしてもらった上で対応するのがベストだと思っていますが、今月2025年10月末日までになにも反応がなければ、「関わり続ける気はない」ものと解釈して対応するつもりです。

よろしくお願いいたします。

… (後略: 英語版のメッセージなど) …

注) このメールの文中で触れている Bundler/RubyGems の件は 2025 年 10 月 17 日に結論が出ています。詳しくは次の記事を参照ください: The Transition of RubyGems Repository Ownership

なにがどうなるのですか?

Embulk プロジェクトは、上に引用したメールのとおり、以下の対応をもって「メンテナンス・モード」に入ります。

• GitHub の embulk organization には、今後も参加し続ける意志のある最低限の人のみが所属するようになります。
• Embulk チームが管理しなければならない対象を減らします。たとえば、開発者向けの Zulip チャットを閉鎖します。
• Embulk チームとして「メンテナンス・モード」を宣言します。これはつまり、「自分たちにはもう、このプロジェクトをアクティブに維持することはできない」という宣言です。

短く言えば、今後はもう Embulk がアクティブにメンテナンスされることを期待しないでください。もし Embulk に pull request などを送っていただいても、レビューもマージもされないかもしれません。もっとも Embulk は Apache License, Version 2.0 でライセンスされるものなので、そんな保証は元からないのですが。

誰が organization に残るのですか?

最終的に (Bcc を含め) 18 人にメールをお送りし、内 10 人から期日内に返信をいただきました。その返信 (あるいは返信をいただけなかったこと) をもとに、以下の 4 人のみが GitHub の embulk organization に残ることになりました。

• @frsyuki: 原作者
• @hito4t
• @hiroyuki-sato
• @dmikurube: このアナウンスの書き手

もう二度と更新されないのですか?

「二度と」というつもりはありません。気が向いたときには更新するかもしれません。が、期待はしないでください。

ちょっとした改善や整理は入れるかもしれません。ですがたとえば、もっと先の Java への追随や非互換ライブラリの更新 (Jackson 2 から 3 とか) のような大きな更新を入れるのは、現実的ではないでしょう。

もしくは、もし Embulk を引き継ぎたいというどなたかから手が挙がれば、上の引用メールに書いたように、残るメンバーで議論することになります。ただ、これも実現しないだろうと個人的には思っています。それは、既に昨年には下記のようなアナウンスを出していたのですが、積極的な提案や反応はなかったからです。

ここでご理解いただきたいのは、「引き継いでくれるのなら誰でも、私たちが知らない人でも引き継ぐ」という態度は、必ずしもユーザーのためにはならない、ということです。ご存知かもしれませんが、機密データの転送にも Embulk を使っている組織があります。もし、悪意を持つ誰かに Embulk を引き渡してしまったら、どうでしょう? そのような引き継ぎの提案は拒否して、単純にプロジェクトを継続しないほうが、ユーザーにとっても良い選択肢かもしれないのです。引き継ぎとは、言うほど簡単なことではありません。

まとめ

Embulk は、その役目を果たしたと考えています。古橋さんから Embulk を引き継いで、数年にわたってメンテナーを務めたことは、個人としても得がたい経験でした。

まず Embulk を最初に作ってくれた古橋さんへ、そしてコミュニティで関わったすべての人へ感謝を。ありがとうございました。

振り返って

さてここからは、公式アナウンスには含まれていない、個人的な振り返りです。

ミドルウェア

Embulk を、その規模や使われかたから分類すると「ミドルウェア」となるでしょうか。

「ミドルウェア」の定義は、実はあまり自明ではありません。 ^[1] が、少なくとも共通して言えることは、ミドルウェアを直接「使う」のは、人間よりも、主に誰か他の人が書いたソフトウェア・プログラムだ、ということでしょう。

とはいえこれだけでは、いわゆる「ライブラリ」とミドルウェアを区別できません。このライブラリとミドルウェアの区別にも、実際おそらく複数の見方があって、白黒はっきりできるものではありません。

ここでは「『ミドルウェア』特有の難しさとはなにか」という点に着目してみたいと思います、すると一つの見方として、ミドルウェアとは「複数のソフトウェア・プログラムから同時に使われる・依存される」ソフトウェアである、という整理ができるかもしれません。

あるライブラリが使われる場面を個々に考えると、その場面でそのライブラリを使う・呼び出す「ユーザー」は、個々のアプリケーション・ソフトウェア一つ一つです。あるライブラリのメンテナーが修正や機能を加えるとき、非互換を少しくらい入れてしまっても、それがライブラリなら「ごめんちゃい★ アプリケーション・コードのほうを直してね★」で済むといえば済みます。

一方、上で整理したように「複数のソフトウェア・プログラムから同時に使われる・依存される」ミドルウェアでは、そうはいきません。たとえば典型的なミドルウェアであるところの RDBMS が、いきなりその SQL 文法や接続プロトコルを変えてしまったら、どうなるでしょうか。

その RDBMS (インスタンス) の「ユーザー」が真に一つのアプリケーション・コードしかない、なんて理想的な状態は、現実にはそう多くありません。全社的なデータ分析のためにデータベースからデータを集約していたり、サービス監視の一環としてデータベースの内容を定期的にクエリしていたり、他のマイクロサービスのデータベースに CDC (Change Data Capture) でレプリケーションする必要があったり、現実にはいろいろな状況があります。そしてそうしたデータ集約、監視や CDC のために、さらに他のミドルウェア ^[2] を使うでしょう。

もしその RDBMS が本当に SQL 文法や接続プロトコルを変えてしまった場合、その「ユーザー」たるアプリケーションの開発者・運用者は、「『他のミドルウェア』が新しい SQL 文法やプロトコルに対応してくれるのを一通り待って、まずそちらを更新してから、最後に RDMBS を更新する」のように、依存関係を考慮した複雑な対応を検討しなければなりません。依存関係グラフが深く複雑になるほど、対応も複雑になります。

つまりこの見方において「ミドルウェア」とは、こうした複雑な依存関係の起点となりがちなソフトウェアのことである、となります。この整理が意味するのは、ライブラリとミドルウェアを分けるのは、そのライブラリまたはミドルウェアの自認ではなく、「周辺のエコシステムからどのように依存されているか、その依存関係グラフの構造だ」という外形的な見方です。

その意味では、たとえば Guava や Jackson のような「いろいろな Java ライブラリやミドルウェアから推移的に依存され互換性問題で悲鳴が上がるようになってしまった『ライブラリ』」は、ミドルウェア的な宿命を背負わされて「ミドルウェア化」してしまった哀しきライブラリ、と見ることもできるのかもしれません。

多様なプラグインから依存され、そのプラグインと Embulk を組み合わせて使う多様なユーザーがいた Embulk は、この見方においても正しく「ミドルウェア」だったと思います。

オープンソースとメンテナンス

上の見方をするとき、あるソフトウェアがミドルウェアであることと、そのソフトウェアが「長期間メンテナンスされ続けてきた」ことは、ほぼ不可分です。

できたてほやほやのソフトウェアが、他の多くのソフトウェアから依存されて互換性維持に悩まされることなど、ありません。あるソフトウェアが他のソフトウェアから依存され、互換性を気にされるということは、すなわちそのソフトウェアがそれなりに長期間メンテナンスされ、信頼されてきたことの証でもあります。

ソフトウェアを長期間メンテナンスし続けることと、それにまつわる互換性問題などについては、少し前に、大学のオムニバス特別講義の場でお話しする機会をいただきました。記事の形で以下にまとめています。

また近年では、このように使われるミドルウェア、中でも大規模なものの多くをオープンソースが占めるようになりました。特にこの十年強の間に新しく生まれたミドルウェアは (企業の "source-available" ソフトウェア ^[3] を除けば) 大部分がオープンソースでもあるのではないでしょうか。

その結果、大規模なミドルウェアをメンテナンスする苦悩には、オープンソース・プロジェクト運営の苦悩も同時につきまとうようになりました。

折しも最近 YAPC::Fukuoka 2025 で Hono の Yusuke Wada さんが「OSS開発者の憂鬱」というトークをされたそうです。

クリエイターからメンテナーへ
作っていればよかったのが保守しなくてはいけなくなる

Noを言うには体力がいる

政治に巻き込まれる

このあたり、涙なくしては聞けません。

Embulk の場合、規模は Hono よりも小さいですが、「クリエイター」≠「メンテナー」であったことや、「企業発」でありながら「プラグイン」という社外のオープンソース・エコシステムに頼る設計だったことなど、状況をややこしくするポイントを部分部分で踏み抜いていました。そういったややこしさについては、以下の記事などで触れています。

そして Linux はこの分野の最大の先駆者と言っていいでしょう。その Linux の Linus Torvalds 氏と Dirk Hohndel 氏は、二年ほど前に以下のように語っています。

メンテナーの話が出ると、Hohndel氏は、「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題を取り上げた。先日の記事でも取り上げたように、Linuxカーネルのメンテナーは、その必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている。

「オープンソースの世界はプログラミングがすべてだと思っている人も多いようだが、実はコミュニケーションが占める割合も大きい。メンテナーの仕事は翻訳であり、それは必ずしも言葉を翻訳するということではない。私が言っているのは、文脈、つまりそのコードであるべき理由を説明するということであり、それは大変な仕事だ。しかし、私が保証するが、それでもメンテナーになりたいというのなら、トップには空きがある」

悪意の存在

さらに近年では、オープンソース・プロジェクトがソフトウェアの依存関係、つまりソフトウェア・サプライチェーンの重要な位置を占めるようになりました。つまり悪意を持つ攻撃者にとって、オープンソース・プロジェクトは格好の攻撃対象になっている、ということでもあります。サプライチェーンの根っこのほうを乗っ取れれば、攻撃者にとって、得るものが大きいですからね。

XZ Utils に悪意のあるコードが挿入された問題 (CVE-2024-3094) が確認されたのが 2024 年 3 月でした。それからまだ二年も経っていません。

当然ですが、このような攻撃を受けたのが XZ Utils だけだと思ってはならないでしょう。むしろ XZ Utils の件は、偶然にも氷山の一角が見つかった幸運な事例、としか考えられません。

おそらくいくつかの攻撃は既に成功していて、私たちのソフトウェア・サプライチェーンには、悪意のあるコードがとっくに入り込んでいる、と認識しておくべきでしょう。

実際 Embulk にも、確実な証拠や確信こそ無いものの、「これは攻撃だったんだろうな」という事例はありました。これについては別の記事にまとめているところで、数日中には公開したいと思っています。 (公開次第、本記事のこの部分も更新します)

「個人」によるメンテナンスの限界

さて、現代のオープンソース界・ミドルウェア界はこんな状態です。それでもいまだに多くのオープンソース・ミドルウェアや、「ミドルウェア化」したオープンソース・ライブラリが、「個人」の手になるメンテナンスに依存し、多くのメンテナーが「疲弊」しています。

たったこの数ヶ月の間だけでも curl や libxml2 の話題が挙がっていますね。

こんなこと、いつまでも個人で続けられるでしょうか。

私たちのソフトウェア・エコシステムは、いつまで保つでしょうか。

今年 2025 年の日本各地で問題のクマ対応とも、相似形の問題を感じてしまいます。

Embulk の場合

Embulk は個人じゃなくて企業主導だっただろうって?

まずこの話の前提として、私は半年ほど前には Treasure Data (TD) を退職して、既に Embulk の「アクティブ」なメンテナーから「降りて」いる状態でした。この時点で Embulk には「個人」のメンテナーしか残っていない状態だったんですね。

The company has shown no intention of taking a leadership role in the Embulk project and contributing to its maintenance. As a result, the Embulk project will have no active maintainers, at least for a while.

しかも、新しい職場で Embulk を使う見込みはありませんでした。 (現に使っていません)

この退職自体はかなり急に直前になって決めたのですが ^[4] Embulk がこの状況になること自体は、かなり以前から予期していました。オープンソースとしての Embulk のメンテナンスは、社内でも長いこと私一人でやっていたので。

だからこそ「『オープンソースとしての』 Embulk のメンテナーを他にも割り当ててちゃんと引き継げる状態にしませんか」という活動を、社内でも数年前からしていましたし、社外でも Embulk を使っていると体外的にも知られた企業さんなどに向けて、直接的にも間接的にもコミュニケーションをとって「一緒にメンテナーやりませんか」と言ってきました。

以下のような広報活動も、そうした活動の一端でした。

Core Team のような形を作って少しずつでも関わってもらおうというのも、その一つでした。

そして将来的な方針については、それらに対する内外の反応も見ながら考えていました。

プロジェクトをたたむ

今回の Embulk の「メンテナンス・モード」については、ユーザーの方々には申し訳ないことですが、引き継ぐ意志を明示的に示す人や組織が現れないかぎり、既定路線でした。

当時の勤務先から積極的なサポートも見込めず、自分はオリジナルの作者でもなく、個人として続けても安定した収入に結びつくわけでもない。メンテナンスを続けるしんどさだけがそこにある。まあ、続くわけもありません。前述の「これは攻撃だったんだろうな」の件も、最後の追い打ちになったでしょうか。

メンテナンス・モード後もメンテナーとして残ってくれている @hiroyuki-sato さんや @hito4t さんには、本当にお世話になりました。 (そしてまだもう少しの間、お世話になります)

とはいえ、残るメンテナンスをお二人に丸投げできるような状態ではありませんでした。そして「メンテナンスを静かに止めて言及も止めてアナウンスもせず、いつの間にかフェードアウト」のような態度を取るべきでない、とも考えていました。オープンソース・プロジェクトでは、わりとよく目にする「終わり方」ですけどね。身近なところでも。

特に企業などで重要データを運ぶこともある Embulk のユースケースを考えれば、どこかで盛大に事故る前に、落ち着いて切り替えができるうちに、公式なアナウンスをしておくことも、メンテナーの責務だろう、と考えました。それが今回の「メンテナンス・モード」です。 ^[5]

そしてこれは冒頭に引用したメールでも書いたことですが、悪意を持った人や組織にプロジェクトを引き継いでしまうくらいなら、プロジェクトをちゃんとたたむほうが、結果的にユーザーにとっても良いでしょう。悪意を持ってオープンソースに関わろうとする人や組織の存在は、残念ながら現代では明らかなのですから。

とはいえ、サービスやデータのインフラとして現在でも使っている企業がいる以上、いきなり放り投げてハードランディングさせるのは忍びない。ということで、せめて軟着陸の形でプロジェクトをたためるよう、しばらく以下のような方針をとっていました。

1. 「このままだと続かないよ」という広報を陰に陽に続け、引き継ぐという人や組織が現れれば歓迎し、引き継ぐために労力を割く意志も示す。 (前述のとおり)
2. 引き継ぎやすくするために、今の Embulk の設計 ^[6] について「なぜそうしたのか」を記録したドキュメント ^[7] をなるべく書き残す。 ^[8]
3. 「メンテナンス・モード」になっても即座に「使えなく」はならない程度に、「塩漬け」の準備をする。 ^[9]

100% 狙いどおりにいったとは言えませんが、たたみ方として、悪くない着地にはなったんじゃないかと思っています。冒頭のメールから古橋さんとも話したのですが、やはり Embulk のコア機能や SPI (Service Provider Interface) の設計はよくできていると思います。もうしばらくはこのままでも、いちおうは「使える」んじゃないでしょうか。

もちろんあくまで無保証のオープンソース・ソフトウェアですので、そこにはなんの保証もありませんし、「いちおうは使える」うちに落ち着いて移行や社内 fork などを進めることをおすすめしますが。

惜しむらくは、在職中にもう少しはっきりした表明をできれば、引き継ごうという人や組織の掘り起こしや、引き継ぎに向けた現実的なコミュニケーションを、もう少しやれたかもしれないな、ということでしょうか。とはいえそれは、仮に退職タイミングの問題がなくても難しかっただろう、とも思っています。 ^[10]

またこれも冒頭のメールにも書いたとおり、いまからでも引き継ぐ道筋は、いちおう残しています。ですがそれは「Embulk にメンテナーとして長期的に関わってくれる人と企業を探しています」でアナウンスした当時ほど現実的な選択肢では、もうないでしょう。

その理由は、「引き継ぎのために私が割けるのは 100% プライベートの時間のみになった」ことが一つ。そして「引き継ぎを申し出た人や組織に『悪意がない』ことを確認するのが難しい」ことがもう一つです。それらを乗り越えてでも引き継ぐ意志のある組織の方が、もしいらしたら、ご連絡ください。

メンテナーの仕事と責任

オープンソース・プロジェクトを、中でも「ミドルウェア」的な立ち位置になったソフトウェアのメンテナンスを、「個人」の手のみによって続けるのは 無理 です。

これは、一つのオープンソース・プロジェクトのメンテナーを十年近く続けてみることで得た、当事者としての一つの結論です。

新規のオープンソース・ソフトウェアを開発するとか、定期的に「コントリビューションする」とかは、けっこう「個人」でできちゃうんですよ。ですが「メンテナー」の役務は、こうした「開発」とはまったく異なります。

オープンソース・ミドルウェアのメンテナーが担うのは、聞き取りであり、コミュニケーションであり、判断であり、意思決定であり、その意思決定の末にやってくる結果に責任を負うことです。

もちろんオープンソースは「無保証」であり、たとえば仮にそのユーザーが損害を被っても、メンテナーはその損害に責任を負うものではありません。

ですがそもそも、「俺は俺が公開したいコードを好きに公開してるだけだし、ユーザーのことなんか知らね」と考える開発者だったら、オープンソース・ミドルウェアの開発やメンテナンスなんか、最初からやってないんですよ。特にミドルウェアは、そのユーザーでもある他のソフトウェア開発者ありきなんですから。

「あのときの自分の判断と意思決定の結果、どれだけのユーザー開発者がどのような影響を受けたのか」に向き合い続けるのが、オープンソース・ミドルウェアのメンテナーです。

仮にそれが、「熱心にアピールしてきた外部開発者の『コントリビューション』を根負けして受け入れた」結果であり、「その外部開発者はマージしたっきり連絡が取れなくなっちゃった」としても。

こうしたメンテナー仕事の最も顕著な例は、やはり先駆者である Linux において、よく見ることができます。

メンテナーはさらに、異なる意見を持つ開発者間の調停役を務めたり、ベンダーやユーザーとやり取りをする必要もある。後者は、ハードウェア企業との話し合い、そしてそうした企業のドライバーをオープンソース化するための調整作業、ドライバー開発方法に関する開発者支援、ノートPCに搭載されているタッチパッドを機能させるためのユーザーサポート（ドライバー開発時にハードウェア企業が協力してくれなかった場合などに起こり得る）に至るまで多岐にわたっている。

メンテナーの話が出ると、Hohndel氏は、「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題を取り上げた。先日の記事でも取り上げたように、Linuxカーネルのメンテナーは、その必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている。

Torvalds氏は、Hondel氏の問いかけに対して、「開発者を見つける方はずっと簡単だ。開発者はたくさんいる。ただ、メンテナーは何でもできるスーパー開発者でなければ務まらないと考えている人がいるが、実際にはそうでもない」と述べた。

「メンテナーになるためには、他人のコードの善し悪しを判断できるだけのセンスを持っていなければならない。それには生まれつきの才能も多少は必要かもしれないが、大部分は単なる練習の積み重ねだ。メンテナーは、他人のコードを見て『これは良いアプローチなのか、悪いアプローチなのか』を判断できなくてはならない。それは通常、単に十分な経験があるかどうかの問題だ」

先にも触れた Wada さんのトークでも、「開発者」の立場と「メンテナー」の立場については言及がありました。

クリエイターからメンテナーへ
作っていればよかったのが保守しなくてはいけなくなる

企業・組織の貢献と責任

このように多くのユーザー開発者が付き、特に「企業ユーザー」が依存し始めた「ミドルウェア」のメンテナンスを、「個人」の手のみによって続けるのは、前述したように 無理 です。

一方、特に「企業ユーザー」は 無理 では困ってしまいます。では、そうしたオープンソース・ミドルウェアやそのエコシステムに「持続してほしい」と考える「企業ユーザー」は、どうすればいいでしょうか。

「わかりました! もっと積極的に『コントリビューション』します!」

…と、もし考えたのなら、もう一度この記事を読み返しましょう。

そのオープンソース・プロジェクトのフェーズやポリシーによりますが、徒に「コントリビューション」 (pull request など) ばかりを増やすのは、むしろメンテナーの負担を増やすだけの結果になるかもしれません。

そのオープンソース・プロジェクトの現在地とポリシーを知る

依存しているそのオープンソース・プロジェクトは、どこの誰がどう開発やメンテナンスをしているでしょうか。

まず、それを把握していますか?

それは一個人が趣味で開発・公開しただけの、まだ「メンテナンス」とかいう段階ですらないものかもしれません。まだ開発者自身がオーナーシップを握って、互換性など気にせず変えながら、外部からのコントリビューションも入れず、好きなように開発したいと思っているかもしれません。

個人や数人レベルで開発しつつ、そろそろライブラリやミドルウェアとして安定してきて、いろんな人に使ってもらいたいなー、開発に参加してくれる人もいないかなー、と思っている段階かもしれません。

企業発のオープンソース・プロジェクトだけど、社内で作ったコンポーネントをせっかくだからと公開しただけであって、広く使ってもらおうという気は特になく、社外の互換性都合など気にするつもりもなく、外部からのコントリビューションを受け付ける気もないかもしれません。

企業からオープンソース・プロジェクトとして公開しているけど、外部からのコントリビューションを受ける気はなく、あくまで自社プロダクトを購入してもらうための導線として公開しているだけかもしれません。

企業発の門戸を開いたオープンソース・プロジェクトとして、主導権は持ちながら、エコシステムとともに発展させたいと考えているかもしれません。

個人や企業から始まったオープンソース・プロジェクトだけど、大規模化して、複数の個人や企業関係者が意思決定に参加する、はっきりしたガバナンスを持つプロジェクトになっているかもしれません。

個人発でも企業発でも、今後のメンテナンス継続に限界を感じている状態かもしれません。

このようなケースの間のグラデーションのどこかに位置する、あいまいな状態かもしれません。

一口に「オープンソース・プロジェクト」といっても、いろいろです。「オープンソース」はただのライセンスでしかありません。あるオープンソース・プロジェクトを取り上げたとき、上記のようなケースはすべてありえます。

その上で、あなたの企業は、そのオープンソース・プロジェクトに依存しても大丈夫ですか?

そのオープンソース・プロジェクトが求める貢献の形を知る

プロジェクトを GitHub に公開すると、問答無用で pull request を受け入れる状態にさせられてしまいます。なので、「オープンソース・プロジェクトには pull request という名の『コントリビューション』を送るものなんだ!」という「誤解」が、すっかり広まってしまいました。 ^[11]

ですがオープンソースであっても、すべてのプロジェクトが外部からの pull request を実際に受け入れているとはかぎりませんし、受け入れてはいても喜ばれるとはかぎりません。

そのオープンソース・プロジェクトが、外部からの「コントリビューション」を求めているのかどうか、求めているのだとして持続のためには「どういう」貢献を求めているのか、まずは知ろうとしましょう。

ただ応援してほしいだけかもしれません。

スターがつくと嬉しいプロジェクトもあるかもしれません。

いろんな人からの pull request が嬉しいプロジェクトかもしれません。

バグ報告は欲しいけど pull request は求めていないかもしれません。

スポンサーのほうが pull request よりも嬉しいかもしれません。

最終的には自社プロダクトを購入してほしいかもしれません。

そして…、メンテナーとして共に持続的に役務を負ってくれる人を求めているかもしれません。

お金をとおしてメンテナンスに貢献する

「企業ユーザーとして」そのオープンソース・ミドルウェアやそのエコシステムに「持続してほしい」と考えるなら、まず筆頭に挙がるののは、やはりお金をとおしての貢献になるでしょう。

そのプロジェクトが GitHub Sponsors や Open Collective をとおしてスポンサーを募集しているなら、そういうところからスポンサーするのが話が早いでしょう。このような形でスポンサーを求めていないプロジェクトにスポンサーするのはややこしいですが、求めているプロジェクトには遠慮なく支払えます。

企業として、スポンサー支出に正当性を持たせるのが難しいのはわかります。もちろん、すべての依存プロジェクトをスポンサーするのは不可能でしょう。

ですが「もしこのプロジェクトのメンテナンスが途絶えたら、ビジネスの継続にも支障が出る!」というオープンソース・プロジェクト、ありませんか?

もし、そういう単一障害点すら特定できていないのであれば、まずその特定をしたほうがいいでしょう。オープンソース・プロジェクトなんて、いつ止まってしまうかかわかりませんよ? ^[12]

その上で、その単一障害点にあるプロジェクトくらい、スポンサーを検討してもいいのではないでしょうか。

また、そのオープンソース・プロジェクトがあくまで製品への導線で、企業ユーザーとしてそのプロジェクトに依存するレベルで使おうとしているのなら、ちゃんと製品を購入しましょう。わかりやすい話です。

スポンサーはすべてをカバーできないという現実を知る

といっても、お金をとおして貢献できるプロジェクトばかりではありません。そのメンテナーが人生をかけて個人でやっているのなら、スポンサーによってメンテナーの命と生活が助かるかもしれません。ですが、そんなプロジェクトはごく少数でしょう。

個人メンテナーにとって、スポンサーは、お小遣いくらいにはなるかもしれません。ですが安定した収入として生活を支えられるようなものには、そうそうならないでしょう。以下の Rui Ueyama さんの記事なども、その現実を示しています。

Embulk だって、企業発という出自もあって、スポンサーを募ったりはしていませんでした。

もし仮に、たとえば Treasure Data とは独立にスポンサーを募って、私が個人としてメンテナーを続けたとしても、それが私や家族の生活を支えられるとは、ちょっと思えません。

こうした多くのオープンソース・プロジェクトにとって、スポンサーは、継続そのものの助けにはなりません。多くのオープンソース・プロジェクトには、結局、本来そもそも持続に必要なだけのメンテナーが「いない」のです。

多くのメンテナーが、手弁当でメンテナンスを続けています。 (そして、続けられていません。)

それは Linux においてすら、そうであるわけです。

その理由は、The Linux Foundationがプログラミング企業ではないためだ。The Linux Foundationは、企業や組織、開発者がオープンソースプロジェクトを推進していく上でのリソースを提供するオープンソースの財団法人だ。そしてメンテナーを雇うという役割はほとんどの場合、企業のものとなっている。

しかしCorbet氏が述べているように、メンテナーに報酬を支払おうというところはほとんど「ない」のだ。メンテナンスは日々の通常業務に加えて遂行する追加の作業となっている。企業はプログラマーに対して、新規のコードを記述してもらいたいと考えている。このためLinux全体の管理、あるいはその他のオープンソースプロジェクトや基盤となるインフラの管理を支援してもらうために報酬を支払うことに興味を示していない。

するとどうなるのだろうか。Corbet氏は、Googleのソフトウェアエンジニアであり複数のLinuxカーネルプロジェクトのメンテナーも務めるSteven Rostedt氏がメーリングリストに記した、「私自身はメンテナンスとは関係ないフルタイムの仕事を抱えつつメンテナーを引き受けている。このため、メンテナンス作業に取り組む時間の捻出に苦労している」という下りを引用した。

雇用をとおしてメンテナンスに貢献する

さて、私たちの「足元」は、あとどれだけ保つでしょうか?

そこにある課題は「持続と (メンテナーの) 安定」です。「持続と安定」に対して企業に期待される、最もわかりやすい貢献は、結局「雇用」ではないでしょうか。

もちろんほとんどの企業にとって、「オープンソース・ソフトウェアのメンテナーをフルタイムで雇用する」なんていうのは難しいでしょう。それはわかっていることです。 ^[13]

ですが、あなたの会社が強く依存する、途絶えては困るオープンソース・ソフトウェアが今後も持続するために、雇用コストのごく一部でも正式に割くことは、そんなに難しいでしょうか?

ほとんどのオープンソース・ソフトウェアは、かならずしもフルタイムでメンテナンスに従事するほどのメンテナーを必要としてはいません。一方で、個人の業務時間外の時間のみで持続できるものでもありません。

つまりたとえば、まずは自社が依存するオープンソース・プロジェクトとその現状を把握し、その維持が苦境にあれば会社としてその「メンテナンス」に貢献する意志を示し、従業員がメンテナーとして継続的にそのプロジェクトに関与することを推奨し、その従業員の勤務時間の n 割はメンテナンス活動に使うことを認知し、それを正式に評価する。

フルタイムではなく、これだけでも、メンテナーの状況はかなり改善するでしょう。

もちろん「これだけなら企業にとって簡単なはずだ」とは言いません。が、そういう努力を企業から始めなければ、「足元」が崩れるのはもうすぐかもしれません。

なにしろ世の "big tech" な企業は、それとはむしろ逆の方向に舵をきっていそうです。「たたむ」オープンソース・プロジェクトは、これからおそらく増えていくでしょう。

その「足元」で、あなたの会社のビジネスは、継続できそうですか?

まあ、一つのプロジェクトを「たたむ」決定をした当人の言うことではないかもしれませんが。

脚注

1. 2025 年 11 月時点の日本語版 Wikipedia の「ミドルウェア」は『ミドルウェア（英: Middleware）は、コンピュータの分野で、コンピュータの基本的な制御を行うオペレーティングシステム(OS)と、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェアのこと。』としています。が、実態として、ミドルウェアが入り、繋ぐのは OS とアプリケーションの中間のみにはかぎりません。正直、この説明はだいぶズレているように感じます。一方、同時点で英語版 Wikipedia の "Middleware" は 'Middleware is a type of computer software program that provides services to software applications beyond those available from the operating system. It can be described as "software glue".' としています。こちらのほうが、実態にだいぶ近そうですね。

2. それこそ Embulk とか。

3. 日本語版 Wikipedia: 「ソースアベイラブル・ソフトウェア」

4. レイオフとかではないです、念のため。

5. 前に自社発のオープンソース・フレームワークをメンテナンス・フェーズに移行するアナウンスを正式に会社として出していたのは、現職について以前から好ましく思っていたことの一つだったりします。

6. 特に Embulk v0.9 〜 v0.11 で大きく変えた部分の設計。

7. いわゆる Architectural Decision Record (ADR) 的なもの。

8. Embulk Enhancement Proposal (EEP) という形になっています。

9. 「塩漬け」: ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)より。たとえば依存ライブラリを減らしたり隔離したりとかですね。

10. お察しください。

11. これはこれで GitHub のポリシーとして理解はできるし、功罪ともにあったと思ってもいますが。

12. と、そのたたむプロジェクトの当事者が言うんですから。

13. いくつかは実例もありますが。日本では Ruby などの例 (1, 2) が有名です。 Hono の Wada さんも Cloudflare に雇用されていますね。