# OpenTelemetry のメンテナーシップを推進する理由

Site [llms.txt](/ja/llms.txt)

---

OpenTelemetry の最大の制約はアイデアでもコードの貢献でも採用でもなく、メンテナーだと私は考えています。

> [!NOTE] 筆者について
>
> 私は2021年初頭から OpenTelemetry に携わっています。
> opentelemetry-java、opentelemetry-configuration、opentelemetry-injector のメンテナーであり、技術委員会（Technical Committee）のメンバーでもあります。
> その間、New Relic と現在の Grafana Labs という2つのオブザーバビリティ企業で、OpenTelemetry に取り組みながら、それに依存する社内のエンジニアリング活動にも従事する役割を担ってきました。
> この投稿は、さまざまな OpenTelemetry プロジェクトへの関与と、さまざまなコントリビューターが出入りするのを見てきた経験に基づく私個人の意見です。

メンテナーは、プロジェクトを動かし続けるための地味だが継続的な作業を担っています。
リリース、トリアージ、イシューやプルリクエスト（PR）のレビュー、セキュリティアドバイザリ、メンタリング、ユーザーの信頼の維持など、多岐にわたります。
すべての貢献には意味がありますが、メンテナーはそれらをつなぎ合わせ、他の貢献を可能にする結合組織です。
メンテナーがいなければ、他の貢献がリリースされることはありません。

OpenTelemetry はほぼあらゆる側面で成長してきました。
コントリビューター、貢献、リポジトリ、採用のいずれも増加しています。
しかし、メンテナーの数はその成長に追いついていません。
レビューを何週間も待った経験がある方は、このことを実感しているでしょう。

この問題を正確に測定するのは難しく、さまざまな交絡因子があります。
メンテナーシップの経時的なデータが不足していること、自動化された PR（例: Renovate、Dependabot）やレビューが大量にありデータを歪めていること、そしてメンテナーの負担が均等に分担されていないことなどです。
私は2024年以降の OpenTelemetry リポジトリの PR とレビューデータをすべて取得し、分析しました。
おそらく誰にとっても驚きではないでしょうが、2026年初頭から、受信 PR の増加がアクティブなレビュアー（メンテナーの対応能力の代替指標）の増加を上回り始めていることがわかりました。
2024年9月から2026年9月にかけて、受信 PR / レビュアー比率は56%増加しています。

![2024年から2026年にかけての受信プルリクエストとアクティブなレビュアーの比較チャート。](maintainer-burden.png)

| 指標                                  | 2024年9月 | 2026年9月 |    変化 |
| :------------------------------------ | --------: | --------: | ------: |
| 受信 PR                               |     1,390 |     3,523 | +153.5% |
| アクティブなレビュアー                |       103 |       167 |  +62.1% |
| アクティブなレビュアーあたりの受信 PR |     13.50 |     21.10 |  +56.3% |

