🏄‍♂️

ジュニアエンジニアが初めてOSSにコントリビュートした話とコツ

2022/06/14に公開

はじめに

こんにちは、Web系企業でエンジニアになって2年目のyukunです。
この記事はよくある初めてOSSにコントリビュートした自慢のポエムですので温かい目で読み流していただければと思います。
ところで、OSSにコントリビュートしているエンジニアってかっこいいですよね。僕もずっと憧れがありましたが、ライブラリを作るアイデアやモチベーションが無かったり、GoodFirstIssueを見つけて目的としてのOSSコントリビュートはあまり興味がありませんでした。
しかし、今年はthree.jsmodel-viewerという大きなOSSにコントリビュートすることができたので、そのときに意識していたことを書いてみようと思います。

↓ model-viewer内部でファイル変換に使われており、一部非対応だったものを対応させたPR
https://github.com/mrdoob/three.js/pull/23588

↓ model-viewerを利用しているときに、個人の検証端末で表示がおかしかったので、CSSを修正したPR
https://github.com/google/model-viewer/pull/3464

コントリビュートの手順とコツ

前提として個人開発もしくは仕事でOSSのライブラリやフレームワークを使ってソフトウェア開発をしている人を対象としています。また、GitやGithubの使い方、GithubFlowといった知識があることとします。

  1. まずは、自分が開発しているWebサービスやアプリなどで利用しているOSSのライブラリやフレームの問題を見つけます。見つけるよいうよりも、開発途中で見つかると言った方が適切かもしれません。
    ここで特に問題がバグや追加してほしい仕様などの問題が見つからなければ。そのまま自分の開発に専念しましょう。

  2. 問題が見つかれば、Githubなどの開発が行われているサイトのIssueを探しにいきます。
    Issueがあれば既知の問題で既に解決されているのか、議論されているかといった情報を読み込みます。
    Issueが見つからなければ、自分で作成します。
    ContributionGuideがあるプロジェクトであれば、しっかり読みそのリポジトリのルールに従って作成しましょう。無ければ、よくあるIssueのテンプレで自分の環境や事象を詳細に書きましょう。

  3. 未解決の問題の場合は、自分でそのプロジェクトのコードを読みにいきます。ライブラリやフレームワークのOSSはほとんどの場合、自分が開発しているソフトウェアと同じ言語で書かれていることが多いので、ソースコードを読むのはそんなに大変ではないかと思います。かなり大きなプロジェクトの場合には全部を読もうとせず、まずは自分が問題に直面している該当の処理を読みにいきましょう。このときに定義ジャンプや検索などを駆使すると便利です。場合によってはそのライブラリが依存しているさらに別のライブラの問題かもしれません。
    ここで問題を修正できるかどうかはその問題をどれくらい解決したいかの執念ですかね…
    別に修正せずとも他の方法で回避できるならそれはそれでいいと思います。

  4. コードをある程度把握できたらなぜ問題が起きているかを調査し、自分なりに直してみます。これで直せたら自分の開発しているソフトウェアで正しく動くか検証してみます。npmの場合は対象パッケージを自分が修正したローカルのディレクトリを指定することで簡単に検証できます。

  5. 問題の修正ができたらPRを出します。繰り返しになりますがContributionGuideがある場合、Lintやテストなどのルールに従うようにしましょう。
    多くの場合PRを受け取る人は同じ職場で普段からコミュニケーションをとっている人ではないので、前提知識や根拠となるドキュメントや場合によってはサンプルコードなどを付けておくとPRのレビューがしやすくなります。

  6. PRのレビューで指摘されたことや質問があれば適宜、修正や回答をすると良いでしょう。

  7. PRがマージされれば、コントリビュート完了です。おめでとうございます!

終わりに

こうして書いてみると当たり前のことかもしれませんが、普段の開発で問題が見つかったときに意識してみると自然とOSSにコントリビュートできるようになるかと思います。

実のところ、1年前の自分は大きなOSSにコントリビュートするとは思いもしなかったですが、個人で0からコードを書いていた頃と違い、業務で大規模なプロジェクトに触れていると自然とコードを読む能力がついていたことも要因の一つだと思います。
また、業務でGithub(もしくはEnterprise)などを使っているとIssueやPRを作ることに慣れているので、Github上での活動のハードルが下がったように感じます。(Githubが業務で使えるのは福利厚生なのではと思ったりもします…)

個人的な感覚ですが、問題に気が付く人 >> Issueを立てる人 >>>> PRを出す人 のような割合だと思うので問題に直面した時はぜひチャンスだと思ってどんどんOSSにコントリビュートして世界に貢献していきましょう!!

Discussion