🐣

[最初の一歩]OSSにﾁｮｯﾄ🤏だけコントリビュートできるようになってきて見えてきた個人的コツを書きます

2023/07/06に公開

OSS

idea

対象者

「OSSにコントリビュートしたことない・・・本当はやりたい・・・！！！でもまず何をすればいいのかわからない・・・最初の一歩どうすればいいんだ・・・！」

「OSSこんとりびゅーたーーーってかっこいい！！！！俺も〇〇のコアコントリビューター(ｷﾘって言いてぇ！」

こんな事を心のなかでちょっと思ってるような、でも具体的な一歩を動かせてない人向けです。ちなみに↑の思考は過去自分が思ってた心の中の声です。過去というかこの記事を書いている現在進行系で思っています。

何を話す？

OSSにコントリビュートしたい！PRの出し方とか、gitの使い方とか、そこらへんのやり方はわかるんだけど、どうしても最初の一歩が踏み出せない！、どんな感じで進めていけばいいのかわからない！という人に対して、自分の過去の知見から
「こんなふうな視点でで取り組むといいかもしれない」
という事柄を書いていきます。これをきっかけにチョットでも「よし、やるかぁ！」と手を動かしてくれたら幸いです

今まで何やってきた？ (自慢)

タイトルに「ﾁｮｯﾄ」と書いてるので本当にちょっとだけですし、内容自体も小さいものです。ただそのチョビチョビの一歩ができるだけでもかなりの差、だと思っているので、ここは胸を張って自分が過去コントリビュートしてきたPRを書いていきます！
※ただの過去自慢なのでtoggleで閉じときます。自慢話を聞くのが好きな人は開いてみてください

過去のコントリビュートしてきたOSS(自慢)

react-apexcharts

一番最初のコントリビュートです。

動機

当時在籍していたインターンの会社で使っていたのですが、明らかに型的に流し込めるはずなのに型が存在していなく、不便だったので試しに型を流し込んでみたらいい感じに動かせたのでPRにあげました。作者の無言マージがちょっと怖かったですけどこれがきっかけで「自分でもOSSにコントリビュートができるんだ・・・！！」と思えるようになりました

Next.js

すげぇ！Next.jsにコントリビュートしたのか！！と思いきや、中身はリポジトリ内にあるexampleの一つを修正しただけです

動機

issuesでgood first issueラベルが付いているものを漁っていたらいい感じに壊れてて動いていないissueがあったので直しました。会社の人にはよく「俺はNext.jsコントリビューターだぞ！！」ってイキリちらしていますが皆さん優しく受け止めてくれていて、その優しさに涙がでます。

dagger

動機

当時Daggerというツールがアチラコチラで出現するようになってきていました。ドキュメントのサイトがおしゃれだったのと、forkして中身を見ると、todoコメントとして

TODO: find available plans and if they load successfully

というのがあったので、「おれがやってやらぁ！」という気持ちでやりました。レビューしてくれた人がすごい優しい人で良かったです・・・
あとこういうOSSで触ってみて改めて「あぁ、Goは読みやすいな・・・いいな・・・Go」って思うようになりました。Goはイイぞ

Jotai

動機

現職でJotaiをよく使っていたのでなんとなく「Jotaiにコントリビュートしてぇ！」という気持ちになっていました。そしてforkしてなんとなくissueとコードをにらめっこしてるとdeprecatedな型をimportしているのがあり、かつこのextendsいらなくね？って思ったので消してPRとして提出しました

Aqua

動機

現職でCLI管理ツールとしてAquaを使っていました。ただこのaquaで管理しているうちの一つである「aws-vault」がなぜかmacosのみ非対応になっていました。調べてみるとaws-vaultのmac配布のみ.dmg拡張子で配布されていました。なのでaquaにissueで「dmgファイルのサポートって予定ある？」みたいなニュアンスのissueを出しました結果としては「いいよ！」という反応をもらったのでせっせと開発してPRを出しました。
PR出したあと作者の方がほとんどリファクタリングされてて「おれ、役に立ったのかな・・・」とか一瞬思ったんですけど、まぁ結果として自分がissueを出さなかったらdmgファイルのサポートはされなかっただろうし良いか！と前向きに捉えるようにしました。今では会社のaqua.yamlでaws-vaultが管理できてチームのみんながaws-vaultでいい感じにaws-cliを使えています

どのOSSにPRだす？

いくつか観点があると思いますが、自分は下記の軸で考えてます！

1. 愛

リポジトリのPRやIssueでの会話、discussionでの会話、ドキュメントの充実さ、そのリポジトリに助けられた過去の記憶、色々な要因で「このリポジトリ好き！」みたいな気持ちが芽生えることがあったりします。最終的にモチベーションを保つのに必要なのは愛です愛。多分

2. 積極的にissueやprが処理されている

どんなに頑張ってPRを書いたとしても、リポジトリオーナーによってはメンテナンスされずに放置されているOSS、結構あります。過去のPRを見て、そのPJがアクティブにメンテナンスされているかどうかを見てみましょう。長期間放置されているPRが大量にあるOSSがあったら、もしかしたらあなたのPRは見てくれないかもしれないですので

3. 普段の仕事で困っているツール

同僚にちやほやされたい場合おすすめです。普段会社で触っているツールに関して「こんな機能があったらな」「このバグ治らねぇかな」とかぼやいてる人いませんか？そんなときに

「おれがコントリビュートしときましたよ(ｷﾘ」
とか言って見る場面を想像してみてください

(´＾ω＾｀)

どんなPRを作る？

Issueのラベルで見つけよう

Next.js(以下next)を例に上げます。
nextでは「good first issue」というラベルで初心者向けのissueをラベルで管理しています。これらのissueは他のissueよりも難易度が低い(はず)はずなので、初心者向けラベルで絞り込んでみて取り組めそうなissueを見つけましょう！bug修正だったらbugラベルもあるはずですので、それで絞り込んでみてもいいでしょう。

TODOコメントを見つけよう

コードにコメントアウトで// TODO　と書かれているものがあったらそれに取り組んでみるのもいいと思います！

canary版やalpha版、beta版リリースを使ってみてバグを見つけて修正してみよう

ちゃんと管理されているossでは、stableリリースの前にbeta版なんかをリリースします。これは事前にバグを洗い出し、修正するためだったり、フィードバックを貰うための事前リリースだったりします。これらを利用してみてバグと思えるものを発見ししだい、issueに上げて、原因がわかりそうならそのまま取り組んでみましょう！

PRを出すに当たっての事前準備

1. CONTRIBUTIONガイドラインを読もう

例: https://github.com/vercel/next.js/blob/canary/contributing.md
例: https://github.com/dagger/dagger/blob/main/CONTRIBUTING.md

マストです。これを守っていないとPRやissueを見てくれない場合も少なくありません。最悪非難されたりします。
環境構築の方法なども乗っている場合があるのでまず最初に読んでみましょう

2. (新機能の場合)自分が実装したい内容に関して事前にIssueを作成して合意を取ろう

あなたが素晴らしい新機能を思いついたとします。いきなりガガガっとコードを書いてPRを提出しても作者の人が困ってしまいます。新機能があれば便利！！というのは利用する側としては単純な話ですが、一方でリポジトリの作者は「将来に渡ってその機能のメンテナンスをしていく」という覚悟がいります。
なので、事前にIssueやDiscussionを作成して「こんな機能を考えたんだけどどうよ！」と合意を取ったほうが良いかと思います。そうすればお互い無駄な時間を取ることがなくなりますので

コードリーディングのコツ

全てを理解しようとしない

OSSの規模によってはそこらへんの会社で作られてるソフトウェアの何倍もの量のコードが書かれていたりします。よっぽどの天才ではない限り社会人生活のスキマ時間ですべてを理解するのは不可能です。あなたが取り組むIssueベースで
「このバグを修正するにはどのコードが原因なんだろう」
「新機能を追加したいけどどこにコードを追加すればいいんだろう」
を意識して、一部分だけから読み解いて実装するとコードが書けるようになるかなと思っています。

そのリポジトリがやろうとしてるドメイン知識ある？

これは筆者がよく失敗してることです。筆者はよくかっこいいという理由だけで

Dockerにコントリビュートしたい！
Denoにコントリビュートしたい！
Linuxにコントリビュートしたい！
..etc

とポンポコforkしたりしてコントリビュートチャンスを見つけようとしたりします。ですがよく考えてみてください。
Linuxを例にします。Linuxのコードをいじるということはある程度「カーネル技術とはなにか？」「Linuxはどういうアーキテクチャで作られているか」という基礎知識が必要になるはずです。それらがないままいきなりコードを読んでもただif文とfor文の羅列を目で追うだけの行為になってしまいます。事前知識があるだけでコードの解像度が段違いに違うはずです。
Linuxにコントリビュートしたいけどカーネル技術なにもしらん。というのも変な話です。そのリポジトリが取り扱う領域を事前に勉強してみましょう。

これは筆者へのブーメランです

...
..
.

気をつけます(・ω・)

エントリポイントを見つけてそこからデバッグしてみよう

すべてのコードを見るのは不可能と言いましたが、じゃあどこから見ていけばいいのよ！と思ったかと思います。
筆者はよくエントリポイントを軸に処理を追っていきます。例えば

cliツールならmainファイル
web apiならhandlerレイヤのコード
importして使う系のライブラリならそのライブラリのコンストラクタや関数

などですね。これらの処理を追いながらprintデバッグしていくと。処理の初め ~ 終わりまでの、データの取得から出力までの流れを簡潔に追うことができます

単体テストを見つけてそこからデバッグしてみよう

エントリポイントからのデバッグは全体を俯瞰するときに、単体テストは一部分の挙動を確かめるために使ってみましょう。単体テストの場合はテストケースがたくさん書かれていることが多いので
「このデータの場合はこれが出力される」が網羅されています。コードリーディングを助けてくれる存在としてテストファイルは宝の山です！！是非活用してみましょう

(追記)Githubのエディターで見ようとせず、自分が普段使っているエディターで見よう

完全に個人的な感覚の世界なのですが、軽いコードリーディングの際でも、Githubのファイルエディターではなく、普段使っているエディターで見るようにしたほうが良いなと思っています。普段使っているエディターだからこそコードに集中できますし、エディター経由で触ると気軽にコードを編集できます。コードの値をいじって試してみることで、自分とOSSとの距離感がかなり縮まるような感覚を得ます。

おわりに

皆さんの心のなかにすこしでも「良し！OSSコントリビュートやってみるか！！！！」という気持ちが芽生えてもらえたら幸いです！

では！