Embulk にメンテナーとして長期的に関わってくれる人と企業を探しています

(この記事は www.embulk.org にある Looking for long-term maintainers around the Embulk eco-system の日本語訳と、同じ筆者によるもう少しぶっちゃけた追記です。)

---

古橋さん (@frsyuki) が最初に Embulk をリリースしてから、まもなく 10 年になります。もう Embulk はかなり成熟・安定して、いまも企業などで実際に使われています。近代化にも引き続き取り組んでいて、もうすぐ Embulk v1.0 を出せるだろうと考えています。

EEP-8: Milestones to Embulk v1.0, and versioning strategies to follow

その傍らで、実は多くのものが置き去りになっています。たとえば https://github.com/embulk にあるほとんどの「公式」プラグインは、いまだかなり古いライブラリに依存しています。 (Embulk 本体や、標準の組み込みプラグイン、ユーティリティ・ライブラリなどは最近ようやく更新できたのですが。) さらに、プロジェクトの Web サイトはほとんど更新できていませんし、ユーザーや開発者向けのドキュメントは不十分なままです。

端的に言って、現在の私たちにはあまり余力がありません。筆者の三廻部 (@dmikurube) は Treasure Data での勤務時間の半分をオープンソースの Embulk プロジェクトに割いていますが、そこでやれるのは、本体とその周辺の各種整備や、アーキテクチャ設計についての記録を EEP のようなドキュメントとして積み上げることくらいです。佐藤さん (@hiroyuki-sato) は、私や外部からのプルリクエストのレビュー、提案、問題提起など、個人の時間で非常に多くの貢献をしてくれています。田中さん (@hito4t) も、個人の時間で JDBC プラグイン関連のコードレビューなどをしてくれています。ですがこれが、現在も Embulk エコシステムのメンテナンスを続けるメンバーとリソースの、ほぼすべてです。

つまり Embulk は現在、持続可能だとはちょっと言いにくい状態にあります。

とはいえ世間はそんなに甘くなく

私たちは助けを必要としています。しかし残念ながら、「私たちは『皆さんの』助けを必要としています」と大きな声で言える状態でもないのです。

2024 年 4 月に明らかになった XZ Utils のバックドアに関するニュースを覚えている方もいるかもしれません。

• Securelist by Kaspersky: Social engineering aspect of the XZ incident (2024 年 4 月 24 日)
• Russ Cox: Timeline of the xz open source attack (2024 年 4 月 3 日)
• Steven J. Vaughan-Nichols (翻訳校正: 川村インターナショナル): トーバルズ氏が語った「XZ Utils」バックドア問題、AIの誇大宣伝 (2024 年 4 月 24 日)
• JPCERT/CC: XZ Utilsに悪意のあるコードが挿入された問題（CVE-2024-3094）について (2024 年 4 月 1 日)

同じことは Embulk に起きてもおかしくありません。まったく新しくやってきた人に大きな信頼を置くことは、残念ながら現在の世界ではリスクです。

実は、すでに「疑わしい」開発者から Embulk に対して「悪意が背景にあるように見える」接触を受けたことがあります。彼らは、善意からのように見える自明で些末な改善を、名の知れた複数のオープンソース・プロジェクトに対して、一斉に送っていました。それは XZ Utils の事件の発覚から間もないころだったので疑うことができましたが、そうでなければ気にせず受け入れてしまったかもしれません。 ^[1]

この年末年始にも、似た手合いと思われる活動があったようです。

このような攻撃 (?) は、生成 AI によって以前よりも簡単になっているでしょう。彼らが本当に AI を使っていたかはわかりませんが、使うのをあえて避ける理由も思い当たりません。生成 AI は、半自動的に (雑なものであっても) 多くの攻撃を「生成」することで、より大きな力を攻撃側に与えることができます。一方の防御側 (メンテナー) が生成 AI から得られる支援は、現状では非常に限られています。オープンソースのメンテナーにとって、現代は、大変な時代だといえるかもしれません。 (AI が、完璧なセキュリティレビューとバックグラウンドチェックをやってくれたらいいのですが)

それでも皆さんの助けが必要です

オープンソース・コミュニティにとってはかように難しい時代ですが、特に長期的なメンテナーという役割において、それでも皆さんの助けが必要だ、と言わなければなりません。

貢献してもらえるのは、それが単発や短期のものであっても、ありがたいものです。しかし、コミュニティの外から単発の貢献を Embulk にいただいても、メンテナーがその内容をレビューしなければなりません。悪意のある変更や脆弱性がないことはもちろん確かめなければなりませんし、互換性を損なわないか、将来の拡張をむしろ妨げないか、という点にも気をつける必要があります。提案に変更が必要な場合や、提案を受け入れられない場合は、それぞれコミュニケーションを取らなければなりません。これに対応するだけの余裕が、現在の私たちにはあまりありません。

