Zenn
🧬️

ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)

2024/01/25に公開
#
middleware
#
OSS
#
opensource
embulk
#
ecosystem
idea

2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。

6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。

8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。

また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。

大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開された言語モデルが『オープンソース』と呼ばれがち問題 [1]」や、「言語モデルがオープンソースのコードのクローンをライセンス要件を満たさずに生成しがち問題」など、まだ課題はあります。

さて、この記事の筆者は "Open Source is in our DNA" をうたう Treasure Data (TD) という会社で、自社発の Embulk というオープンソース・ソフトウェアのメンテナンスを原作者から引き継いで、かれこれ 6 〜 7 年ほどメンテナーをやっています。「TD 発オープンソース・ソフトウェアのメンテナーをやっている TD の従業員」としては、いまではおそらく最長になったんじゃないでしょうか。

本記事は、オープンソースを前面に出した企業で、業務としてそのオープンソース・ソフトウェアのメンテナーを務めてきた一社員、という立場から共有できる経験があるかもしれないと思って、ここ数年の経験をつらつらと書いてみたものです。

Embulk について

Embulk と Treasure Data

Embulk は Treasure Data 共同創業者の古橋さんがオープンソースとして [2] 2015 年にリリースしたソフトウェアで、行列 (row-column) 形式の大きめのデータを、一括 (バルク) で、各種のデータベースやストレージから、別のデータベースやストレージに、転送するためのものです。

Embulk は、オープンソースのプロジェクトとしてだけではなく TD の中でも動いています。 Data Connector というサービスとして TD のサーバー環境で Embulk が動き、顧客の環境から TD にデータを取り込んだり、逆に TD のクエリの結果を顧客の環境に書き出したりしています。

Embulk は Data Connector として TD の内部に密結合しています。この点が、顧客の環境にインストールしてもらうことが主体だった Fluentd との大きな違いです。私は 2016 年の入社から長いあいだ、この Data Connector の開発・運用を主業務としながら、並行してオープンソースの Embulk のメンテナンスをしていました。

一方で Data Connector は TD のサーバーで動作するサービスなので、ネットワーク的に届かない環境にアクセスすることはできません。そのような場合に、顧客の環境の中でオープンソースの Embulk の利用をお勧めすることがあります。 (伏線)

Embulk とプラグイン

Embulk は、多様な転送元と転送先に対応するために「プラグイン」型の設計になっています。

Amazon S3 からデータ (ファイル) を読み込む embulk-input-s3 や CSV ファイルをパースする embulk-parser-csv のような parser プラグインに始まり、転送先として MySQL や PostgreSQL に書き込む embulk-output-mysql や embulk-output-postgresql など、いろいろなプラグインが本体 (embulk-core) とは別に開発・公開されています。

実は Embulk は、本体 (core) だけではほぼなにもできません。実際にデータを読んだり書いたりするのはすべてプラグインであり、プラグインは Embulk において必須の存在です。言い換えると Embulk は、「プラグインありき」のソフトウェアなのです。

世の多くの「プラグイン型ソフトウェア」では、プラグインはたいてい「付加機能」という位置付けにあります。それとは対照的だと言えるでしょう。

エコシステムと Treasure Data

これらプラグインは、すべてを TD が開発・メンテナンスしているわけではありません。 TD の外でもさまざまな方々がプラグインを開発して (多くはオープンソースで) 公開してくださり、それらを含めた全体として Embulk という「エコシステム (生態系)」ができています。

TD 以外の方が開発してくれたプラグインを TD の中で使わせていただくこともあります。前述のように顧客の環境で Embulk を使っていただくようにお勧めすることがあり、その中で社外のプラグインを使っていただくこともあります。つまり TD は「Embulk というエコシステムのユーザー」でもあるのです。

Embulk のエコシステム

TD は「Embulk というソフトウェアの本体」を世に送り出した企業ですが、「Embulk というエコシステム」を所有しているわけでもなければ、統制しているわけでもありません。 2024 年 1 月の時点で Embulk 本体のコミット権を持っているのは TD の人間だけ (現在は主に私) ですが、たとえばそれを笠に着て無茶な変更を強行すれば、社外のプラグイン開発者の方々から見放されて「Embulk エコシステム」はまるごと無価値になってしまうでしょう。

本体のコミット権こそ (まだ) TD で占有していますが、だからといって社内の Data Connector のことだけを考えて「エイヤッ」と Embulk 本体を変更すると、社外のプラグインが動かなくなったりします。実際に初期にはそういうことが何度もありました。近年はその反省もあって、特に本体とプラグインの互換性にかかわる変更について、積極的なプラグイン開発者と本体のメンテナー (私) の間でゆるく形成された「コミュニティ」で意思決定をするように試行錯誤を続けてきました。

ただ、この関係性と力学を正しく理解していた人は、残念ながら社内にもほぼいませんでした。

社内から Embulk や Data Connector に、機能追加の要望が来ることがしばしばあります。もちろんそれ自体は健全なことですし、そうした要望こそが (オープンソースにかぎらず) ソフトウェアを発展させるともいえます。

一方で、傍からは簡単な変更に見えても、その機能がどうしても既存プラグインに影響を与えてしまうことがあります。そのため「既存プラグインとの互換性の問題があるので、コミュニティでも相談しないとならないし、すぐの実現は難しいですね」とこたえざるをえないことがあります。

そうすると「すぐできないの?」「なんでコミュニティのことなんか気にしないとならないの?」「Embulk って TD のものじゃなかったの?」のような目を向けられたりします。同じエンジニアからでさえ、「こうすれば (社内のインフラが) 速くなるじゃん」と互換性ぶち壊しの変更をゴリ押されそうになったりもします。

