こんにちは、Zaim でサーバサイドエンジニアをしている @hira です。
4 か月ほど前から OSS 活動を始めました。

OSS は「オープンソースソフトウェア（Open Source Software）」の略です。作成者がソースコードを無償で公開していて、利用や改変、再配布を許可しているソフトウェアのことです。

OSS 経験ゼロだった私も四つの OSS に対して貢献（コントリビュート）できました。今回はこれから「OSS 活動に挑戦してみたい！」という方向けに記事を書きたいと思います。

OSS にはさまざまなコントリビュート方法があります。今回は OSS 活動として「GitHub 上で公開されている OSS に対して実際にコードを書いて貢献する」ケースにフォーカスしたいと思います。

OSS 初心者にもコントリビュートするチャンスはある

OSS 活動というと、次のようなイメージがありました。

• 英語力が必須

• issue の難易度が高くて初心者では難しい

しかし、OSS 活動を始めてみると、このようなイメージは大きく変わりました。

英語力はそこまで必要ない

issue や Pull Request 上では、基本的に英語でやり取りすることになります。私は英語が得意ではありません。ですので、もともとは OSS 活動に対して敷居が高いなという印象を持っていました。

しかし、実際にやってみると英語力はそこまで重要ではないと感じました。というのも DeepL などの機械翻訳を利用すれば、問題なくコミュニケーションできたからです。

もちろん英語ができるに越したことはないですし、もしかすると、ネイティブの方からするとおかしな表現も使っていたかもしれません。ですので完全に機械翻訳だけに頼るのではなく、できるだけ issue の中で使われている表現を取り入れてみるなど工夫することは心がけていました。

探せば簡単な issue はある

難しい issue ばかりなんじゃないかという印象があるかもしれませんが、探してみると簡単な issue は残っていたりします。

大抵の OSS の issue には「good first issue」というラベルがあります。これは初めてコントリビュートする人向けのラベルです。このラベルがついた issue は比較的、難易度が低めです。初めてコントリビュートする場合は good first issue から挑戦できると自信がつくので良いと思います！

good first issue を探せるサイトがありますので、こういったところから issue を検索してみるのもおすすめです。

簡単な issue の探し方

good first issue のラベルがついた issue の探し方は色々なところで紹介されているので、ここでは私流の簡単な issue の探し方を共有します。

私が簡単な issue を探す際に意識したポイントは以下の 3 点です。

• 作成から半年以内であること

• バグ報告かつ再現方法の記載があること

• issue のコメント数が少ないこと

作成から半年以内であること

good first issue であっても、古い issue は誰も解決できなかった可能性が高く難しい傾向にあります。そのため、簡単な issue を探す場合はできるだけ新しい issue から探すといいと思います。

逆に新しい issue であれば good first issue のラベルがなくても簡単な issue だったりするので、私は半年以内の issue はラベルに関係なく目を通すようにしています。

バグ報告かつ再現方法の記載があること

バグ報告は good first issue のラベルが付いていなくても再現方法の記載があり、自分の環境で再現できれば簡単にバグ修正に成功するケースがあります。

例えば私が対応した以下の issue です。

issue のコメント数が少ないこと

コメント数が多い issue は、good first issue であっても仕様や方針に関するディスカッションであるケースが多く、取り掛かる前に確認する点が多岐に渡るため、難易度は高くなる傾向があります。簡単な issue を探す場合はコメント数を確認すると良いと思います。

私は簡単そうな issue を探すときには以上の点を意識して issue を検索していました。

そもそもなぜ OSS 活動を始めたのか

Zaim では週 3 回 15 分程度の LT 会があります。

その中で、別の社員が OSS 活動に関して発表していました。内容は OSS 活動に入門するにあたっての準備についてで、Pull Request を作成するまでの流れや issue の見つけ方など、とても参考になりました。私の中で「OSS は難しそう」というイメージから「自分にもできることあるかも」と意識が変わりました。

※ Zaim の LT 会については以下の記事をご覧ください。

また、普段の生活の中で、世界規模で利用されているものに対して貢献するチャンスはそんなに無いと思います。
しかし、OSS 活動であれば、自分自身のやる気さえあれば貢献することができます。

私は、世界規模で利用されているものに対して貢献できるという点にとても魅力を感じて OSS にコントリビュートすることを決意しました！

OSS 活動のコントリビュート実績

OSS 活動を始めて約 4 か月で、四つの OSS に対して七つの Pull Request を出しました。

denoland/dotland
JavaScript/TypeScript のランタイムである Deno の公式サイトです。
公式サイトのバグ修正や機能追加をしました。dotland は、私が初めてコントリビュートした OSS です。ブラウザ上で動作確認しながら開発できるので、初めて取り掛かるにはピッタリでした。

oakserver/oak
Deno の HTTP サーバのフレームワークです。テスト用のモックオブジェクトで Cookie を扱えるようにしました。テストを書くときに、oak で用意されているモックオブジェクトでは Cookie が使えませんでした。私も不便に感じているところでしたが、この修正で Cookie を使ったテストが楽に書けるようになりました。

ory/hydra
Go の OAuth 2.0 サーバーのライブラリです。shell の静的コード解析ツールである shellcheck を導入しました。

rubocop/rubocop
Ruby の静的コード解析ツールです。リモート環境にある設定ファイルを読み込んだ際に発生するバグ修正をしました。

OSS にコントリビュートして感じたメリット

技術力向上につながる

OSS にコントリビュートするにあたって、ドキュメントやコードを読むことが必要になります。OSS のコードやドキュメントは読むだけでも今まで知らなかった言語仕様やコードの書き方を学べました。
　また、Pull Request を出した際には、コミッターの方からコードレビューをしていただけます。より良いコードの書き方を教えていただくこともあり、とても勉強になりました。

達成感が得られる

世界中で使われている OSS や普段、自分で使っているライブラリの機能を修正することで「貢献できた！」という達成感が得られます。

自分が作成した Pull Request がマージされた瞬間は本当に最高です。

最後に

OSS 活動を通じて OSS に対する「なんだか難しそうだな」というイメージがなくなりました。今後は簡単な issue だけではなく、少し難易度が高めの issue にもチャレンジしたいと思います。

この記事を読んでくださった方が一人でも多く OSS 活動に興味を持って一歩を踏み出していただけると嬉しいです！