はじめに
SREチームの @minamijoyo です。
今回は最近社内でやってる、OSS開発に参加してみたい人の背中を押して回る草の根的な活動について書いてみようと思います。
クラウドワークス は Linux / Ruby / Rails など、たくさんのOSS (Open Source Software) のエコシステムの上に成り立っています。 むしろ現在のWebサービス開発はOSSなしに開発するほうが難しいでしょう。 つまりWebサービスを開発してご飯が食べられるのも、OSSのおかげと言っても過言ではありません。かくいう私は普段業務で Terraform をいじってることが多いので、たとえば Terraform の細かいバグを直してみたり、サードパーティのツールを作ってOSSとして公開してみたりして遊んでおります。
そんなOSS活動について、周りを見渡したところ、「やってみたいけど、やったことがない」というエンジニアが社内に少なからずいるようでした。 できてしまえば簡単なのに、なんとなくやり方がわからなくて不安なんだろうなーって思って、もっとみんなのOSS活動に参加する敷居を下げようと思いました。
．．． というのは建前で、
私事ですが、子育てエンジニアが継続的にOSS活動するのに、睡眠時間を削るのはつらいのです。（切実）
そこで、仕事中に業務に直接関係あるようなないような広い意味であるといえばあるようなOSS活動をする口実を得るのに、社内版 OSS Gate という企画を思いつきました。
- 参加者は、OSS活動に参加するとっかかりが得られ、社外へのアウトプットの実績ができる
- 会社は、OSS活動に理解のある会社として、エンジニア採用広報にプラス
- 私は、業務時間中にOSS活動する時間が増える
Win-Win-Win で三方良しで、我々ながら妙案ですね。策士か！？（自画自賛）
まぁホントは別に口実なんてなくても、勝手にやってよいんですけどね。活動に名前を付けることで、全方位に説明しやすさみたいなのは大事です。
今のところ半年ぐらいちゃんと続いてるので、この活動について紹介します。
クラウドワークス社内版 OSS Gate
ところで、 OSS Gate というイベントご存知でしょうか？
「OSS Gate」の目的は以下のとおりです。
「OSS Gate」は、OSS開発に参加する「入り口」を提供する取り組みです。 OSS開発に未参加の人を参加する人へ、少し参加したことがある人を継続的に参加する人へ。そうやってOSS開発に参加する人を継続的に増やしていく。それが「OSS Gate」の目的です。
ちなみに私は、本家の OSS Gate には参加したことはありません。（ないんかいw
以前 @koichiroo さんや @cesare さんが、会場の提供など運営のお手伝いをしていたこともあり、存在だけ認知しておりました。
クラウドワークス社内版OSS Gateは、目的は上記の本家と同じで、社内向けの説明の便宜上名前だけ勝手に拝借しておりますが、参加者が全員社員なので、運営は社内の事情に合わせて全然違います。本家とは直接関係ありません。
現状こんなかんじでゆるふわに運営しています。
- 休日に丸1日使うのではなく、業務時間中に週1で1時間枠を作って継続的に実施する。
- 毎週開催のため時間の制限がないので、タイムテーブル的なものは用意せず、各自の進捗に合わせて進める。
- 時間枠以外に土日とかに趣味の一部として勝手に進めるのは構わない。
- 初回参加しなかった人が途中参加もできるように、メンバーが増えたら運営などを都度説明してフォロー。
- 進捗や悩みごとは社内のSlackに共有し、誰かがPullRequestを投稿したり、マージされたりしたらみんなで喜ぶ。
初回のゴールは限りなく低く設定しています。
当たり前ですが、1週目の1時間でいきなりマージまでいけません。 そんなに簡単なら、もうみんなできてます。 細切れの時間でも細く長く1つのテーマに取り組み続けることが大事です。
以下は「戦術を学ぶ」ために、社内向けに書いた「OSSコントリビュートへの道」という文書を、多少加筆修正したものです。 ちょっと長いですが、社外に公開しても実害なさそうなので、誰かの参考になればと思い、ここに貼っておきます。
一人でも多くの人が、OSS開発の最初の一歩を踏み出せるとよいですね。
OSSコントリビュートへの道
目的
みんなはなんのためにOSSコントリビュートしますか？
目的はなんでも構いません。 ここでは目的はなんであれ、戦術について説明していきます。
OSSコントリビューションあれこれ
- ドキュメントの修正
- バグの報告
- バグの修正
- 機能追加
- 自分のコードをOSSで公開
なんでも構わないけど、最初の一歩はドキュメントの修正が一番ハードルが低い。
現状確認
ちょっとみんなにアンケート
- OSSコントリビューションしたことがない
- まずはドキュメント修正からやってみるとよいかも？
- PullRequestを送ったことがある
- リアクションがなくマージされないなら、アクティブなリポジトリを狙おう
- ドキュメント修正がマージされた
- 次はコードを修正してみよう
- コード修正がマージされた
- あとは自分がやりたいことをしたらよい
- 他の参加者をサポートしてくれるとうれしい
あなたがOSSコントリビュートできない3つの理由
OSSコントリビュートしたいのに、なぜできないのか？
- 時間がない => 定例枠を確保しました。毎週1時間、半年あれば24時間で3営業日ぐらいあるよ。
- 英語ができない => 自明な修正であればGoogle翻訳で意外となんとかなります。
- やり方が分からない => これから説明します。
OSSコントリビュートしてみよう
- 対象のリポジトリを決める
- 適切なサイズの問題を見つける=>これが一番難しい
- 修正する
- PullRequestを送る
- マージされるまでがんばる
順番に説明していきます。
対象のリポジトリを決める
- どれか1つに狙い撃ちするのがオススメ
- 適切なサイズの問題を見つけやすくなる
- ただ問題がうまく見つからない場合は、いくつかのリポジトリを見てもよい
- 自分が使っているソフトウェア
- 自分が使ってないとモチベーションが保ちにくい
- メンテナの人がアクティブ
- アクティブじゃないとPullRequest送っても放置されて悲しい
適切なサイズの問題を見つける
これが一番難しい
- ドキュメントの修正も立派なコントリビューション
- 最初の練習にはオススメ
- ドキュメント読んでて見つけたtypo
- インストール手順が分かりにくい
- 最近入った修正がドキュメントに反映されていないあるある
- 自分が使ってて不満に思った機能改善
- コードを読み込まないと実装が難しいことが多い
- この機能を追加するにはどこをいじればよいか？という意識でコードを読んで、意外と簡単そうってこともある
- プロジェクトの方針によっては拒否されることもある
- プロジェクトの方針にもよるけど、先にIssueを立てて方針を相談した方がよいかも
- 説明に若干の英語力が必要
- 自分が使ってて踏んだバグ
- 問題と修正が自明であればマージしてもらいやすい
- 自分が問題を発見したので、まだ誰も修正に着手していないのでチャンス
- 誰かが報告してるバグの修正
- 簡単なバグはすぐに修正されちゃうので、残ってるものは修正が難しいことが多い
- リポジトリが活発な場合、毎日Issueをチェックしていると、簡単な問題が落ちてることがある
- 新機能を試してバグを探す
- 新機能はだいたいバグってる
- 新機能はメンテナのモチベーションが高い
- バグを埋め込んだ人がコミット権を持っている場合、マージしてもらいやすい
大事なこと
- すぐに簡単な問題が見つからなくてもあきらめない
- 気になるリポジトリを継続的にウォッチする
- 何か自分で直せそうな問題がないかという視点でコードを読んでみる
- 完璧なソフトウェアなどない
- 大抵の問題は時間をかければなんとかなる
- 期限はない
- あきらめたらそこで試合終了ですよ
修正する
- ドキュメント修正だけなら、GitHubのWebブラウザから編集でも構わない
- コード修正の場合は、修正前のコードが手元で試せないと修正できない
- プロジェクトによるけど、開発者向けの情報は
README.mdとか*.mdに書いてあったりすることもある Contirubtion.mdとかCODE_OF_CONDUCT.mdとかあれば目を通しておく- 修正方法が自明ではない場合は、手元で動かしつつprintfデバッグしたりして問題を特定していく。このへんはケースバイケース。
- コード修正は基本的に自分のリポジトリにforkしてきて、作業ブランチを切ってpushし、本家にPullRequestを送る
PullRequestを送る
- バグ修正の場合はIssueも立てたほうがよい
- バグ修正の場合はPullRequestにはIssue番号とどうやって直しただけで十分。迷いポイントがあれば補足。
- テストが書きづらい場合は、稼働確認したログとかを貼るだけでもレビューワーの負担が減る
- 英語に自信がない場合は、他のIssueやPullRequestを参考にしつつGoogle翻訳
- 同じような修正のPullRequestを探して表現を参考にする
- Grammarly のChrome拡張が便利
- 英語のtypoと文法チェックしてくれる
- 有料版だとチェック項目が増えるが、無料版だけでも十分有用
- 入力データサーバに送るので、常時有効にせず必要なときだけ有効化するのがよい
マージされるまでがんばる
- レビュー指摘があれば直す
- 反応があれば、あとはレスポンスを早く返信して、指摘に対応していけば勝ったようなもの
- しばらく経っても反応がなければ、アクティブなメンテナの人にメンションしてみる
- マージされたらみんなに自慢して、承認要求のフィードバックループを強化する
やってみよう
各自、自分の気になるリポジトリを探してコード/Issue/PullRequestを眺めてみよう。 まずは、リポジトリを決めて、適切なサイズの問題を見つけよう。
アウトプットは社内のSlackに共有してね。
あなたがOSSコントリビュートできない3つの理由(再掲）
OSSコントリビュートしたいのに、なぜできないのか？
- 時間がない => 定例枠を確保しました。毎週1時間、半年あれば24時間で3営業日ぐらいあるよ。
- 英語ができない => 自明な修正であればGoogle翻訳で意外となんとかなります。
- やり方が分からない => まずはドキュメント修正から、その次はコード修正へ。自分がなんとかできそうな適切なサイズの問題を考え続ける。あきらめないきもち。
半年ぐらい続けてみて
半年ぐらい続けてみて、はじめてコード修正のマージまで達成した人が、新規に6名増えました。めでたい。
はじめてだとやっぱり、PullRequestを送るのに「この程度のしょうもない修正でよいのかな？」とか「なんかお作法間違ってないかな？」みたいな漠然とした不安が大きいようです。 私はお悩み相談にのって、「それでいいんだよ」って背中を押してあげてるだけです。マージされたらみんなでわいわい喜ぶのも大事。
社内のSlackの様子です。わいわいしている雰囲気だけお楽しみ下さい。
こんなかんじで、みんなでわいわいやると心理的なハードルが下がってよいですね。
参加するメンバーは途中で増えたり減ったり入れ替わっていますが、この手の活動は継続することが大事だと思うので、引き続きゆるふわに活動していこうと思います。
おわりに
クラウドソーシングのクラウドワークス では、 OSS活動が大好きなエンジニアを募集しております。