仕事が社内で完結しないオープンソースのこのような関係性は、ソフトウェア・エンジニアではない人、オープンソースに縁の浅い人からは理解しにくいものでしょう。エンジニアであってさえ、チームが違っていたりプロジェクトに関わっていなかったりすれば実態は想像しにくいものです。しかし "Open Source is in our DNA" と言い切る組織の一員としては、これでいいのか、と歯がゆさを覚えてもきました。 (※後述するように Embulk では今はそれなりに状況が改善しています)

エコシステムの維持

さて、このような Embulk エコシステムを維持 (メンテナンス) していくには、ただ Embulk 本体 (embulk-core) のコードを黙っていじっていればいいわけではありません。

たとえば実行基盤である Java の更新に追従しなければなりません。そのためには、単に Embulk 本体が新しい Java で動くことを確認するだけでは不十分です。数多くあるプラグインをあたって新しい Java で動かなくなるものを調べ、動かなくなる条件を洗い出し、問題を本体で吸収するか各プラグインで対応するかそれぞれに意思決定し、必要であればプラグイン開発者にアナウンスし、さらに必要であれば個別にコミュニケーションを取り…、という一連のプロセスが必要です。特に Java 8 から 9 以降への更新はギャップが大きく、「たぶんもう大丈夫じゃないかなあ…? [3]」と言えるようになったのさえごく最近のことです。

Embulk は JRuby も使っていたので JRuby の更新も考えなければなりません。 Java は互換性をかなり気にする部類のプラットフォームですが、一方の JRuby は (Ruby という言語としてではなく JRuby という処理系実装として) 互換性をそこまでは気にせず、特に Java と Ruby の間をつなぐインターフェースにはわりと非互換が入ります。 [4]

JRuby のそういった情報をメンテナー一人でいちいち追いかけるのは難しく、結論として JRuby のサポートは第一線から落とすことにしました。しかしその「落とす」決定さえも容易ではなく、たとえばいきなりまったく動かなくするわけにはいきません。どういう段階を踏むか、移行期間はどうするか、どこまでサポートするか、どこからあきらめるか。技術的な実験をして、コミュニケーションを取って、コミュニティでも受け入れてもらえそうなラインを探って、最近ようやく着地点が見えてきた、くらいの状態です。 [5]

さらに Embulk は「本体で使っているライブラリのバージョンを上げるだけで、そのライブラリの非互換を直接には踏んでいなくとも、一部のプラグインが動かなくなる可能性が普通に予見される」という、変更に弱いアーキテクチャでした。世のライブラリには脆弱性問題などもあるので [6] もちろんいつまでも上げないわけにはいきません。かといって互換性問題の導火線に火が点きっぱなしのような状態では、ライブラリのバージョンを常に最新に上げ続けるような対応は、現実的にとれません。

業を煮やしてこのアーキテクチャそのものを変更する決断をしたのですが、そのアーキテクチャ変更自体が、一度は互換性を大きく壊さないと成立しません。一方で、すべてのプラグインを一斉に移行するような計画は、もちろん実行不可能です。移行を漸進的に進められそうな手法を探り、社外のプラグイン開発者の方々とコミュニケーションをとり、並行して社内で Embulk を動かしている環境の準備も進め、といった具合で、この計画を始めて (v0.10.0) から終わる (v0.10.50) まで結局 3 年かかりました。 [7]

そしてそんな中でも、機能要望は社内外からやってきます。そうすると、それを互換性を壊さずに実現する道筋はあるか、壊さざるをえないなら受け入れ可能そうな移行プランの選択肢にはなにがあるか、その機能単体では互換性を壊さないとしてもその機能が将来の拡張の邪魔になることはないかなど、内外とコミュニケーションを取りながら多くのことを検討しなければなりません。

「メンテナンス」の負担

Embulk のような「他の開発者が書いたソフトウェアを動かす基盤となる」ソフトウェア、いわゆる「ミドルウェア」のメンテナンスには、このように多くの苦労があります。

Embulk がオープンソースでなく単なる社内ソフトウェアであったなら、話はもっと簡単だったでしょう。大きなネックになっていたライブラリの更新にしたって、すべてのプラグインのライブラリを一気に上げてしまえば済んだ話なので、大変ではあっても 3 年はかからなかったはずです。

特に利害関係者が増えやすい「オープンソースのミドルウェア」のメンテナンスは、必要な機能開発の傍らに「ついで」でできる仕事ではないのです。このようなミドルウェアの「メンテナーを務める」ことは、オープンソースの既存のプロジェクトに一貢献者としてコミットすることとは、別物だといっていいでしょう。メンテナーの務めの大半は実際のところ、コミュニケーションと意思決定です。

以下に、「Linux メンテナーの燃え尽き (burn out)」について書かれた記事を引用します。

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

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

『「Linux」メンテナーの燃え尽き症候群問題--業務内容の変化と支援の必要性』 (Written by Steven J. Vaughan-Nichols / 翻訳校正: 村上雅章, 野崎裕子 / 2023-11-06 06:30) より引用

もちろん Embulk は Linux ほど巨大ではありません。利害関係者も Linux ほど多岐にはわたりません。それでも『メンテナーに報酬を支払おうというところはほとんど「ない」』『メンテナンスは日々の通常業務に加えて遂行する追加の作業となっている』『メンテナンスとは関係ないフルタイムの仕事を抱えつつメンテナーを引き受けている』というくだりには心当たりがあります。これは実際 Embulk とそれを世に出した TD においてすら例外ではありませんでした。