同様の指摘が最近のブログ記事 [OTel Isn't Going Well (And I Made A Spreadsheet About It)](https://matduggan.com/otel-isnt-going-well-and-i-made-a-spreadsheet-about-it/) でもなされていますが、OpenTelemetry の特定の分野についてより詳細に論じられています。

ここでは、なぜあなたがメンテナーになることを検討すべきか、そしてなぜ OpenTelemetry に依存している企業があなたのメンテナーシップを支援すべきかについて論じます。

## 好循環と悪循環 {#virtuous-and-vicious-cycles}

OpenTelemetry のペースについて不満を述べる人は多くいます。
「スループットは高いがレイテンシーも高いプロジェクト」と表現されてきました。
つまり、多くのことが行われているものの、個々のワークストリームには長い時間がかかるということです。
しかし、OSS や OpenTelemetry は本質的に遅いわけではありません。
プロジェクトの一部が極めて速く動くのを見てきましたし、個々のリポジトリが速い状態から遅い状態へ、またその逆へと変化するのも見てきました。

私の見立てでは、リポジトリの動きが速いか遅いかを決める最大の要因は、貢献の量に対応できるだけの十分な数のアクティブなメンテナーがいるかどうかです。
これが好循環と悪循環の分かれ目です。

リポジトリに十分な数のアクティブなメンテナーがいる場合:

- 各メンテナーが対応すべき PR やイシューの数が管理可能な範囲にとどまるため、常にコンテキストスイッチを繰り返すことなく迅速に対応できます。
- 迅速なフィードバックはコントリビューターを励まし、小さく自己完結したプルリクエストを実用的なものにします。
  積み重ねた一連の PR でも合理的な時間内にマージされるからです。
  小さなプルリクエストはレビューしやすく、それがフィードバックの速さを維持します。
- プロジェクトはより多くをリリースし、ユーザーへの対応も速くなり、それが採用を拡大し、さらに多くのコントリビューターを引き付けます。
  その一部がメンテナーになります。

メンテナーが不足している場合、あるいは関与が不十分な場合:

- 各メンテナーは対応しきれないほどの PR やイシューを抱えることになります。
  常にコンテキストスイッチを繰り返すことでエネルギーが消耗し、バーンアウトにつながります。
- メンテナーがキューを順番に処理していくため、個々のプルリクエストに対するフィードバックサイクルの時間が長くなります。
- 遅いフィードバックはコントリビューターの意欲を削ぎ、より大きなプルリクエストへと向かわせます。
  小さなプルリクエストを一連で送る場合、それぞれに長いレビューサイクルを待つのは耐えがたいためです。
- 大きなプルリクエストはレビューが難しく、コンテキストスイッチの認知的負荷を増大させます。
  これがフィードバックをさらに遅らせ、メンテナー候補者の意欲も削ぎます。
  レビュー負荷は高いまま維持されます。

どちらのサイクルも自己強化的です。
1人か2人のアクティブなメンテナーの存在が、リポジトリを一方のサイクルからもう一方へと傾けることがあります。
そして、関与は脆いものであり、転職、優先順位の変化、あるいは生活上の出来事によって急速に変わりえます。

## インセンティブの整合: 個人と企業 {#aligning-incentives-individuals-and-companies}

アクティブなメンテナーがプロジェクトの健全性にとって重要なてこであるならば、より多くのメンテナーが必要だということになります。
私はプロジェクトに [メンテナーシップにインセンティブを与える](https://github.com/open-telemetry/community/issues/3437)ことを提案しました。
もっとメンテナーシップを促進できると考えているからです。
しかし、現在でもメンテナーになる十分な理由はあります。
ただ、それが明確に表現されてこなかっただけです。

これは OSS であり、関心とスキルのある人なら誰でも貢献し、いずれメンテナーになることができます。
しかし実際には、ほとんどの OpenTelemetry メンテナーは本業の一部としてこの作業を行っています（執筆時点で、私の分析ではメンテナーの75%超がオブザーバビリティベンダーに所属しています）。
これが良いことか悪いことかは別の問題ですが、現実です。

より多くのメンテナーを望むなら、インセンティブが個人とその雇用主である企業の双方にとって機能する必要があります。
個人だけにこの負担を負わせるのは求めすぎです。

補足: メンテナーシップは個人にとっても企業にとってもメリットばかりではありませんが、その詳細はこの投稿の範囲外です。
将来の投稿や別の著者が詳しく述べてくれるかもしれません。

### なぜあなたがメンテナーになるべきか {#why-you-should-be-a-maintainer}

**キャリアのシグナル。**
メンテナーであることはキャリアにとって有益です。
見知らぬ人があなたを採用するかどうかを決める際、成功の見込みを示すシグナルを探します。
出身校、勤務先、推薦者、コーディングチャレンジの結果などです。
本格的な OSS プロジェクトのメンテナーであることは強力なシグナルであり、他のシグナルが弱まった AI の時代においても有効です。
うまくこなすには深い技術力と優先順位付けのスキルが必要です。
また、競合他社に所属する協力者と公の場で協働しながらの紛争解決など、ピープルマネジメントスキルも含まれます。
メンテナーシップは私のキャリアにとって有益でしたし[^career]、他の多くの人にとっても同様です。

**認知度。**
メンテナーには他では得がたい機会が与えられます。
CNCF イベント（例: KubeCon、Observability Summit）では、メンテナー専用トラックやメンテナーサミットへのアクセスなどの特典があります。
ポッドキャストやウェビナーでの登壇、その他のフォーラムで意見を共有する機会にも招かれます。
築いた業界のネットワーク、評判、そして公開された成果物は、特定の職場を超えてあなたとともにあり続けます。

**より大きなものの一部になること。**
これが私が OSS に関わり始めた最大の動機でした。

以前、全力を注いだ仕事がありました。
私のチームはいくつかの印象的なものを構築し、特許も取得しましたし、自分たちの成果を誇りに思っていました。
ビジネスに不可欠なプラットフォーム機能を構築していましたが、ビジネスの中核をなすものではありませんでした。
会社はプロダクトマーケットフィットを見つけられず、大幅に縮小しました。
レイオフ、ピボット、すべてが起こりました。
そのソフトウェアは今、どこかのハードドライブに放置されています。

人生の多くの時間を占める仕事に無関心ではいられませんし、自分のコントロールの及ばない力のせいで何年もの努力が無に帰したことは耐えがたいことです

OSS であれば、アイデアと実行が優れていれば、あなたのソフトウェアは成功し、大規模に使われることができます。
これこそが、毎日目覚めて良い仕事をしようとする私の動機です。
ソフトウェアは永遠に続くものではなく、OpenTelemetry もいつかは置き換えられるでしょう（願わくば数十年先のことであってほしいですが）。
しかし、その次に来るものは OpenTelemetry の影響を受けているはずです（OpenTelemetry がその先行プロジェクトの影響を受けたように）。
OpenTelemetry のような標準化プロジェクトはソフトウェアの系譜の永続的な一部となります。
クローズドな環境で構築した放棄されたソフトウェアが、それに関わった数十人のエンジニア以外の誰かに影響を与えたとは言えません。

### なぜあなたの会社がメンテナーを支援すべきか {#why-your-company-should-sponsor-maintainers}

これはメンテナーへの時間投資を検討しているマネージャーやステークホルダーの方に向けたものです。

**より効果的な貢献。**
メンテナーが特別扱いされるわけではありませんが、コードベースとプロジェクトの規範や優先事項を熟知しており、他のメンテナーとの信頼関係があり、適切な判断に必要な文脈を得るために誰に相談すべきかを知っています。
これにより、プロジェクトに適した提案を形成し、行き詰まりを回避することができます。

**セキュリティ。**
LLM によって脆弱性の発見が安価になったことで、セキュリティアドバイザリが急増しています。
メンテナーはアドバイザリが公開される前にトリアージと修正に携わります。
自社の製品に OpenTelemetry コンポーネントを組み込んでいたり、ベンダーフォークを保守している場合、そのアドバンテージにより、アドバイザリが公開された時点ですでに対応が進行中であることを意味します。

**影響力。**
プロジェクトは進化しますが、必ずしもあなたが望む方向に進むとは限りません。
OpenTelemetry に依存しているのにメンテナーがいなければ、プロジェクトの方向性に対する発言力は大幅に小さくなります。

**信頼性。**
OpenTelemetry を採用する顧客は、誰がそれを最もよく理解しているかに基づいて購入を判断する部分があります。
メンテナーはその専門性の最も明確な証明です。
競合他社にメンテナーがいてあなたの会社にいなければ、競合他社が優位に立ちます。

**共有基盤。**
OpenTelemetry の成長に伴い、プロプライエタリな計装への投資を正当化することがますます困難になっています。
OpenTelemetry はすべてのオブザーバビリティベンダーのストーリーの共有基盤となりつつあり、基盤が弱ければその上に構築されるすべてのストーリーも弱くなります。
すべての企業が他社にその基盤の維持を任せようとすれば、リポジトリは悪循環に陥り、あなたの製品が依存している機能や修正はすべての人にとって遅れて届くことになります。

## メンテナーになるには {#becoming-a-maintainer}

ここまでの内容に共感いただけたなら、次に気になるのは何が必要で、どこから始めればよいかでしょう。

> [!NOTE] コントリビューターラダー
>
> リポジトリレベルでは、[コントリビューターラダー](https://github.com/open-telemetry/community/blob/2c7afdc7fef121bcded259c1234489b834a770e8/guides/contributor/membership.md)は member → triager → approver → maintainer の順に進みます。
> SIG ごとに昇格の基準は異なります。

### メンテナーが求めるもの {#what-maintainers-look-for}

私の経験では、メンテナーに招かれるのは概念的にはシンプルです（簡単だということではありません）。
良い判断力を発揮し、オーナーシップを持って継続的に参加することです。

**良い判断力を発揮する。**
プロジェクトはメンテナーに多大な信頼を置いています。
メンテナーはコードをマージし、多くの本番システムに展開されるリリースを公開できます。
既存のメンテナーは、良い判断力を持つ人にその信頼を拡張したいと考えています。
実際には、提案している内容とそのトレードオフを理解しているかなど、ソフトウェアエンジニアリングの基本的な素養が求められます。
しかし OSS では、ソフトスキルが特に重要です。
他者の視点を考慮し、フィードバックへの対応を最後まで行ってください。
合意点と不一致点を要約し、進行を妨げている不足情報や保留中の判断を特定し、提案を独立して進められる小さなステップに分割することで、議論を前に進めてください。

**継続的に参加する。**
メンテナーシップにどれだけの時間がかかるかは、プロジェクトの規模や成熟度などによって異なります。
総量がどうであれ、小さな単位で継続的に参加するほうが、大量の時間をたまに費やすよりもはるかに有用です。
週に5時間あるなら、1日に5時間使うよりも5日間にわたって1日1時間ずつ使うほうが良いでしょう。
毎週継続的に参加することで、メンテナーはあなたがプロジェクトの責任を分かち合い、長く関わり続けてくれるという信頼を持てるようになります。

**オーナーシップの精神を持つ。**
メンテナーはプロジェクトのライフサイクルのあらゆる側面に責任を持ちます。
ビルド、テスト、ロードマップ、スタイル、ドキュメント、リリースなどです。
招かれる前からその精神を持つことができますし、そうすべきです。
リリースの実行やプルリクエストのマージはできませんが、それ以外のすべてに貢献できます。
特にコードレビューは重要です。
**コードレビューを行うために承認者やメンテナーである必要はありません。
レビューはどのコントリビューターからでも意味があります。**
これが、既存のメンテナーが新しいメンバーを招くかどうかを判断する際に注目する行動です。

### どこから始めるか {#where-to-start}

自分が使っているもの、必要としているものから取り組んでください。

OpenTelemetry は大きなプロジェクトであり、単一のリポジトリでさえ圧倒されることがあります。
最善のアプローチは、すでに使っていて改善できると思う部分から始めることです。
それに関連するイシューやプルリクエストを注視し、レビューしてください。
関連する Special Interest Group（SIG）のミーティングへの参加を始めてください。
提案された変更をローカルでチェックアウトし、そのサブコンポーネントがプロジェクトの他の部分とどう接続しているかを探る契機としてください。
探索していく中で、気になる点が見つかるでしょう。
それを小さく焦点を絞ったプルリクエストで修正してください。
これがメンテナーとの信頼関係を築きます。
より多くのサブコンポーネントを理解するにつれて、注視するイシューやプルリクエストの範囲をそれらにも広げてください。

メンテナーグループにすでに多くの人がいるように見えるリポジトリを避けたくなるかもしれません。
その直感には従わないでください。
ある分野があなたの関心に合致しており、メンテナーシップが明らかに不足しているなら、関わるべき強いシグナルです。
しかし、一見十分に見えるグループでも、実際にはそうでないこともあります。
イシューやプルリクエストの負荷が十分に大きいため、それなりの規模のグループでもなんとか持ちこたえるのに苦労しているかもしれません。
一部のメンテナーは、自分が離れるとプロジェクトが機能するのに必要な閾値を下回ってしまうため、時間を割けないにもかかわらず残っている場合もあります。

PR やイシューで貢献する際は、忍耐強くあってください。
悪循環に陥っているプロジェクトに飛び込むことになるかもしれないからです。
良くも悪くも、注目が希少なときは、SIG ミーティングでその事柄が重要である理由を直接説明することが、合意を得て前に進むための効果的な方法になりえます。

補足:
[open-telemetry/community](https://github.com/open-telemetry/community/) リポジトリは OpenTelemetry を知るための優れたリソースです。
SIG ミーティングのスケジュールとリンク、役割・責任・プロセスに関するドキュメントが揃っています。

## まとめ {#takeaways}

OpenTelemetry の最大の制約はメンテナーです。
十分な数のアクティブなメンテナーがいるリポジトリは速く動く傾向があり、いないリポジトリは停滞する傾向があり、その差は複利的に拡大します。

OpenTelemetry に携わるエンジニアにとって、メンテナーシップは真剣に追求する価値のあるキャリア目標です。
OpenTelemetry に依存している企業のマネージャーにとって、メンテナーシップはその他の OpenTelemetry 関連の取り組みをより効果的にする戦略的投資です。
企業は、その仕事を担う意思のある個人がいなければメンテナーを支援できません。
そして、個人は通常、支援してくれる企業がなければその仕事を担うことができません。

OpenTelemetry は現在すでに素晴らしいプロジェクトですが、まだ多くの重要な作業が残っています。
メンテナーが増えれば好循環が増え、それがプロジェクトのポテンシャルを引き出す方法です。

[^career]:
    私は OpenTelemetry に関わり始めてから、その仕事の直接的な結果として数回昇進しました。
    また、平均以上のキャリアの流動性があると思っています。
    私の OSS での経歴に特に関心を持つリクルーターから頻繁にアプローチを受けますし、公開された OSS での貢献を通じて実力を示すのも容易です。
    OSS に携わる前もまずまずのエンジニアでしたが、優秀なエンジニアたちと協働し観察することで、言語化能力・文章力・技術スキルが確実に向上しました。