【ITニュース解説】From Scared of the Repo to Mentoring People Into It

巨大なオープンソースプロジェクトに初めて貢献しようとするとき、多くの人が共通して感じる圧倒的な感覚や恐れについて解説する。それはまるで、いきなり飛行中の航空機の操縦席に放り込まれたかのような感覚だ。何千ものファイルが並び、熟練のコントリビューターたちが簡単にこなしているように見える状況に直面すると、「自分には場違いだ、すぐにタブを閉じよう」という声が頭の中で聞こえてくるかもしれない。しかし、この内なる声に耳を貸さないことが、オープンソースの世界で活動する上で非常に重要である。なぜなら、その声に打ち勝つことこそが、このゲームの本質だからだ。

筆者もかつてはプルリクエスト（PR）を提出することさえ怖がっていたが、わずか2年後にはGoogle Summer of Code（GSoC）のメンターを務めるまでになった。この道のりは、外から見ているほど神秘的なものではなかったと筆者は語る。実際に効果があった具体的な方法が示されている。

まず、誰もが最初からプロジェクトの「かっこいい部分」を書くわけではないという事実を理解する必要がある。これは、あまり語られない真実である。大規模なプロジェクトへの最初の貢献は、エキサイティングな分散システムにおける高度な技術開発であることはほとんどない。筆者の場合、Jenkinsというプロジェクトへの最初の貢献は、ドキュメントの作成やツールの改善に関するものだった。具体的には、1100万人以上のユーザーが参照するJenkinsのドキュメントを、適切なバージョン管理されたスタック（GatsbyJSとAntora）に再構築する手助けをした。これには、サイト全体を新しいシステムに移植したり、多数のプラグインを最新の状態に更新したりするような、地味だが非常に実質的な作業が含まれていた。

当時、筆者は「ドキュメントの修正も本当に貢献と言えるのだろうか」と疑問に感じたという。しかし、読者よ、それこそが最も現実的な貢献である。ドキュメントを修正するためには、そのプロジェクトの仕組み、ビルド方法、そしてユーザーが実際にどこで戸惑うのかを深く理解する必要がある。結果として、プロジェクトの「エッジ」、つまり中心的なロジックの周辺部分を通じて、プロジェクトを横断的に学習することになる。これは、いわば「チートコード」のようなものだ。ドキュメントやCI（継続的インテグレーション）の扱いに慣れる頃には、かつて恐ろしく見えた核心のコードも、もはやそれほど恐ろしいものではなくなる。何ヶ月もの間、その隣で活動してきたからである。

「エッジ」とは、ドキュメント、テスト、CI、ツール、ビルドスクリプト、エラーメッセージといった、プロジェクトのコアロジックを取り囲む部分を指す。これらの作業は、重要度が低く、レビューも受けやすいため、リポジトリ内の最も難しいファイルを凝視するよりも早く、コードベースの全体像を把握するのに役立つ。

次に重要なのは、「退屈なドア」を選ぶというコツだ。KubernetesやPrometheusのような巨大なプロジェクトにどうすれば貢献できるのかと悩んでいるなら、筆者からの具体的なアドバイスはこうだ。印象的な変更を探すのではなく、厄介な変更を探すのだ。例えば、誰もが嫌っているが誰も直そうとしない不安定なテスト、一度修正されたバグが再発しないようにするためのテストの追加（筆者のKubernetesへの最初のマージは、json-patchの負のインデックスに関するバグの回帰テストだった）、あるいは手作業で維持されている不安定なCIの仕組みなどだ。筆者のKueueやPrometheusのテストインフラに関する多くの作業は、まさにこのような内容だった。

これらの作業は一見地味だが、それこそが手がつけられていない理由であり、メンテナーたちが喜んで受け入れてくれる理由でもある。このような地味な貢献を十分にこなしていくと、やがてはより本質的な作業を任されるようになる。筆者も最終的にはPrometheusの実際のクエリ層で、/queryや/query_rangeに制限パラメータを追加したり、memcached_exporterに新しいメトリックを公開したりするまでになった。しかし、これらは筆者が最初に手を出したものではなく、10番目に取り組んだ内容だった。

「Kubernetesに貢献する」と聞くと、崖を登るような壮大な挑戦に聞こえるかもしれないが、間近で見ると、それは何百もの小さな足がかりの積み重ねに過ぎない。一度に全ての崖を登り切る必要はない。不安定なテストを一つ修正する、欠けている回帰テストを追加する、分かりにくいドキュメントを改善する、といった次の足がかりに到達することだけを考えれば良い。

そしてある日、あなたは反対側にいることになる。2024年、筆者はGSoCに再び参加した。しかし今回は、メンティーとしてではなく、メンターとしてだった。

メンターという立場になり、オープンソースへの貢献全体に対する筆者の見方は完全に変わった。なぜなら、新しい貢献者たちが、かつての自分と全く同じ行動をしているのを目の当たりにしたからだ。リポジトリの巨大さに戸惑い、自分の質問を「愚かだ」と謝罪し、小さなプルリクエストは提出する価値がないと思い込んでいる彼らの姿を見たのだ。そして、筆者は彼らに向かって「いや、提出しなさい、それは良いものだ、まさにこのようにして物事は進むのだ」と伝える役割を担うことになった。

メンティーからメンターへの道のりは、かつて筆者が下から見上げていた時には、まるで深い峡谷のように感じられた。しかし実際には、それはわずか1年と、たくさんの小さな、そして完了した貢献の積み重ねでしかなかったのだ。誰も「あなたはここに属している」というバッジを渡してくれるわけではない。ただ、ひたすら活動を続け、ある日、自分が誰かに「あなたはここに属している」と語る立場になっていることに気づくのだ。

要するに、最初の大規模なリポジトリへのプルリクエストを出す際に感じる恐れは、正常な感情であり、ほとんどの人に共通するものである。誰もがそれを感じる。それでも、プルリクエストはとにかく提出すべきだ。ドキュメント、テスト、ツール、CIといった「エッジ」の部分から始めることが重要だ。これによりプロジェクトを多角的に学習でき、それが最も早くプロジェクトに慣れる方法となる。印象的なタスクではなく、誰もが避けたがる厄介なタスクを追いかけるべきだ。不安定なテストや回帰バグの修正こそが、KubernetesやPrometheusのようなプロジェクトにマージされるための入り口となる。十分に小さな、完了した作業を積み重ねていけば、「メンティーからメンターへ」という道のりは、深い峡谷ではなく、階段のように見えてくるだろう。

もしあなたが、巨大なリポジトリの周りをうろつき、「準備ができた」と感じるのを待っているとしたら、これがあなたへのサインだ。あなたは「準備ができた」と感じることはないだろう。だから、「退屈なドア」を選び、足を踏み入れてみよう。筆者は今でも、慣れないコードベースを開くたびに「自分はここに属しているのか」という一瞬の疑念を感じるという。しかし、今の筆者はそれが嘘だと知っている。今週、あなたが尊敬するプロジェクトの中で、不安定なテストを一つ見つけてみよう。それが最初の一歩の全てである。