ビジネスとオープンソース

私が入社して Embulk のメンテナンスを引き継いだころは、まだ会社の規模も大きくなく、人事制度自体があまりカッチリしていませんでした。私の主業務は Data Connector 関連の開発と運用でしたが、当時は Embulk のメンテナンスも Data Connector の仕事の一部として (いちおう) 成立していたのです。

ただ、買収や分離を経て会社規模が大きくなり、人事評価制度などが整ってくるにしたがって、プロダクトの開発に付随していたオープンソース・ソフトウェアのメンテナンスは組織から置き去りにされていきます。ソフトウェア・エンジニアは「Treasure Data のサービス」というプロダクトへの貢献をベースに評価されるようになった一方で、残念ながらオープンソースとしての Embulk は「Treasure Data のサービス」では「ない」からです。

それでも上司は「オープンソースのほうのあれこれは全部まかせた!」と一任してくれており、オープンソースの Embulk のメンテナンスの中でも「Data Connector のために必要」という大義名分が立つタスクは、どうにか通常業務の一部として (オープンソースでなければ必要最小限だったであろう時間よりも多くの時間をかけて) 滑り込ませることができていました。

とはいえ、「余分に時間がかかる」オープンソースとしての仕事が評価の対象になることはありませんでしたし、それ以前に認知されることもありませんでした。そしてオープンソースとしてのメンテナンスは Data Connector の業務として「大義名分が立つ」タスクばかりではありません。たとえば Embulk の中の「Data Connector では使っていない部分」のメンテナンスを業務時間でやっていたら、「それをやって Data Connector がどう変わったんだっけ?」と聞かれるでしょう。業務時間でやったのに、それに対して「なんにもなってない」とこたえるわけにもいきません。 [8]

こうなるとさらに悪いのは、オープンソースとしての仕事をチームメンバーにお願いできなくなることです。社内で完結する仕事をしたほうが評価されることはみんなわかっています。私自身はオープンソースに思い入れがないこともないのでコミットを続けましたが、私はメンバーの評価をする立場でもなく、彼らにとって「タダ働き」になりかねないとわかっているのに「オープンソースのほうにもコミットして」とは言えません。こうしてオープンソースの仕事は、社内の「貧乏くじ」になっていきます。

私にしたって、自分が一から生み出したわけでもない「業務で担当することになっただけの」ソフトウェアに、プライベートの時間を注ぎ込んでまで「カネにもならない」メンテナンスを続けるのは、さすがに御免こうむりたいわけです。いくらオープンソースだからって、業務で担当するソフトウェアにすべてを捧げるつもりまではありません。プライベートの時間を割くならプライベートなりのことをやりたいですよね。

視点を切り替えて Embulk というエコシステムの視点から見ると、その創始者であり、本体のコミット権の占有者であり、私の雇用者でもある Treasure Data という会社は、善く振る舞えば「よいユースケースと実装の両方を Embulk に提案・提供できる善き貢献者」たりえるのですが、悪くすれば「無茶な要求をゴリ押しする利用者」や「エコシステムとしての Embulk を台無しにする破壊者」にもなってしまう、繊細な立ち位置にいます。

それにもかかわらず社内でオープンソース仕事が「貧乏くじ」になっていたということは、組織としての TD は、その従業員やチームが Embulk に対して「善き振る舞いをする」「善き貢献者である」インセンティブを与えられていなかった、言い換えれば Embulk というエコシステムに対して組織として払うべき負担を払えていなかった、ということでもあります。

負担を払うのは誰?

ことここに至ったのを読んで、「もう Embulk をオープンソースとしてメンテナンスするのを止めたら?」と思った方は少なくないでしょう。実際、そういう話は何度も浮上しましたし、なんだったら私自身から持ち出したことも何度かあります。

たとえば Embulk を Data Connector の一部として社内に fork して、クローズドで [9] 開発・運用すれば、「Treasure Data のサービス」としての開発効率はグンと上がりますし、やった仕事を評価しやすくもなるでしょう。コードレベルの互換性を壊すような変更だって、ずいぶんやりやすくなります。サービスの運用だけを考えたら、そうしない理由がない、と言ってもいいくらいです。オープンソースの Embulk はそのまま置いておいてもいいし、メンテナンスしたい人がいればおまかせしてもいいし、なんだったらさらに fork してもらったっていい。

数年前に Presto が PrestoDB と PrestoSQL (後の Trino) に分かれた [10] とき、社内にはその決定を残念に思う声や揶揄する声もありました。しかしなんのことはない、いつ同じようなことが自社内で起きてもずっと不思議はなかったわけです。 [11]

しかし実は Embulk について言えば、それすらも簡単ではありませんでした。それはこれまでにも触れてきた以下の事情によります。

  1. Embulk はプラグインなくしては何もできないこと、そしてプラグイン開発者に見放されれば Embulk エコシステム自体が成り立たないこと
  2. 顧客の環境で Embulk を使うことを TD としてお勧めすることがあること
  3. TD として "Open Source is in our DNA" をうたっていること

つまり TD 自身もユーザーとして「(他の Embulk プラグインを含む) Embulk エコシステム」に乗っかっているのに、そしてあまつさえ自社について "Open Source is in our DNA" などとうたってもいるのに、オープンソースとしてのメンテナンスを放棄してエコシステムを崩壊させるのは筋が通らないでしょう、ということです。

TD 自身が TD 以外の方が開発したプラグインと「Embulk エコシステム」のユーザーでもある

