OSS に出した PR がスルーされたときに自分がよくやること

自分が使っているOSSに対して、見つけたバグのパッチや機能要望でプルリクエスト（PR）を出してみることがあります。その際、個人が保守しているプロダクトだと返事がないことも少なくありません。そんな時に自分がよくやっていることを簡単に紹介します。

以前SNSで個人的にちょっと話題になってたやつをブログにまとめてみました。（元のスレッドはこちら）

なぜ PR がスルーされやすいか

自分でも複数の OSS を公開しています。そしてごく稀に pull requestや issue などが来るのですが、自分も結構放置しがちです。で、その理由が割と身も蓋もなく、「そもそも気づいていない」というケースがほとんどです。たまーに自分が必要となってそのプロダクトを保守しようとした時に、issueやpull requestが増えていることに気づく・・・みたいなことはかなりの頻度で経験しています。

こんな感じなのでPRを出しても反応がない場合、まず考えた方がいいのは「そもそも気づいてないのでは？」という点かなと思います。もちろん Hono の作者のようにキッチリ時間を確保してチェックされている方もいらっしゃいますが、「自分が使いたいから作って公開している」タイプのOSSについては、そもそも通知に気づいていないパターンがありえます。

1回リマインドしてみよう

ということで、「反応がないなー」と思った時は、IssueやPRコメントでメンションしてみましょう。英語で書くのが怖い・・・という方は、「any updates?」とか「If you need more information about this, please let me know」みたいな感じのを書くだけでもいいと思います。自分も放置しがちですが、PRを誰かに出すときも、リマインドを送ってみると「ごめんごめん忘れてた」とか「通知に埋もれてたわ」みたいなカジュアルな返事が来ることがまぁまぁあります。あと、メンションしてみることで「もうすぐローカルで作成したパッチを push する予定なので、アップデートをお待ちください」のような返事をもらえることもあります。アプデで対応されることがわかれば、あとはSNSなどでリリースのお知らせが流れるのを待つだけですね。

だからといってリマインドをしつこく送ると、「なんだこいつ・・・」と引かれることがあります。半月〜1ヶ月して音沙汰ないなーと思った時に1度聞いてみる。それで返事がなければ「そういうタイプのOSS」と理解する。こんな感じが開発者とユーザー双方にとってストレスなく付き合える関係かなと個人的には思っています。

返事がない場合

それもまたOSSです。自分のために公開しているタイプのOSSは、その人の都合でしか更新されません。たまにベンダーが出しているタイプのOSSもそういうのがありますが、まぁその話は傍に置いておきましょう。その場合はその人にとってメリットになる訴え方を考えてリベンジするか、forkして自分もまた自分のためのOSSとして公開するかのどちらかになるでしょう。その場合はライセンスもチェックしておく必要があります。

保守されていないケースもあります。使う場面が終わったケースなどですね。この場合はやはりforkするか、代替のOSSを探すことになります。いずれにせよ、「返事がこない・・・どうなってるんだ！」とヤキモキするよりは、「まぁOSSってそういうものではある」と考えるくらいの方がいいでしょう。特に組織ではなく個人が公開しているタイプのものに、充分なサポートを求めるのは酷な話です。

ごく稀に起きること

WordPressのような大規模なOSSでは、ごく稀に「2年前に報告したものが急に動き出す」こともあります。推測ですが、何かの機能開発PJが始動した時に、「あれ、これも一緒にやれそうじゃない？」のような形でバンドルされるか、本当に偶然メンテナーの目に入ったか、あるいは「古いopen状態のissue / PRなどを整理しよう」という取り組みが動き出したかのどれかではあると思います。

「そんな昔のこと、覚えてないよ・・・」となりますが、「反応がないから絶対に対応されない」というわけではないということで、頭の片隅においておくといいかもしれません。

OSSはどこまでいっても DIY

組織立ってサポート体制が提供されているOSSは、そんなに多くありません。仮にサポート体制があったとしても、世界中からリクエストが来るため、どうしても見落としや後回しになる可能性が残ります。

「今すぐ使いたいのに反応がない」という状況であれば、fork して npm などのリポジトリに公開する選択肢も検討してみましょう。アドオンとして公開して、後で本体への合流を目指すという進め方も、WordPressなどで定期的に発生しますので、その辺りも含めて柔軟に案が得るのがよいでかなと思います。