ここで Linux のメンテナーに関する記事から、一節を引用します。

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

『トーバルズ氏、Linux開発の現状や生成AIについて語る』 (Written by Steven J. Vaughan-Nichols / 翻訳校正: 石橋啓一郎 / 2023-12-11 06:30) より

個人の時間だけでメンテナーを務めるのは、誰にとっても非現実的です。そんなことは、例外的にパワフルなエンジニアにしかできません。所属組織のサポートを得ながらメンテナーの役割を担うことができれば、持続可能性の観点からは理想的だといえるでしょう。

その一方、有志・奉仕のためだけにリソースを費やすのは、組織 (特に営利組織) としては非合理的です。もし、すでに Embulk を大規模に利用して活動やビジネスをおこなっている組織が、その維持のために自社のエンジニアがメンテナーとして時間と労力を使うことを支援してくれるなら、その組織とコミュニティの利害は完璧に一致するでしょう。

しかし前述のような理由から、まったく新しい人をいきなり受け入れることには、コミュニティとしても不安があります。過去にコミュニティと一緒に活動した経験のある人がメンテナーとして参加、あるいは他の誰かをメンテナーに紹介してもらえたら、新しいメンテナーを明快な関係として説明しやすくなるでしょう。

もちろん、まったく新しい方を一切歓迎しないわけではありません。ですが、たとえば「あなたの所属組織やバックグラウンドを確認させてほしい」のような、失礼なお願いをするかもしれないことをお許しいただけたら幸いです。前述のように、あなたが所属組織の支援を受けていれば、話はもっと簡単に済むかもしれません。

オープンソースにとって難しいこの時代に、あなたとあなたの組織が Embulk コミュニティへの支援を検討していただければ嬉しいです。

スターター・プロジェクト

ですがいずれにせよ、コミュニティの中で意思決定まで司るメンテナーの役割を、いきなりゼロから担えと言われても、多くの人にとっては無茶振りでしょう。

そこで、新しく参加したい人のための「スターター・プロジェクト」をいくつか GitHub Discussions に用意しています。

GitHub Discussions : Embulk : Contributors wanted

もし (長期的に) メンテナーとして参加することに興味をお持ちでしたら、まずはこれらのスターター・プロジェクトを見てみてください。それぞれ一定程度の作業量があり、なにかしらの意思決定をする必要もあります。まず Discussions 上で手を挙げていただいてから、既存のメンテナーと協力し、議論しながら、一緒に作業しましょう。プロジェクトを通じてコミュニティでの役割を広げてもらい、コミュニティの中で信頼が確立すれば、自然とメンテナーとして正式に入ってもらおう、ということになると思います。

Embulk と Treasure Data について

参考までに。もしかしたら Embulk とそのエコシステムは Treasure Data (TD) が所有・管理している、と考えていた方もいるかもしれません。ですが、そんなことは (少なくとも現在ではもう) ありません。ぜひ、その点については躊躇しないで考えてみてください。

もしそのあたりの経緯について興味があれば、こちらの記事などをご覧ください :

Embulk の今後と筆者について

さて、ここから先は、原文にはない追記です。

こういうアナウンスをいまになって出したのには、大規模改修 (Embulk v0.10 系) が終わって新しい人を受け入れやすくなったという理由もあるんですが、筆者が「そろそろ肩の荷をおろしたい」と思っているという理由もあります。

筆者が 2016 年に Embulk のメンテナンスを引き継いでから、もう 8 年ほど経ちました。目立った機能追加だとか見栄えのする変更だとかはあまりやっていないんですが、特に後半は「新しい Java に追いつけるようにする」とか「ライブラリを更新しても壊れにくいようにする」とか、ひたすら足回りを整えていた感じです。なんなら、足したものより消したもののほうが多いかもしれません。 JRuby とか。 (その細部は下の記事などご覧ください)

この改修をやらないと Embulk としても TD としても手詰まりになるのが見えていたし、自分で宣言した以上は、とやりきったんですが、いやー、まさか 3 年かかるとは。 (3 年は、各種の待ちを含めたリードタイムですが)

これはこれで良いチャレンジだったし、悪い時間ではなかったと思っていますが、そろそろ違うこともやりたいな、とも思うわけです。そしてここ 2 年近くは実際、勤務時間の半分で Embulk のメンテナンスをやり、もう半分で社内の別のプロジェクトの仕事をやる状態を続けています。でも、これをさらに何年も続けるのは、それはそれでやっぱりしんどい。

