こんにちは。@willnetと申します。普段はRailsを使っている会社の技術顧問として、技術的な相談を受けたりエンジニアの教育をしたりしています。空いている時間を使って、自分がほしい機能が世の中にないときにそれを作ってOSSにしたり、既存のOSSの不具合を見つけたらできる範囲でなおしたりということをしています。著名なライブラリの作者でもないし、コミッタでもないです。
今回の寄稿記事では、そんな普通寄りなOSS開発者である僕が普段何を考えてどのように活動しているかについて書いていきます。
最近の困りごと
ここ数年、僕やお手伝い先で利用しているgemのメンテナンスに問題があって困ることが増えているような気がします。これはそれなりに利用者がいると思われるgemでもそうです。例えばseed-fuというgemは1.2kのスターを持ち、累計ダウンロード数は4000万を超えているgemですが最終コミットは7年前になっています。特に統計を取ったわけではありませんが、gemの不具合を見つけてGitHubのリポジトリを見に行くと、IssueやPRが放置されているケースに遭遇することが体感的に増えました。
理由は想像するしかないのですが、ぱっと思いつくのはメンテナが多忙になってしまったというケースです。僕自身も子どもが生まれたばかりのころはOSS活動はほぼできませんでした。
他には、作ったgemを作者が使わなくなってしまったというのがありそうです。僕は以前JSON Schemaを利用したRailsアプリケーションを開発するためにcommittee-railsというgemを作ったのですが、現在はJSON Schemaを使っていないためメンテナンスのモチベーションが下がっています。PRがきたら時間のあるときに気合を入れて対応してはいますが…。committee-railsでは新しいメンテナを募集しています。
Railsが流行った時期に作られたgemは、誕生してから10年以上経過しているものがほとんどであり、それをずっと使い続ける人のほうが少ないように思います。その中でもうまくメンテナを引き継げているケースもありますが、次のメンテナにバトンを渡せずに開発が停滞しているものが目立ちます。
困りごとにどう対応しているか
gemのメンテナンスが滞っていて困っても、基本的にGitHub上ではIssueを立てるかPRを作ることしかできません。なのでまずはそこから手を付けます。メンテナンスが滞っているということはIssueを立てても対応されない可能性が高いので、なるべくPRを作るようにしています。
しかし、いきなり不具合修正のPRは作れないことが多いです。なぜなら、メンテナンスが滞っているgemはCI環境が古いか壊れている、もしくはCI環境がないことがほとんどだからです。なので不具合修正のPRを作る前に、CIを整えるPRを出す必要があります。モチベーションが下がっているメンテナは期待通りに動くかどうかわからないPRを確認することが難しいはずなので、まず信頼できるCI環境を作るのが大事だと僕は考えています。
CI環境を作る例を挙げます。omniauth-oauthというgemは去年までTravis CIを利用していました。Travis CIはかつてはOSS開発時に使うCI環境のデファクトスタンダードと言っていい存在でしたが、現在はOSSでの利用に制限がかかっており、OSS開発時に気軽に使えるCIサービスとは言えなくなっていると思います。メンテナがTravis CIに利用申請をすれば使えるようですが、頑張ってTravis CIを使うよりもGitHub Actionsを利用するのが楽なので移行のためのPRを出しました。
すでにGitHub Actionsを使うようになっていても、最新のRubyやRailsでテストされていないことは多いです。そんなときは次のようなPRを出します。
該当リポジトリに最初にコントリビュートするときはGitHub Actionsが動かない設定になっていることが多いので、forkした自分のリポジトリ上でGitHub Actionsを動かして結果のリンクを貼っておくと親切です。
CIを改善するPRがマージされたらようやく不具合修正のPRが出せます。
PRを出してもメンテナからの反応がない場合
先ほど例として挙げた2つのPRは無事マージされました。しかしメンテナからの反応がない場合はどうしたらよいでしょうか？
とりあえずGitHub上でメンテナにメンションすると話が進むことがあります。例としてcapistrano-pumaというgemにCI環境を作るPRを出したときの話を挙げます。
capistrano-pumaはv6.0.0.beta1のリリースから2年間音沙汰がなく、さらにその2年の間、IssueやPRに対するメンテナの反応がまったくありませんでした。そのためダメ元でPRを出したのですが、他の人がメンテナにメンションしてくれたのを契機に話が進み最終的にv6.0.0がリリースされるに至りました。GitHub上の通知設定が「メンション時にメール通知する」になっている人が多いはずなので、メンションなら気づいてもらえる可能性があります。
Add tests and CI by willnet · Pull Request #375 · seuros/capistrano-puma
メンションしても反応がない場合は…どうしましょうね。メールなど他の手段でメンテナと連絡をとるという手段がぱっと思いつきます。しかし自分がよく使っているgemで「どうしても直したい！自分がメンテナになってもいい！」レベルのモチベーションがない場合はそのままにしてしまっています。
冒頭で紹介したseed-fuは僕がお手伝いしている複数の会社で利用していて、さらにどうしても直したい不具合があり、自分がメンテナになってもいいくらいのモチベーションがあったので作者にGitHub上でメンションし、メールを送り、XでのDMでも連絡を試みました。しかしそのどれにも反応がなかったので、最終的にforkすることにしました。rubygems.org上で公開するために名前をseed-doに変えています。
個人的にはforkは最終手段であり、なるべく本家をメンテナンスしていくのがいいと考えています。forkをすると、これまでseed-fuを利用していた人は移行のためのコストを払う必要があります。新メンテナ（僕）の立場だけでいうと自分の裁量で大きな変更を加えやすくなるため楽ですが、コミュニティ全体の幸福を考えるとあまりそれを選択したくはありません。gemの利用者にとっては、seed-fuの新バージョンがリリースされ、dependabotが自動で作ってくれたPRをマージするだけのほうが圧倒的に楽ですよね。なのでどうにかしてメンテナとコミュニケーションが取れるとよいのですが、現状取りうる手段だとどうしても限界があります。
OSS開発のハードルは下がっている
体感ですが、ソフトウェアエンジニアの中でOSS活動をしている人の割合はかなり少ないんじゃないかと思っています。一方で、お手伝い先やコミュニティなどで「自分もOSSに貢献してみたい！」という声はちらほら聞きます。しかし貢献してみたくてもどのOSSに貢献すればよいのかがわからなかったり、どのようにやったらいいのかわからなかったりして、一歩を踏み出せないことが多いのではないでしょうか。
貢献したいけど何をしたらいいかわからない人にとって、今の状況は悪くないと思います。自分が使っているライブラリのCIが整っているかを見てみましょう。超有名なライブラリを除けばだいたい何かしら改善点があります。新しいRubyやRailsのバージョンがリリースされる前後などは特にチャンスです。そして一箇所改善すると、そこから芋づる式に別の改善点が見つかるはずです。
改善点を見つけたらIssueもしくはPRにします。このとき、日本人のソフトウェアエンジニアにとって英語でのコミュニケーションがOSS開発における一番のハードルではないかと思うのですが、最近のAI技術の革新によってそのハードルはかなり下がっています。僕はChatGPTで次のようなカスタムプロンプトを用意しており、日本語を自然な形で翻訳させるようにしています。
こちらが入力した文章をすべて平易な英語に変換して返してください。GitHubのコメント、もしくはgitのコミットメッセージとして利用します。markdownの記号はそのまま保持してください。バッククォート記号はそのまま保持してください。
僕は英語を書くのが苦手で、なるべく英語を使わずにコードで表現できるような形でIssueやPRを書いていましたが、最近はその必要がなくなりました。
まとめ
僕がOSSに関して考えていることと活動内容について共有しました。OSS活動の雰囲気が少しでも伝わったでしょうか。もしこの記事を読んで「自分も何かやってみようかな」と思ってもらえたなら、とても嬉しいです。