業務外で成長を加速させる「OSS貢献」の始め方

「自分が直せるコードなんて無い」で止まる

OSS への貢献がいいらしい、と聞いて有名なライブラリのリポジトリを開いてみる。ファイルが数千個あり、型定義とビルド設定が入り組んでいて、Issue の議論は英語で流れている。五分眺めて、そっとタブを閉じる。ほとんどの人が、ここで一度は止まります。

止まる理由は実力ではなく、入口の選び方です。貢献はコードを直すことだと思い込んでいると、いきなり一番高い段から登ろうとすることになります。実際には、その手前に段がいくつもあります。ここでは低いほうから順に見ていきます。

段一つめ、誤字を直す

一番低い段は、ドキュメントの誤字や壊れたリンクの修正です。技術的な難易度はゼロに近く、それでも立派な変更として扱われます。

この段の価値は、修正そのものより手続きを一周できることにあります。リポジトリをフォークし、ブランチを切り、変更を push して、プルリクエストを出し、メンテナーの反応を待ち、マージされる。この流れを一度でも通しておくと、次からは中身に集中できます。初めての貢献で緊張するのは、たいてい中身ではなく手続きのほうです。

探し方は簡単で、自分が普段使っているライブラリの README や公式ドキュメントを、翻訳にかけずに読んでみることです。リンク切れやコード例の書き間違いは、思っているより残っています。

段二つめ、動かなかった手順を書き足す

次の段は、ドキュメントの補足です。導入手順のとおりにやったのに動かなかった、という経験は、そのまま貢献の材料になります。

たとえば、セットアップ手順に書かれていないパッケージが必要だった、特定のバージョン以降で設定ファイルの書き方が変わっていた、といったものです。あなたが詰まった場所は、次に来る人も同じように詰まります。書いた人には当たり前すぎて省かれた一行を、詰まった人が足すのが、この段の役割です。

ここまで来ると、そのプロジェクトが何を大事にしているかが少しずつ見えてきます。多くのリポジトリには CONTRIBUTING.md という貢献の手引きが置かれているので、先に目を通しておくと、書き方の作法で迷わずに済みます。

段三つめ、再現手順の書ける Issue を出す

コードを書かない貢献の中で、いちばん歓迎されるのが、再現できるバグ報告です。メンテナーにとって、手元で再現できない不具合ほど困るものはありません。

良い報告に必要なのは、使ったバージョン、環境、実行した手順、期待した結果、実際に起きたこと、の五つです。「動きません」ではなく「バージョン 3.2 で、この設定のときに、この手順を踏むと、この例外が出ます」と書けるかどうかで、扱われ方がまったく変わります。可能なら、最小限のコードで再現するサンプルを添えてください。

この段は、実は技術力を一番使います。どこまで削っても再現するかを詰める作業は、原因の切り分けそのものだからです。ここができるようになったころには、修正のパッチを書く準備も整っています。

解説

現場の話 — 修正に取りかかる前に、Issue で「これに取り組んでもよいですか」と一言置いてください。他の人と作業がぶつかるのを防げますし、そもそも直す方針が決まっていない案件を避けられます。

英語も、思っているほど障害になりません。求められているのは流暢さではなく意図が伝わることなので、「I would like to work on this issue. May I?」程度の短い文で足ります。翻訳ツールを使って構いません。気をつけたいのは表現より態度のほうで、「直してあげた」ではなく「使わせてもらっているので直したい」という姿勢が伝わるかどうかで、返ってくる反応は変わります。マージされたら、レビューへの礼を一言添えてください。次の貢献がずっとやりやすくなります。

まずは、あなたが今日使ったツールのドキュメントを一枚開いてみてください。直せるところは、たぶんもう見つかります。