誰かがリーダーシップを取り、コミュニケーションを取り、意思決定をし、メンテナンスを継続する負担を払い続けなければ、エコシステムは保ちません。一方で TD は、オープンソースとしての Embulk エコシステムに対して、払うべき負担を払っていませんでした。誰もリーダーシップを取らずになんとなく「コミュニティ任せ」にしてもエコシステムは衰退するだけですが、だからといって TD の都合で勝手な変更を突っ込み続ければエコシステムが崩壊するだけです。しかも本体へのコミット権は TD が占有しているのだから、その負担を他の誰が払えるわけもありません。

オープンソースとしての Embulk エコシステムは、こうして身動きがとれない状態になっていました。

ミドルウェアの本体だけ作って満足し、その上に形成されるエコシステムの維持にコストを割けない様子は、ハードウェアだけ作って満足し、その上にソフトウェア・プラットフォームを醸成できないという、いつかどこかで見た景色とも似ていたかもしれません。

このころは TD のビジネスも様々に転回していた時期でもありました。マネージャーとも「もう少しオープンソースの仕事をちゃんと評価に含められるようにならんですかねえ」という話はしていましたが、「ちょっと寂しいけど難しいですよねー」という反応だったこともあって、率直な印象として「ビジネスの方向性もあるしオープンソースとか言ってられる段階ではないのかなあ」と感じていました。

Embulk v0.10

とはいえ、前述した「プラグインとの互換性を大きく壊す」大改修なしには、ライブラリのバージョンすら上げられません。このままでは社内の Data Connector の継続運用すらままならなくなるのが目に見えていたので、そういう大義名分のもとにどうにか大改修を始めました。これが、コロナ禍とほぼ同時に始まった (そして最終的に 3 年かかった) 前述の Embulk v0.10 系です。

この Embulk v0.10 系でやった技術面の具体的な内容については、現在進行系で EEP (Embulk Enhancement Proposal) という形式でまとめつつありますので、興味のある方はそちらをご覧ください。 (後述)

この大改修は、本体にある程度の変更を加え、「プラグインをこう書き換えれば新しい Embulk に対応できますよ」というアナウンスを出し、公式で管理しているプラグインを実際に書き換えてリリースする、くらいまではスムーズに進みました。実際 v0.10 を始めて 1 年と少しで、依存ライブラリ問題で最重量級だった Jackson に対処した Embulk v0.10.32 のリリースまでこぎつけています。

しかしそこからがなかなか進まなくなります。主な理由として以下の 3 点が挙げられます。 [8:1]

  1. Data Connector 用に社内で開発・管理しているクローズドのプラグインが 200 近くある [12]
    • 「プラグインとの互換性を大きく壊す」大改修なので、この 200 近くあるプラグインをすべて新しい Embulk に対応させないとなりません。
    • 社内のプラグインは私 (単体) ではなく Data Connector のチーム (複数) で開発しているのですが、それでも開発速度には限界があります。
    • 「これはいわゆる『ただの技術的負債・リファクタリング案件』に見えているかもしれないけど、早く進めておかないと (新しいフレームワークやライブラリに追いつく必要がある要件が来た瞬間に) なにもできずに詰む可能性があるよ?」という話はマネージャーともしていました。
    • が、それでもやってくる案件の優先度を下げられるわけではありません。
  2. フレームワークとしての Data Connector の実装が Embulk の内部構造に根深く癒着していた
    • Embulk の内側構造にちょっと手を加えると、オープンソースの Embulk としては普通に動くのに Data Connector としては意味不明に壊れる、みたいな状態でした。
  3. Embulk の中の「Data Connector では使っていない部分」にも手を付けざるをえなくなった
    • 前述のように、これを業務でやることを正当化するのがそもそも簡単ではありません。

