今熱い！OSSコントリビュート

突然ですが、あなたは OSS活動やっていますか？
去年ではありますが OSSを積極的に推奨する企業も出てきて、今 OSS にコントリビュートは熱い分野の１つになっています！

そんな OSS ですが、自分も、去年の10月に初めて nue.js というプロジェクトにコントリビュートしてから、去年の12月から Next.js を読み始めてつい先週 Next.js への PR がマージされました。

しかし、普段はOSSの恩恵を受けているだけの開発者の自分は、大規模OSS開発というOSSを使う側と比べると何倍も規模が違う開発のイロハをわきまえず、開発をしてしまい、失敗してしまった経験があります。
自分と同じような過ちはおかしてほしくないという希望を込めて、ここでは Next.js歴2.5ヶ月の駆け出しNext.jsコントリビューターの自分が、大規模OSS開発で気づいた OSS 開発のイロハをまとめようと思います。

まだ自分のOSS歴は短いので、「ここはこうだよ！」みたいな指摘があったら指摘くださると嬉しいです！

まず結論から！3ヶ月で学んだ OSS開発のイロハ

頭がちぎれるくらい考えよう
issue から課題を見つけよう
文章はしっかり読もう
テスト・リントは通そう

頭がちぎれるくらい考えよう

OSS活動をしたことがある人なら分かると思いますが、issueで発見したバグをローカル環境で直した時に、すぐに PR を送ろうとしたことはありませんか？

他の人とは言わず、自分はそうでした。
ログを埋め込めば、それっぽい原因は分かります。そこで見つけたバグを直して、テストも通ったら、スピード重視でついついプルリクを作ってしまう。
昔少しだけ営業をしていて「数打てば当たる」精神でなんとかできるのではないかと思いがちな自分は、プルリクをすぐ出してしまう傾向がありました。

しかし、最近になって早くプルリクを作り調査を怠ることは、多くの開発者にとってあまり良くないのではないかと思うようになっています。

実際のところ、多くの開発者は、OSSの恩恵に預かる側だと思います。
OSSの恩恵に預かる時、あなたは分からないことがある前提で開発をすると思います。
この世の中に、React の useState（もしくは hooks）が循環リストであることを知って開発している人がどれくらいいるでしょうか？また、その奥にある神秘を知って開発している人はどれくらいいるでしょうか（自分はその神秘とやらは分からないですが...）？
そんなことを知っても多少のパフォーマンス改善かReactの習慣を言語化するくらいにしか、通常の開発では意味を持ちません（多分）。

そうやって私たちのような OSSの恩恵を預かることをよしとしている開発者たちは、ブラックボックスをブラックボックスとしか認識しないことで開発をする「習性」を身につけてしまいます。

そういう「習性」を持った開発者が、OSS開発に参加するとどうなるでしょうか？
真実は、プログラミングに対する浅い理解をメンテナに見せびらかすことになってしまいます。
「とりあえず動いたし、LGTM！きっとマージされるでしょう！」

あまり一般化しないほうがいいかもしれませんね。
これ、私のことです。

「とりあえず直ったなら、いいじゃん！」
あなたはそう思うかもしれません。

しかしよく考えてみてください。

ブラックボックスであることを前提に開発している開発者と、ブラックボックスを提供する側の開発者の間にある、あまりにも大きい隔たりというものを。
私たちの世界ではブラックボックスであることは何も問題ないことですが、OSSという世界ではブラックボックスは許されません。例えば、Next.js だって最近 RSC を採用した時に、検索してもでてこないRSCの仕様を、コードから読み解いていったに違いありません（例えば、@uhyoさんのzennの記事を見れば、tee などドキュメント化されていない関数などがあると思います）。

ブラックボックスであることをよしとしている開発者の「とりあえず動けば LGTM！」という精神は、OSS開発では通用しません（自分の観測する限りだと）。
ある１箇所のバグを修正して、テストを通ったところで、それが表面的な原因しか見ていなかったら、どうか？真因を探し当てていなかったら、どうか？自分でもどこでデグレが起きているか分からないコードを書いてしまったら、どうか？

きっとその「とりあえず動いたし、OK」なコードは、マージされることはないでしょう。自分はそうでした。

逆に自分が書いたコードで Next.js でマージされたコードは、誰のどのコミットの何行目がバグを起こしているか分かって、ようやくマージされました。大規模 OSS開発に求められるレベルは、通常の OSSの恩恵を受けるだけの開発とは全く次元の違う深さなのです。

でも最初から OSS開発に求められる深い理解を得ることは至難の業でしょう。偉そうなことを言っておきながら、自分も深い理解はしていないです。
なので、これから大規模 OSSに挑戦する人は、まず OSSの全体像を把握したら、issue を探してコードの改造をしてパッチを作れるようになることを目指すといいと思います。
ただ、その OSSが大規模であればあるほど、マージされるには issue の真因を深く理解することが重要になってきます。

頭がちぎれるくらい考えないといけない のです。

issue から課題を見つけよう

「good first issue は簡単だから、取り組むといい」という言説は結構ありますが、自分は賛成できません（もしかしたら、見ているOSSプロジェクトによるかもしれませんが）。

なぜか？

原因は２つあります。
まず、競争が激しすぎるからです。
good first issue に何人もの人が取り組もうとしてコメントのを見て、あなたの入る余地があると思いますか？自分はないと思いました。Next.js の issue なら、半分程度の issue はコメントすら来ていないので、そこで最初にバグを直せれば、あなたが最初にバグを直した人になれます。

次に、通常のissueを見て勉強すること自体に意味があり、issueを立てた人から感謝され、徳を積めるからです。
誰もコメントしていない issue を調査することは、最低でも自分でパッチを作る技術がついたり、内部構造について解像度を上げることにつながります。また技術的なことを理解し、コメントを返すことは、問題を解決しているなら、issue を立てた人に感謝されます。
こういった日頃の感謝が、OSSをもっと頑張ろうという気持ちにつながると自分は思います。

そういったことで、競争が激しくなく、勉強しつつ徳を積めるということで、自分は issue のバグを中心に直そうと調査しています。

実際 Next.js にはなりますが、自分のような Next.js OSS歴 2.5ヶ月の人でもパッチは何個か作れたので、やってみる価値はあると思います。

文章はしっかり読もう

これは基本なことになりますが、文章は最後の１文字までしっかり読んだほうがいいです。もちろん、分からなかったら、自動翻訳すべきでしょう。
ついつい、バグの概要に全てが書いてあると思い込んで、additional context を読み飛ばしてしまったことが自分にはありました。
日本は英語圏でないので、コミュニケーションの部分で難しいこともあるかもしれませんが、しっかり漏れがないように issue の文章を読み込みたいものですね。

テスト・リントは通そう

この記事を読んでもらえれば分かりますが、自分にもテスト・リントを通さずプルリクを出していた時がありました。
できる限り、このテスト・リントは通しましょう。

最後に

最初ばっかり長くなってしまいましたが、いかがでしょうか？
もしかしたら、OSSに参加するのって難しいのでは？と思わせてしまったかもしれません。
でも、コードが大規模になればなるほど、とりあえず直ったパッチを作るだけでは超えられない壁があると自分は思います。
そんな中でも、コードを直した時の達成感や技術的な好奇心を持って、OSS開発に取り組めればいいのではないかと思いつつ、末筆にしたいと思います。