はじめに
先日、以下の記事が Qiita トレンド入りしていました。OSS コントリビュートの魅力が伝わる良い記事でした。
こちらの記事に触発され、OSS コントリビュートに関する記事を書こうと思いました。
今回の記事では、最近簡単な OSS コントリビュートを達成して学んだことを踏まえ、OSS コントリビュートをなかなか始められなかった頃の自分に伝えたいことをまとめてみました。
想定読者
以下に書いてあるようなことがちょっとでも頭に浮かぶような方を対象としています。
(OSS コントリビュートする前の自分が考えていたことです)
- どんなリポジトリに OSS コントリビュートすればよいか見当が付かない
- ソースコードに修正を入れられないと OSS コントリビュートとは言えないと思いこんでいる
- 自分の英文が OSS のメンテナに伝わるか不安
tl;dr
この記事で伝えたいことは、簡単に・小さく・早く OSS コントリビュートを達成し、その嬉しさ・楽しさを実感してほしいということです。
本記事のアウトライン
まず最近達成した OSS コントリビュートについて、概要とコントリビュートした経緯を説明します。
その後、OSS コントリビュートの体験をふりかえった内容を、以前の自分に伝えたいこととしてまとめます。
最近達成した OSS コントリビュートについて
対象リポジトリ
今回 OSS コントリビュートを達成したのは、Dynomite という gem です。
GitHub - tongueroo/dynomite: A simple wrapper library to make DynamoDB usage a little more friendly
Dynomite は、Ruby 製のサーバーレスフレームワーク Jets から ActiveRecord ライクに DynamoDB テーブルを操作できるラッパー gem です。1300行程度の小さな gem です。
補足：検証記事書いています
Dynomite と Jets については、個人的に少しずつ技術検証しています。ご興味のある方はご参照ください。
- Ruby 製サーバーレスフレームワークの Jets を検証してみたら、Rails ライクに使えていい感じだった
- Ruby 製サーバーレスフレームワーク Jets から DynamoDB アイテムの CRUD 操作を試す
- Ruby 製サーバーレスフレームワーク Jets で DynamoDB テーブルを使ったサンプルアプリケーションを実装する
送ったプルリクエスト
Dynomite の Validations という機能の利用方法に関する README の記述を修正するプルリクエストを送りました。
Fix README about validations by gotchane · Pull Request #10 · tongueroo/dynomite · GitHub
修正したのはわずか2行。 validate を validates に修正するという、非常に簡単なプルリクエストでした。
プルリクエストを送ってからマージされるまでのいきさつ
技術検証でハマったことがきっかけ
今回プルリクエストを送ろうと思ったのは、もともと OSS コントリビュートをやってやろうと意気込んでいたわけではなく、技術検証でハマったことがきっかけでした。
以下の記事を書くために、「Jets で DynamoDB テーブルを使ったサンプルアプリを作るにはどうしたらいいのか？」ということについて技術検証していました。
Ruby 製サーバーレスフレームワーク Jets で DynamoDB テーブルを使ったサンプルアプリケーションを実装する
その中で Dynomite の Validations 機能を使おうと思い、README を参考に実装していたのですが、README に記載された validate メソッドだとエラーが出てうまく動かず、少しハマりました。
class Post < Dynomite::Item
include ActiveModel::Validations
column :id, :title
validate :title, presence: true
end
README の記述にズレがあることに気付く
なぜだろうと疑問に思い、include して使っている ActiveModel::Validations について調べました。
結果、Rails ドキュメント によると、 validate メソッドは独自のバリデーション用メソッドを適用する場合に使うメソッドであることがわかり、README の記載と使い方にズレがあることに気づきました。
こちらを踏まえ、 validate を validates と修正し、無事に動作するようになりました。
ふと思い立ってプルリクエストを出す
技術検証が進むようになり、一旦問題は解決したのですが、今の README の記述だと、自分みたいにハマる人がいるだろうなー、とちょっとモヤっとしていました。
そこで、ほんのちょっとの修正だし、プルリクエストを送ってみようかなと思い立ち、以下のようなプルリクエストを作成しました。
Fix README about validations by gotchane · Pull Request #10 · tongueroo/dynomite · GitHub
Dynomite は比較的小さなライブラリだったため、特に Description のフォーマット指定はありませんでした。
そのため、メンテナがプルリクエストの内容を最低限理解できるよう、以下を説明に盛り込んでプルリクエストを作成しました。
- 前置き
- プルリクエストを出した背景
- どんな修正をしたか
即マージにあっけにとられつつ歓喜
プルリクエストを出して他の作業をしていると、10分も経たずにマージの連絡が。
仕事早すぎませんか…！とあっけにとられつつ、後からマージされたことへの喜びが強く湧きました。
今回の OSS コントリビュートをふりかえって
ここからは上述した OSS コントリビュートをふりかえり、OSS コントリビュートを始められなかった頃の自分に伝えたいことをまとめます。
簡単に・小さく・早く OSS コントリビュートを達成し、その嬉しさ・楽しさを実感してほしい
冒頭にも書きましたが、まずこの言葉を過去の自分に伝えてあげたいです。
OSS コントリビュートは難しい、自分とは無関係だ、自分なんか相手にされないと思って敬遠するのではなく、簡単に・小さく・早くプルリクエストを出してみて、どんなものなのかを体感してほしいなと思います。
まずプルリクエストを出すと、何かしらのフィードバックを得られるチャンスが生まれます。加えてマージされると、強い喜びや楽しさを感じることができます。（僕自身はそうでした）
そして一度 OSS コントリビュートを達成すると、OSS に対する心理的ハードルが下がり、OSS がより身近に感じられるようになります。
OSS に対する心理的ハードルが下がると、「他に面白そうな OSS は無いだろうか」とか、「OSS の内部のソースコードはどうなっているのだろう」など、OSS に対する興味・モチベーションがより湧いてきます。
OSS に対する興味・モチベーションが湧けば、OSS コントリビュートにチャレンジする回数も増えていくことでしょう。その過程でソースコードを読みこむ量が増え、バグ修正や機能追加といった経験を通して技術力が上がり、今後のプログラマ人生に良い影響が出る可能性が高くなるでしょう。
今回のプルリクエストは非常に簡単なものでしたが、OSS への心理的ハードルも下がりましたし、OSS への興味・モチベーションも強くなりました。そしてこれからもっと OSS のソースコードを読み、バグ修正や機能追加もしてみたいと思っています。
このように、簡単でも良いので早い段階で第一歩としての OSS コントリビュートを体感することは、その後のプログラマ人生に良い影響がもたらされることになるのでは、と考えています。
簡単に・小さく・早く OSS コントリビュートするために意識したいこと
それでは、どうすれば 簡単に・小さく・早く OSS コントリビュートすることができるのでしょうか。今回の OSS コントリビュートをふりかえり、意識したいことをまとめました。
「大きくて枯れたリポジトリ」 よりも 「小さくて発展途上のリポジトリ」 の方がコントリビュートのチャンスが多い
大きいリポジトリよりも小さいリポジトリの方が、リポジトリの内容をキャッチアップするのもより容易になります。
また、枯れたリポジトリよりも発展途上のリポジトリの方が、今回のように README の間違いやバグに遭遇する機会が増えるでしょう。
Dynomite は、約1300行という小さなライブラリです。かつ、現在も活発に修正コミットがされていました。
今回の OSS コントリビュートをふりかえってみると、プルリクエストを出しやすいリポジトリだったのかなと思っています。
「ソースコード修正」よりも 「ドキュメント修正」 の方がコントリビュートのハードルが低い
一般的に、ソースコードの修正よりも、ドキュメントの修正の方が OSS コントリビュートのハードルは低いでしょう。
「OSS コントリビュートはソースコード修正してナンボだ」という思い込みを以前の僕は思っていたのですが、OSS コントリビュートを体験した今は、ドキュメント修正も立派な OSS コントリビュートだと考えるようになりました。
今回のプルリクエストのように、簡単なドキュメント修正を OSS コントリビュートの第一歩として取り組んでみることは、アプローチとして悪くないのではないでしょうか。
####「長文で読みにくい説明」 よりも 「簡潔で理解しやすい説明」の方がコントリビュートのフィードバックを受けやすい
OSS コントリビュートで利用される言語は英語が大半ですよね。どんな説明をすれば敬遠されないかと OSS コントリビュートする前の自分は不安に思っていました。
しかし現在では、拙い英語でも、ロジックが通っていれば内容は伝わると考えるようになりました。
今回のプルリクエストの説明では、日本語に訳せば数行のメールの内容程度のことしか書いていませんが、以下のような内容を説明に盛り込みました。
- なぜこのプルリクエストを出したか
- どんな修正をしたか
それでも、結果10分以内という短時間でマージいただくことができました。
10分というのは非常に稀なケースだと思いますが、仰々しく長い英文を書かなくても、メンテナが理解できるような最低限の説明があれば、フィードバックを得られる可能性は高いと考えています。
まとめ
- 簡単に・小さく・早く OSS コントリビュートを達成し、その嬉しさ・楽しさを実感してほしい
- なるべく早く OSS コントリビュートを体験するという第一歩を踏み出すことができれば、その後のプログラマ人生に良い影響が出る可能性が高くなる
- 簡単に・小さく・早く OSS コントリビュートするために、以下を意識してみると良い
- 「大きくて枯れたリポジトリ」 よりも 「小さくて発展途上のリポジトリ」 の方がコントリビュートのチャンスが多い
- 「ソースコード修正」よりも 「ドキュメント修正」 の方がコントリビュートのハードルが低い
- 「長文で読みにくい説明」 よりも 「簡潔で理解しやすい説明」の方がコントリビュートのフィードバックを受けやすい
おわりに
かなり長めの記事になりましたが、今回の OSS コントリビュートを踏まえ、OSS コントリビュートする前の自分に対し伝えたいことをまとめてみました。
この記事が、OSS コントリビュートを始めてみるきっかけに少しでもなれば幸いです。
また、こちらの記事は個人的な経験・考えをもとに書きましたので、フィードバックやコメント等、もしあればいただけるとありがたいです！