一方で、私が他の仕事に完全に移ってから「TD からメンテナーの後任を」という将来は、率直に言っておそらく望み薄です。本当に必要になったら誰かが「アサイン」されるかもしれませんが、プラグインのエコシステムとプラグイン開発者を含めたコミュニティに長期的に関わっている人は他にいないので、その後任とコミュニティの間は大きく分断されることになるでしょう。 (このへんの事情については下の記事など)

そうなったら、どこかで fork されたりしつつ縮小して自然消滅するしかないかな〜、という見立ても正直あります。が、これでもいちおう長年かかわってきたので、それもちょっと忍びない。仮に TD としてはそれでよくても (いいわけではないと思っていますが) Embulk を使っている人や企業が社外にそれなりにいることも知っていますし。

だからといって、そういう人や企業のために己を犠牲にしようとまでは思わないわけです。もちろん人は霞を食っては生きていけません。

Embulk の本体こそ TD のエンジニアが主にメンテナンスしてきましたが、特にプラグインのエコシステムは、もともとコミュニティで成り立ってきたものです。だからこそ仮に Embulk 本体を fork してもエコシステムがそれに着いてくるとはかぎらず、そのことこそが「メンテナーに異論があるなら fork して自分でやればいい」という、いわゆる「オープンソースしぐさ」を難しくしていました。

いざ本体がメンテナンスされなくなれば、誰かしらは fork するかもしれません。しかし現実的に、エコシステムが着いて行く見込みは薄いでしょう。最もありそうで、そして特に誰も幸せにはならない未来です。

そうであるならば、せめて誰かが引き継げる筋道を作っておくべきかなということで、社外の人も巻き込む仕組み (Core Team) を整えてみたり、そのオープンソース・プロジェクトとしての立ち位置を社内にも通用させてみたり、アーキテクチャについての記録 (特に大規模改修で変えたことと理由) をドキュメント (EEP) に残してみたり、ということをしてきました。 (上記記事などを参照)

このアナウンスは、その最終段階です。「自然消滅されては困る」「メンテナーとコミュニティが分断されるのも困る」という人や組織がいれば、その人たち自身にメンテナーになって続けてもらおう、ということですね。私が積極的に関与しているうちにぜひ参加して、コミュニティにおける発言権を確保しちゃってください。いまなら、レビューなども一緒にやりながら、それなりの時間をかけて引き継ぐだけの用意はあります。 ^[2]

もしそういう人も組織もいなければ、消滅に向かうのはむしろ自然なことでしょうから、あとはなるべくしてなるでしょう。

まずは

…というようなことを、この日本語訳を作る前にもごもごと旧 Twitter などでつぶやいていたのですが、そこで TROCCO の primeNumber さんから「会社も大きくなってきているので (Embulk に) 一定の投資をする意思決定もできるかもしれない」というご連絡をいただきました。

TROCCO の内部に Embulk を使っているのは以前からうかがっていますし、その primeNumber さんからメンテナンスに参加していただけるなら、コミュニティとしてもいわゆる Win-Win で、願ってもないことです。 (下記は primeNumber の中根さんによるアーキテクチャConference 2024 でのご発表)

具体的な関わり方はまだこれから相談していくところですが、やっぱりまずは前述のスターター・プロジェクトから触れてもらうのが入りやすいでしょうか、というようなお話をしているところです。これからを楽しみにしています!

まだまだ

といっても、一社に入ってもらって「めでたしめでたし」になってしまうと、「TD だけで本体のメンテナンスをしていたとき」と本質的な状況はあまり変わりません。いろいろな人や組織が関わってこそ、持続可能になるものと思います。

ということで、長期的に関わりたいという人や組織は、引き続き歓迎しています。まずはスターター・プロジェクトを見てみて、これならやれるかも、というところに、ぜひコメントを残していってください。

GitHub Discussions : Embulk : Contributors wanted

脚注

1. 彼らは当初 GitHub の activity を見える状態にしていたので、いろんなプロジェクトに送っている様子がよくわかりました。それだけなら熱意のある開発者や研究者に見えなくもなかったのですが、途中で彼らは activity を見えないようにわざわざ変更したのです。最終的にはそのことをもって、隠す必然性は他に思い当たらず、悪意があるものだろうという判断にしました。悪意のある人が「悪意ある?」という質問に正直に答えてくれることはもちろんないので、推測で判断するしかありません。

2. 私が手を離したあとでもメンテナーにはなれるんじゃないかと思いますが、決して読みやすいとは言えないかもしれない (ごめんなさい) ドキュメントとコードと履歴と、自力でにらめっこする羽目になるかもしれません。