結局、上記の v0.10.32 を社内の Data Connector で使い始められたのは、オープンソースとして v0.10.32 をリリースしてから、さらに 1 年後のことでした。プラグインを追いつかせる (#1) チームの仕事にも時間がかかりましたし、癒着を引き剥がす (#2) 私の仕事も難関でした。 [13]

さらに「オープンソースの Embulk としてここまでは作らないと一貫性がない、つまり Embulk として使い物にならないんだけど、でも Data Connector で使う予定はない」というところ (#3) をそれまで見なかったことにしてずっと後回しにしていたのですが、そこにも手を付けないといよいよ Embulk として話が進まなくなっていました。

メンテナンス体制の変更

この v0.10.32 のあたりまでは「Data Connector の仕事の傍ら」として Embulk のメンテナーをやるのも (自身をふくむ多方面に無理をかけながらも) ギリギリ成立しなくはなかったのです。が、その v0.10.32 を Data Connector にデプロイするのに 1 年かかったあたりで、この体制は完全に破綻しました。

これは実質的に TD という組織がオープンソースとしての Embulk エコシステムの足を引っ張っていたということでした。これでは "Open Source is in our DNA" なんてエラそうなことはとても言えません。 Embulk の使用を勧めた TD の顧客に対する誠意にも欠けていたと言わざるをえません。そして私個人としても「割に合わない」状態でした。

それでも 1 年の格闘ののち、最大の山だった v0.10.32 + α を Data Connector にデプロイするところまではたどりつきました。そしてちょうどそのころ、ふと私に人事異動の話があったのです。もともと「もう Embulk と Data Connector をやって 5 年以上になるし、この改善が一段落したら、そろそろちょっと違うこともやりたいっすねえ」という話はしていて、それが少し早まったような形です。

Data Connector としてもやり残していることはまだ (たくさん) あったので、考えるところはあったのですが、紆余曲折を経てこれを「半分」受けることにしました。この「半分」とはどういうことかというと、現在は半分の時間で社内の別のチームで別のプロダクト開発に入りながら、もう半分の時間で (Data Connector とは独立に) 「オープンソースの Embulk のメンテナー」をやっています。

それと同時に、オープンソースの Embulk プロジェクトとしても、明示的にメンテナンス体制を変えました。もともとメンテナンス体制に無理があったわけで、この異動はそれを変えるのにちょうどいい機会かもしれない、と思ったからです。

Data Connector との分離

まず、自分の人事異動をちょうどいい機会として「オープンソース Embulk のメンテナー」と「Data Connector の開発」を人事的にも分離してもらいました。

前述してきたように、「オープンソースの Embulk をメンテナンスする立場」と「Data Connector というプロダクトを開発する立場」は、残念ながらしばしば対立関係になります。「オープンソースの Embulk」が社外の利害関係者をまじえたエコシステムである以上、この対立に恒久的な解消はありません。それまでは、私という一つの人格が複数の顔を使い分けながらこの対立を調整せざるをえなかったのですが [14] これは個人の負荷としても人事評価としても長く続けられるものではありません。これが第一の無理でした。

この二者を人事的に分離することで、プロジェクト進行において対立があれば、その対立は形として明確になります。対立が避けられないのであれば、その対立を個人の責任に押し込むより、対立があることを明確にしたほうが健全です。組織としての対応もできるようになるでしょう。

そして、これによって純粋に「オープンソースの Embulk エコシステム」のことを考えてコミットできるコミッター (私) が誕生しました。「Data Connector で使うことはない」ために後回しにされてきたところにも手が回るようになり Embulk としてもいい結果につながりましたし、私にとっても Embulk への貢献が正当に人事評価されるようになって幸せな結果です。

ただし念のため、これはもちろん Data Connector チームをオープンソースの Embulk から排除したものではありません。後述する Core Team にも Data Connector チームのメンバーが入っています。しかし「オープンソースの Embulk」をメンテナンスする立場の私と「Data Connector を開発する立場」のチームの間で立場を明確にした議論を持つほうが、双方にとって有益で建設的な改善につなげられるでしょう。

また、オープンソースの Embulk プロジェクトにおいて Data Connector チームが「善き貢献者」として振る舞えるようになるには、まだ慣れと時間、そしてマネジメントと評価体制の準備が必要です。この新しい関係性が、そのための準備・練習期間として機能することを期待してもいます。

Core Team と EEP

さて、この分離によって Embulk エコシステムの状況はマシにはなりました。それでもまだ TD の中に閉じた話でしたし、結局 Embulk の立場に立っているのは私一人だけでした。たとえば私が Embulk から手を離せば元の木阿弥ですし、企業としての方針も、この先いつ "Open Source is in our DNA" じゃなくて "Open Source is our junk DNA" にならない保証もありません。 (そんなことはしないと信じてはいますが)

エコシステムの利害関係者であるプラグイン開発者の方々を置き去りにしながら、本体は TD が独占的にメンテナンスしている、という状態がそもそもいびつだったのです。かといって、いまさらプラグイン開発者の方々を抜きにエコシステムは成立しません。これが、第二の無理でした。であれば、必然的に「TD が独占的にメンテナンスしている」状態のほうを変えるしかありません。

このいびつさは構造的なもので、「TD が Embulk の根っこ (本体) を握っている」かぎり、変わりません。もちろん関係者が「善き貢献者」であれるように、私も努力しますし組織としての TD もそうすると信じています。ですが、根本的な解決は「TD 外のプラグイン開発者の方々にも明示的に『Embulk の中の人』になってもらう」ことでしょう。そうでなければ、同じことが起こるリスクはいつまでもなくなりません

そんなわけで Embulk では "Core Team" という体制を明示的に作りました。これは社外でも主要なプラグインの開発者の方々に声をかけて入ってもらった [15] ものです。本体のコミット権を持っているのはまだ私だけですが、まずは私が本体に加える変更を監視 (レビュー) してもらうチームとしてスタートしました。コミッターが「善き貢献者」でいることを確認してもらい、同時にプラグイン開発者の方々に形式的にも「中の人」になってもらうことで、メンテナンスの責任を分散・分担するものです。いずれ Core Team からコミッター・メンテナーになる人が現れることを期待してもいます。

Embulk Core Team

さらに Embulk の本体に大きめの変更を入れるための明示的なプロセス (EEP: Embulk Enhance Proposal) を整えました。これは、特にプラグインとの互換性に影響があるような変更に対して、「なぜそれが必要なのか」「誰がどう使うのか」「プラグインとのインターフェースはどう変えるのか」「移行はどういう手順で進めるのか」などを明示的なドキュメントにして Core Team で確認・承認してもらうものです。

また、私が既に v0.10 で入れてきた数々の変更についても、同じ形式で "Retrospective" EEP という形でドキュメントに残す活動を進めています。

視点を切り替えて社内の Data Connector チームの立場に立つと、これらは外部要因が加わることで進捗管理をやりづらくする変更でしかなく、開発速度を落とすもののように見えたかもしれません。ただそのやりづらさは、もともとずっとそこにあったものを、私が一人で吸収していたものです。チームには、人事評価などのマネジメントもふくめてそのチームのやりかたで、「オープンソースのエコシステムに向き合う」覚悟を決めてもらいましょう、ということになりました。 (具体的なやりかたはまだ試行錯誤があるところです)

"Open Source is in our DNA"

Treasure Data には、オープンソースに深くかかわるソフトウェア・エンジニアが大勢います。

  • Ruby のコミッターが 5 人いる (2024 年 1 月時点)
  • 自作の OSS を持つ人も多い
  • 企業としても Hive や Presto (Trino) などをフル活用し、貢献もしている

しかし実は、「組織として」オープンソースに向き合うことができていませんでした。それはむしろ、それぞれが個人としてあまりに日常的にオープンソースに触れていたがために、そんな発想が頭から抜け落ちていた、ということだったのかもしれません。

特に Embulk のような「エコシステムをともなうミドルウェア」は、誰かが責任を持ってリーダーシップを取らなければ、なにも動きません。そして、そういうリーダーシップはタダではありません。エコシステムの維持を組織として望むのであれば、その負担を組織として払う必要がありました。

この Embulk の事例が示したのは、「『オープンソースを自らの DNA に刻み込んじゃった個人』をただ集めただけでは、組織の DNA にも自動的にオープンソースが刻まれるわけではない」という示唆であったように思います。組織の DNA にオープンソースを刻みたいのなら、そのように設計して組織を作らないかぎりそうなることはない、と言い換えることもできます。

そして (特にオープンソースの) プロジェクトに自分たち以外の「利害関係者」がいるのならば、その関係性が単なる開発者とユーザーの関係にとどまらないのならば、下手にプロジェクトの主導権 (コミット権など) を握り続けようとせずに、利害関係者にもちゃんと「中の人」になってもらったほうがいい、という学びもありました。これは「オープンな開発はよいことだ」のようなきれいごとではなく、そうしないとプロジェクト自体がいびつになって立ち行かなくなってしまうという、リスクの問題です。

本記事では、一つのオープンソース・プロジェクト (Embulk) について企業の従業員という立場でやってきたこと、その中で感じた限界、そして組織・人事的な改善や、オープンソース側でのメンテナンス体制の変更について紹介しました。これらの変更を経て Embulk は「大改修」だった Embulk v0.10 系を完了して v0.11 系を始めることができ、さらに v1.0 のマイルストーンを計画できるところまでやってきました。

しかし、これが本当に最終的な正解だったのかはまだ誰にもわかりません。これからも引き続き、個人としても組織としても、プロジェクトのいい進めかた・継続のしかたを考えていくことになるでしょう。

また、本記事の内容はあくまで Embulk という特定の一つのプロジェクトにおける例でしかありません。プロジェクト自体の特性や関係者によって、どういうやりかたが合うかはまったく異なってくるでしょう。 Embulk と同じやりかたを他のケースにそのまま適用できることはまずないと思いますが、一つの事例として、どなたかの参考になることがあれば幸いです。

Embulk の今後

ところで「具体的に Embulk は今後どうなるの?」というところが気になっている方もいると思いますので、少しだけ。

「委員会制」

この記事を読んで「Core Team ってつまり『委員会制』だよね」と思った方も多いのではないでしょうか。そしてそれは率直に、そうなんだと思います。

遠藤：とりあえずこの3年は今やっているTypeProfをちゃんと動くようにすることに注力したいですね。それと、Rubyの開発体制が3年から5年ぐらい先に変わるかもしれなくて。RubyKaigiのRuby Committers and The Worldの中でまつもとさんが委員会制を使った言語仕様策定を試したいと言ってたんですよね。それが2025年だっけ？

笹田：わからない。

遠藤：そんなに遠くない未来に試される可能性があって、単純に委員会制にすると保守的な判断しかできなくなるんですね。そうするとRubyの進化が止まってしまうし、それはまつもとさんも嫌だと思ってるだろうし。

「Rubyが楽しくて良い言語になることが STORES の未来につながる【STORES.rb × Asakusa.rb 文字起こしレポート】」 (STORES Product Blog / 2023-12-26) より引用

世の中のデータ基盤の構成って、ぶっちゃけた言い方をすれば、もうけっこう成熟しているんですよね。そしてその部品となる Embulk のような個々のツールは、革新よりも安定して動き続けることを求められる段階にあると思います。

Embulk が良い部品として安定・継続するためには、「中の人」がついうっかり勢いあまってぶっ壊すよりも、この Core Team のような形式のほうが合っているでしょう。私としても、いまからあまり画期的なことを Embulk のエコシステムの中でやろうとは思っていません。 (Data Lineage 対応とか、レポーティングとか、キーになりそうな基盤機能については構想がないわけではないのですが)

コモディティ

つまり Embulk は、ある種のコモディティになっていると言っていいでしょう。こう言うと、特に新しいもの好きのソフトウェア・エンジニアの方々は「なんだつまんないな」と感じるかもしれません。

ですが、個人的には「コモディティ上等」と思っています。

コモディティにするということは、極端な言いかたをすれば「塩漬け」にするような側面もあります。しかし、正しく「塩漬け」にするのって実はけっこう難しいんですよね。自由水が残っているとすぐ腐っちゃう (※比喩) [16] ので。

前述の JRuby や Jackson が、この自由水にあたるものだったと喩えることもできるかもしれません。そういうところを上手に削ったり隠したりして、必要なところをアップデートしながら、複数の人の手を入れながら、「塩漬け」のインフラとして長く維持するというのも、技術的にはなかなかチャレンジではあるのです。

コンパクトなツールとして

長期的なメンテナンスに方向性を切り替えるにあたって、ツールとしての機能をいくつか削ってもいます。たとえば JRuby のサポートを第一線から落としたのもそうですし、他にもコマンドラインで embulk run example.yml のように実行することもできなくなる予定です。代わりに java -jar embulk-0.11.2.jar run example.yml のように java のコマンドラインを自分で組み立ててもらうことになります。

初期の Embulk は「手元で手軽に実行できるツール」であることを目指した設計になっていましたが、現在でもそういう使いかたをしている方はどれほどいるでしょうか。ほとんどのユースケースでは、データ基盤の一部としてサーバーで Embulk を動かしているのではないでしょうか。

「手元で手軽に実行できる」ユーザーフレンドリーさを維持し続けるのは、そんなに簡単ではありません。 embulk run ... のコマンドラインの中ではシェルスクリプト (またはバッチファイル) が java を起動しているのですが、新しいバージョンが次々に出てくるようになった Java のコマンドラインに一つ一つ対応し続けるほどの価値は、もうあの「手軽な」コマンドラインにはないだろう、と判断しました。

Embulk はこのように、「ユーザーフレンドリーな単体で使いやすいツール」から、「データ基盤の部品としてメンテナンスを続けやすいコンパクトなツール」へと、方向性をシフトさせています。

ユーザーフレンドリーなツールが欲しい向きには、生の Embulk をそのまま使うよりも、たとえば trocco さんのように Embulk を内包したサービスを上手に使ってもらうほうがいいかもしれません。

メンテナー求む

このように、かかる手間を減らしながらどうにかメンテナンスを継続していますが、今も「メンテナー」が私一人であることには変わりありません。ここまで読んできてもらえた方なら、たとえば私が同僚に「あとはまかせた!」といきなり丸投げしても、メンテナーとして機能しないだろうということは想像できると思います。メンテナーの主な役割は、コミュニティ (主に Core Team) とのコミュニケーションと、過去の経緯やプラグイン環境を踏まえた意思決定です。つまりコミュニティと構築してきた信頼関係こそが重要です。コミット権を渡して一ヶ月でコードの説明をしただけでは、信頼関係は引き継げません。

そうは言っても、私もメンテナーをもう 6 〜 7 年もやっています。さすがに私にもちょっと飽きが来ているというか、そろそろ少し肩の荷を下ろして他のことをやりたくもあるのです。もちろん Embulk のユーザーさん目線では「引き継ぎできる人を TD の中で探して少しずつでも引き継げよ」と感じると思いますし、そういう準備も少しずつ始めてはいます。しかしここまで読んできた方は、「TD が Embulk の根っこを握っている」状態が既にリスクだ、とおわかりではないでしょうか。

Embulk v0.10 の間は大規模改修が進行中で、最中に新しい人に入ってもらうのは難しかったのですが、それも v0.11 に入って落ち着きました。

そういうわけで、「一緒に Embulk のメンテナーをやってくれる人」を TD の外からも探し始めています。

Embulk 本体のメンテナー

ただこれは、新機能の提案のような一過性の貢献を募集するものではありません。「プルリクエストお待ちしてます!」のようなノリではありませんし、「この『俺の考えた最強の○○』を入れるべき!」のような一方的な提案は求めていません。ひとたびプラグイン互換性やデータの正確性に影響しようものなら対処が非常に大変ですし、そうして入ってしまった機能をずっとメンテナンスし続けるのはメンテナーなのです。

このメンテナー募集は、「Embulk というエコシステムの維持のために継続的・長期的に関与してくれる方」を探しているものです。なにか新機能の提案をしていただくにしても、「『Embulk エコシステム全体のために』ここがこうなっているといいと思うんだけど」という出発点の提案を期待していますし、なんならその機能の担当メンテナーとして末永く面倒を見続けてもらうのが理想的です。 [17]

ですので、個人として思い入れのある方に入っていただくのももちろん歓迎するのですが、社内で Embulk を使っている企業から正式に労働時間を割いて参加していただくのが、一番いいかもしれません。たとえば「社内のサービスやデータ基盤として Embulk をガッツリ使っているから Embulk のエコシステムが衰退しちゃうのは困る」という企業が、「Embulk エコシステムを衰退させない」ために、長期的なメンテナンスの負担を企業としてリソースを割いて分担しつつ、自分たちの使いかたにとって都合のいい変更をちゃっかり提案して入れちゃったりもする、そんな「利害関係者」としての関係をエコシステムの中に構築できるのが健全だろうと考えています。

もちろん、新しく入ったメンテナーの方々が塩漬けをやめて大きな変更を入れていくことに積極的であれば、私が前述したような方針はやめて大きく変えていく方向に舵を切ることになるかもしれません。そのようなことも、長期的に責任をとる意思があるメンテナー同士で話し合って決めていくことになるでしょう。

ここで再び、「Linux のメンテナー」について書かれた記事を引用します。

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

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

新陳代謝

「委員会制とかコモディティとかそんなヌルいこと言ってたら、新しく出てくるソフトウェアに負けちゃうんでは」のような意見もあるかもしれません。

ですがこれについては、率直に「そうやって新しいものが出てくるのなら素直に世代交代すればいいだろう」と考えています。時代が移り変わるとともに Embulk にも「時代にそぐわない」面は既に出てきていますし、行列 (row-column) 形式のデータを一括 (バルク) で転送、というやりかた自体がいずれ廃れるかもしれません。そうなったとき、ユーザーをつなぎとめるために無理な延命をしてもしかたないでしょう。

もちろん、いま使っている人が困らないような更新は継続できるといいですし、ユーザーの存在はエコシステムに貢献する人のモチベーションにもつながります。一方で、ユーザーが他のツールに離れていくことで新陳代謝が起きるのなら、それは健全なことでもあります。 [18] [19]

データ転送という文脈でも Fivetran や Airbyte のように Embulk より新しいものが (SaaS 含め) 出てきています。そういった領域に新しくチャレンジする人が出てくるのも、ユーザーにとっては新しい選択肢ができるのも、良いことでしょう。

もっとも、私が Embulk のメンテナーを続けてきた理由には「『その中にオープンソースの選択肢が存在する』ことが世の中にとっても重要なことだ」と信じてきた、というのもあります。ですので、せっかくなら他にもオープンソースの仲間が出てこないかな、とも思っています。 [20]

いまからプラグイン的な仕組みを作るのであれば、前述の Airbyte のような Docker ベースは非常におもしろいアプローチだと思いますし、他に WebAssembly ベースなんかもアリかもしれませんね。

Embulk が出色だったのはそのプラグイン・インターフェース (SPI) を上手に定義したことだったと、何年もメンテナンスしてきた中で、個人的には感じています。別の見方をすると、近いものを作ろうとした場合でも、本体に本質的に必要なものは「規模」だけならそんなに大きなものにならないような気がします。個人で作ってみるのもおもしろいチャレンジになるでしょう。

ただここまで延々と述べてきたように、その作ったものを本格的に継続運用しようとしたら、ほんとうに重要なことは「プラグインとその開発者を含むエコシステムを維持するコストを長期的にかけ続けることができるか」にあります。その問題に対する画期的なアプローチがあったら私も見てみたいので、ぜひ教えてください。 :)

後編…?

さて、実はこの記事のタイトルは「前編」になっているのですが、「後編」はまだありません。

後編では、こういうめんどくささをなるべく避けるための、組織やプロジェクト運営上の工夫ではない「技術的なアプローチ」はあるのか、みたいな話をできたらいいなと思っています。が、いつになるか正直わかりません。もし後編を読んでみたくなった方は、期待しないでお待ちください。

脚注

  1. 個人的には、自分が書いたわけでもない多くの文章から学習した結果である言語モデルにおける「ソース (source)」ってなに? というあたりに、そもそも疑問があったりしますが。閑話休題。 ↩︎

  2. Apache License 2.0 です。 ↩︎

  3. "Embulk v0.11 is coming soon" -- Support for newer Java ↩︎

  4. 例: 「Java のクラスを継承した Ruby クラスのコンストラクタの中で条件分岐して super() を呼び分けるようなことが、以前の JRuby ではできたけど JRuby 9.3 以降はできなくなったよ」 みたいなこともあり、「いやわかるんだけどさあ…」と思いながら Embulk に非互換変更として入れたりしました。 ↩︎

  5. このあたりのことは EEP-6: JRuby as Optional というドキュメントに残してあります。 ↩︎

  6. Log4Shell とかありましたね。 ↩︎

  7. このあたりのことは TreasureData Tech Talk 2022 で話したり EEP-7: Core Library Dependencies というドキュメントに残したりしてあります。 ↩︎

  8. このあたりのことも TreasureData Tech Talk 2022 で話したり、その内容を Embulk in TD, and in the future というブログに残したりしてあります。 ↩︎ ↩︎

  9. 実はクローズドにまでする必要はありません。オープンはオープンなままで、ライセンスもオープンソースのままで、「開発プロセスはクローズドで上流 (upstream) はあくまで社内です」「プルリクエストは受け付けません」「互換性は保証しません」と宣言するだけでも、この目的にはかないます。 ↩︎

  10. Presto Software Foundation Launches to Advance Presto Open Source Community ↩︎

  11. Presto の件は、個人的には「どこも大変ですよなあ…」と共感しながら見ていました。 ↩︎

  12. そもそも、プラグインがこんなに増殖する前に早く手を付けたかったんですけどね…。 ↩︎

  13. 例: Data Connector の中には「REST API サーバーとして 1 つの Java プロセス内で Embulk を繰り返し動かす」というそもそもおかしなアーキテクチャのサービスもあったのですが、これが内部的にメモリリーク (クラス・ローダーのリーク) を起こしていて、いわゆる「修正」で済む範囲では根治不可能とわかったので、このサービス自体をほぼ一から再構築したりしました。 ↩︎

  14. これをずっと続けてると、わりと人格ゆがみそうになります。 ↩︎

  15. 巻き込んだ or 引きずり込んだ、とも言います。 ↩︎

  16. 「水分活性について ～ 食品の保存性パラメーター ～」 日本食品分析センター (2003 年 10 月) ↩︎

  17. 「TOMOYO Linuxに学ぶ説得術」 という、「Linux のメインラインに TOMOYO Linux というセキュリティ機能の提案のやり取りをレビューしてもらった記録」があります。 Embulk とは関係なく、オープンソースのプロジェクトにコミットしたいときに役立つ姿勢が書かれているので、おすすめします。 ↩︎

  18. Preferred Networks 社が自社開発の Chainer を自社で開発・使用し続けるのをやめて PyTorch に移行したというニュースが数年前にありましたが、その決断をできるのは良いことだなあと思ったものです。 ↩︎

  19. 私がこう考える背景には、「頑張って『オープンソースの Embulk のユーザー』を増やしたり維持したりしても TD のビジネスには特に関係がない」という事情もあります。ですので「Embulk のユーザーを増やす」ために貢献してくれる人が (TD の外に) いてくれるのなら、それ自体は歓迎しています。私からユーザーサポートにまでは手が回りませんが。 ↩︎

  20. Airbyte がいわゆる「OSI 認定のオープンソース・ライセンス」を止めてしまったのは、個人的には残念に思っています。が、彼らが (TD と Embulk の関係とは違って) それ自体でビジネスをしている以上、それはしかたないことかなあ、とも思っています。 ↩︎

Discussion