オープンソースに本格的に関わり始めたのは今年の下半期からだ。まだ日は浅いが、関心のある分野がはっきりしていたので、かなり熱心にイシューを読んでPRを出してきた。そんな中、10月にOpenTelemetryのガバナンス委員会の選挙で投票するようにというメールが届いた。会社でも国でもないオープンソースのプロジェクトに選挙があることも、貢献を始めてまもない自分にも、地道に活動してきたおかげで票が与えられたことも、そのとき初めて知った。
10月22日に届いた投票への招待メール。過去1年間にGitHubでコメントやコードレビュー、PRなどで20件を超える貢献をした人に声をかけていると書かれている。
調べてみると、オープンソースには思っていたより多くの投票があり、10月のひと月だけで三種類に出会った。新しいコミッターを選ぶ投票と、リリースを正式に出すかを問う投票、そしてプロジェクトの運営を任せる人を選ぶ選挙だ。このうちコミッターの投票は結果の告知で見ただけだが、残りの二つには自分で票を投じた。ガバナンス委員会の選挙で投票したのは今回が初めてだった。
#コミッターを決める投票
FlinkのようなApacheソフトウェア財団のプロジェクトでは、コミッターはコードを直接マージする権限を持つ人で、誰をコミッターにするかも投票で決める。ただし、この投票は外からは見えない。Flinkの規約では、プロジェクト管理委員会(PMC)が非公開のメーリングリストで3日以上かけて投票する。活動中のPMCメンバーの賛成が3票以上あり、かつそのPMCメンバーから正当な理由を伴う反対が1票も出なければ可決となる。そうした反対なら、1票だけでも拒否権として働くわけだ。
外から見えるのは結果だけだ。10月21日、Flinkの開発者メーリングリストに新しいコミッターを知らせる[ANNOUNCE]メールが届き、お祝いの返信が次々と連なった。私も先に付いた返信の形式にならって、短いお祝いの言葉と名前を書いて送った。
10月21日に届いた新コミッターの告知と、翌日未明に私が送ったお祝いの返信。
#リリースを決める投票
リリースを出すかを問う投票は、公開の場で開かれる。リリースマネージャーは、正式な配布の前に検証してもらう配布物である候補版をアップロードし、件名が[VOTE]で始まるメールを開発者メーリングリストに送る。参加者はその候補版を実際にダウンロードして確かめたうえで、+1か-1で返信する。Flinkの規約では投票期間を3日以上設けることになっており、可否を判断するときに数えるのは活動中のPMCメンバーの票だけで、これをbinding票と呼ぶ。bindingの賛成が3票以上あり、bindingの反対より多ければ可決で、それ以外の人も検証の結果を書き添えて票を投じることができる。
10月21日には、Flink Agents 0.4のリリースを控えて確認作業をしていたところ、JDK 17でビルドした配布物でJava側のチャット呼び出しが失敗する問題を見つけて修正した。27日には最初の候補版の署名とチェックサムを確かめ、ソースがタグと一致するかを比べてから自分でビルドしてみたが、そのときに、自分が直した箇所に必要なクラスが配布ファイルに含まれているかもあわせて見た。ところが28日になって気づくと、肝心の投票メールは迷惑メールフォルダに入っていた。
返信には、可否の集計には数えられないnon-binding票であることを明記した+1とともに確認した項目を書き、最初から最後まで通して動かす機能テストはしていないことも書き添えた。以前のバージョンから移行するときに、進行中だった作業の状態が復元されないケースも見つけたが、今回のバージョンで新たに生じた問題ではないので、リリースを止める案件としては挙げなかった。代わりにアップグレードの案内に一行足すことを提案し、次のバージョンで自分が直してみると書いた。
投票は反対なしで可決された。結果のメールには賛成7票のうちbindingが4票と書かれていて、私の名前はnon-bindingの側に載っていた。
10月29日に届いたFlink Agents 0.4.0の最初の候補版の投票結果メール。
#ガバナンス委員を選ぶ投票
OpenTelemetryのガバナンス委員会は、新しいプロジェクトの提案を検討して優先順位を決め、公開ロードマップを管理する機関で、その委員を選ぶ投票は三つの中で最も選挙らしかった。投票権も、私が自分で申請してもらったものではない。過去1年間にOpenTelemetryのGitHub organizationに残した貢献が、PRにイシューとコメントまで合わせて20件以上あれば投票権が得られる。担当領域の貢献をレビューして承認するapproverと、サブプロジェクトの技術的な方向を決めるメンテナーにも投票権がある。名簿は自動で集計され、基準に届かない貢献者は例外を申請できる。
10月21日に反映された公開の投票権者名簿には837のアカウントが並んでいて、その中に私のIDもあった。私のIDの横に集計されていた貢献は29件だった。
候補者10人は全員が自ら名乗り出た人だ。とはいえ自薦だけで候補になれるわけではなく、ほかの2社の投票権者から支持のコメントをもらう必要があり、一つの会社の人が委員会を占めないようにする上限もあった。選挙期間中には、候補者の一人から意見を尋ねるメッセージを直接受け取りもした。
投票はHeliosというオンライン投票システムで、韓国時間の10月26日午後9時から29日午後8時59分まで開かれた。
四つの席を埋める候補を最大4人まで選べた。私は締め切りの数時間前までかけて10本の公約をすべて読んだ。ガバナンスと聞いて規則や投票くらいを思い浮かべていたが、公約が扱う範囲はインストールパッケージやデモアプリから、モデレーションのポリシーやイベント、隣接するプロジェクトとの関係まで、ずっと広かった。
まず目に付いたのはAIだった。私が数えたところでは、自己紹介と公約でAIやエージェントに触れた候補は10人中6人で、メンテナーの時間を守るという約束は、私の基準では5人の公約に入っていた。エンドユーザーの導入を支援するという公約も何本かあり、米国赤十字で働く候補は、米国の血液供給の40%ほどを担う血液事業にOpenTelemetryが中核の構成要素として入っていると紹介していた。
いちばん長く心に残ったのはレビューの話だ。ある候補は、自分が率いるグループの月間PRがこの夏に4倍近くまで増え、レビューが追いつかなかったと書いていた。メンテナーの燃え尽きを冒頭に置いた候補は、共通のツールと自動チェックで繰り返しの作業を減らそうと書いていた。
#投票を終えて
OpenTelemetryガバナンス委員会選挙の公式な結果の記事は米国の日付で29日に公開され、私は韓国時間の30日朝に確認した。投票権者の41%が票を投じ、得票の上位4人が新たな任期を務めることになった。といっても、得票の多い順に無条件で選ばれるわけではない。憲章は同じ会社に所属する委員を同時に2人までに制限していて、この上限は任期が残っている委員まで含めて数える。上限を超える候補は、得票が多くても飛ばされ、次の順位の候補が席を引き継ぐ。今回は上位4人の会社がそれぞれ異なり、任期が2027年まで残る委員たちの会社とも重ならなかったので、得票順のまま決まった。
誰が選ばれたかとは別に、公約に出てきたレビューの話は最近多くのオープンソースのプロジェクトが共通して抱えている現実でもある。今年6月にKubernetesのブログに載った記事も、AIでコードを作るのは速くなったが、コードベースを保守する作業はほとんど楽になっていないと指摘していた。OpenTelemetryでもPRの増えるペースにレビューが追いつかないと書いた候補がいたし、プロジェクトの生成AIポリシーは、メンテナーとapproverの時間をきわめて乏しい資源だと書いている。だからといってAIを使うなというポリシーではない。うまく使えばコードやドキュメント、テストを書くのに役立つ道具だとしたうえで、モデルが作った内容をそのまま貼るより、英語が完璧でなくても貢献者自身の考えを聞かせてほしいと求めている。
実際、私もAIの助けを借りて貢献している。英語でイシューを書いたり、初めて見る大きなコードを読んだりする負担を、AIがずいぶん軽くしてくれる。PRを出すときは、何を自分で動かして確かめ、何を確認できなかったかを本文に書くようにしていて、リリース投票の返信で確認した項目としていない項目を分けて書いたのも同じ習慣からだ。公約を読んでみて、この習慣はオープンソースでこそ大事なのだと思うようになった。会社ならレビュアーと文脈を共有し、隣の席で聞くこともできるが、オープンソースのレビュアーは初めて見る人のPRを自分の時間を割いて読む。だからコードとPRの説明だけで変更の意図が伝わるように、最初からレビューする人のために書かなければならない。
#参考資料
- Flinkの規約。リリース投票とコミッター投票について、投票権を持つ人と期間、可決の基準を定めた規約。
- 2026年OpenTelemetryガバナンス委員会の候補者公約。候補者10人が自分で書いた経歴と公約をまとめたページ。
- OpenTelemetryガバナンス憲章。委員会の役割と投票権の基準、候補者の支持要件、会社ごとの上限を定めた憲章。
- Open source maintainership in the age of AI。AIで増えた貢献に合わせて、Kubernetesのコミュニティがポリシーとレビューのやり方を変えてきた過程をまとめた記事。
- OpenTelemetryの生成AI貢献ポリシー。AIを使った貢献について、メンテナーの裁量と貢献者の責任を定めたポリシー。