OSSにコントリビュートしてみたい人を応援する記事
先日、人生で初めて OSS にコントリビュート（貢献）してきました。
自分の実力ではとてもできないだろうと思って手を出そうともしなかったのですが、真面目にコツコツ取り組んでみるとついにはその目標を達成することができました。
かかった期間も一週間以内（ぶっ通しではないので実際の時間はもっと短い）でした。
もちろん優しい issue を対象にしたというのもありますが、一週間なら挑戦してみようかな という前向きな気持ちになれる期間ですよね。OSS にコントリビュートするのに壁を感じる方は多いと思うので、この記事ではそういった壁を取り払うべく、自分が OSS にコントリビュートするまでの道のりを書いていこうと思います。
この記事では、以下の内容を扱います。
- OSS コントリビュートへの意欲・背景
- OSS にコントリビュートするためにやったこと
- OSS コントリビュートしてみてどうだったか
OSS コントリビュートへの意欲・背景
私の OSS コントリビュートへの意欲・背景はちょっとした好奇心と挑戦心です。
「OSS にコントリビュートしている人ってかっこいい。ワイもなりたい。挑戦してみるか…」
こんな気持ちから始めており、言い換えるとコントリビュートすること自体が目的になっているタイプでしたが、それで全然OKだったと感じています。
というのも、実際にコントリビュートを終えた今となってはその考え方も変化しており、総じて「やってみてよかった」と感じているためです。（※このあたりは後ほど書きます。）
どんなモチベーションから始めても良いです。
興味がある方は、ぜひ一歩踏み出して挑戦してみてください。
OSS にコントリビュートするためにやったこと
続いて OSS にコントリビュートするためにやったことを書いていきます。
まず、自分は以下のような状況でした。
- どの OSS にコントリビュートするか決まっていない
- どんなコントリビュートをするかも決まっていない
コントリビュートすること自体が目的でしたから当然ですよね。。
この前提の元、OSS にコントリビュートするためにやったことを書いていきます。
1. 取り組めそうな issue を見つける
まずは、自分でも取り組めそうな issue をざっくりと探してみましょう。
good first issueという、OSS コントリビューション初心者が取り組むのにちょうどよい issue がまとまったサイトがあるので、こちらを見るのがおすすめです。
ただ、振り返ってみると issue を選ぶ際には 1つだけ守ったほうが良いと思うことがあります。
それは 自分が知っている OSS を選ぶこと です。
自分が知っている・普段使っている OSS であればある程度の動作がわかりますし、お世話になっているがゆえに issue 解決の気持ちも高まりますし、コントリビューションのモチベーションを高く保つことができます。
もし このサイトに自分の知っている OSS がない場合は、GitHub で直接自分が使っている OSS のリポジトリへ行き、 issue を good first issue ラベルで絞り込んでみるのも良いと思います。
ちなみに自分の場合、最近 golang を書き始めてモチベーションが高かったのと、業務で terraformを扱う機会が多かったため、terraform-provider-awsリポジトリの issue を選択しました。
Terraform を使って AWS を管理するのは自分にとって身近ですし、スター数も多くコミュニティも活発でちょうどよいなと感じました。
2. issue の内容を理解する
リポジトリと issue が決まったら、より詳細に issue を読み込んで内容を理解します。
英語で書かれていますが、翻訳ツールなども使いながらゆっくりと読んでいきましょう。
読み込んだ結果 issue の内容が理解でき、それが解決された状態も想像できるのであれば、後はどのように解決するのかの道中を考えるだけなので、ぜひその issue に取り組んでみるのが良いと思います。
なお、自分が取り組んだ issue はこちらです。
An ARN of CodeDeploy deployment config is necessary to build a correct IAM policy. My CodePipeline needs a
codedeploy:GetDeploymentConfigpermission which is resource-based, so currently it looks likearn:aws:codedeploy:${var.region}:${var.account_id}:deploymentconfig:${aws_codedeploy_deployment_config.main.id}- not very tasty.
IAM Policy 内で codedeploy:GetDeploymentConfig を行う対象を arn で絞りたいとき、頑張って arn を組み立てなくちゃいけなくて面倒だ、という内容が書かれてあります。
つまり、
- 問題:
aws_codedeploy_deployment_configのattributeにarnがないこと - 解決:
aws_codedeploy_deployment_configのattributeにarnがあること
なので、attributeにarnを生やすことが自分が取り組む内容だと分かります。
3. issue の裏付けを取る
issue の内容の裏付けを取りましょう。ようは再現です。
私は当時の最新バージョン（5.37）のドキュメントを確認しにいってみましたが、確かにarnのattributeありませんでした。実際にリソースを作ってみて今あるattributeの値の確認もしてみましたが、やはりarnを取得するのは不可能なようです。
これで、この issue の内容が正しいことが分かりました。
4. issue に取り組む
issue の内容が正しいことが分かったので、さっそく issue の解決に乗り出していきます。
ここが一番ハードルが高く、OSS にコントリビュートしてみたい気持ちはあるけど実行に移せない原因になっている箇所じゃないかと思います。何をどうすればわからないためです。コードの読み方もわからないですし、読める気もしないですし。
しかし、ありがたいことに OSS には コントリビューションガイド というものが存在します。
ガイドにはコントリビュートにあたって必要な要素が書かれてあります。以下は例です。
- 環境構築ガイド
- ソースコード構成のガイド
- デバッグのガイド
- テストのガイド
- コミット文、ブランチ名などのガイド
- PRに含めるべき内容のガイド
ガイドが、何をすればよいか、どこを見るべきか、のヒントをくれます。
自分は、以下のドキュメントや情報をじっくりと読んでいきました。
- terraform-provider-aws のコントリビューションガイド
- Terraform Plugin Framework のドキュメント
- 過去に解決された類似の issue
これにより、私はterraform-provider-awsの中身を全く知りませんでしたが、環境構築を行う、ソースコードの構成を知ってソースコードを読む、修正する、修正内容をテストする、といった一連の流れを行うことができました。
とにかく公式が用意しているドキュメントをしっかり読むことが大切だったと振り返って思います。
ここに根気強く時間をかけられるかが、OSS コントリビュートを達成するキーになりそうです。
また、good first issueにピックされるような issue は前例があるものが多いと思うので、過去の issue に参考になるものがないかを調べるのも有効だと思います。
5. PR を出す
テストも書いて動作確認ができたら、いよいよ PR を出していきます。
どのように PR を出せば良いのか不安になってしまいますが、これもコントリビューションガイドに載っているので焦らずじっくり読んでいきましょう。
ほとんどの場合、PR を出すと CI が走って PR 内容に懸念点がないかをチェックしてくれます。
CI が通れば、誰かがレビューしてくれますので気長に待ちましょう。（レビューの優先順位やかかる期間もガイドに載っていると思います。）
後はマージを待つのみです。
自分の場合は PR を上げたその夜にはすぐにレビューされ、マージされました。
OSS にコントリビュートしてみてどうだったか
1. 開発者としての意識が高まった・自信がついた
ついには自分の変更がリリースされ、今やその機能が Terraform のドキュメントに載っています。
ほんの少しの機能追加ですが、自分のコントリビュートにより Terraform で AWS が扱いやすくなったことが実感できるため、自己肯定感や自信が湧いてきました。
ソフトウェアを開発して世界に貢献できる、そして自分もその一人になれる、ということが認識でき、開発者として頑張っていきたい気持ちが高まりました。
2. 世界と繋がった感覚が得られた
今回の OSS コントリビュートの一連の関係者を並べてみると、issue を書いた方もレビューしてマージしてくれた方も日本人ではありませんでした。
今まで日本国で日本企業の中で日本語を話す人としか開発を行ったことがなかったので、物理的な制約を超えて世界の方活動を行ったのが新鮮で、なんだか世界と繋がった感覚を得られました。
そうか、ソフトウェア開発は国境を超えて活動できるんだ…みたいな感覚です。笑
グローバルに活躍するソフトウェア開発者になる、という選択肢に少しだけ視点が向いた気がします。
3. OSSコントリビュートへの壁がなくなった
OSS にコントリビュートできるのは技術力の高いつよつよソフトウェアエンジニアだけだと思っていたのですが、やってみると意外となんとかなったなぁという感覚を持っています。
もちろん高度な貢献はまだまだできないですが、自分でもできることがあると分かったためです。
今まで持っていたような、OSS コントリビュートへの壁は薄れました。
何事も実際にやるまでが一番ハードルが高いもので、やってみたら案外いけるものですね。
4. もっと OSS コントリビュートしたいと思うようになった
1~3の言い換えのような感じですが、OSS コントリビュートに対する意識が変わりました。
もともとは 「OSS コントリビュートいっちょ挑戦してやるぜ！」 みたいな気持ちだったものが、「自分ができる範囲で OSS に貢献できることが分かった。今後もなにか貢献したい」 という高次な価値観(?)を持てるようになり、なんだか精神的な成長を感じました。
日々お世話になっている OSS に issue があれば、ぜひ取り組んで貢献したいと思います。
おわりに
できないと思っていた OSS コントリビュートが、やってみると意外となんとかなるものでした。
そして、実際にやってみたことで開発者としての意識が変化し、より頑張っていきたいというモチベーションに繋がりました。
OSS コントリビュートに挑戦したいと思っている方は、ぜひ壁を感じずに挑戦してみてほしいです。
この記事が、OSS コントリビュートに挑戦したい方の一歩を踏み出すきっかけとなる記事になれば幸いです。
Discussion