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

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などで定期的に発生しますので、その辺りも含めて柔軟に案が得るのがよいでかなと思います。

シェア:

Hidetaka Okamoto profile photo

Hidetaka Okamoto

ビジネスデベロップメント

DigitalCubeのBizDev。EC ASPの開発やStripeのDeveloper Advocateとしての経験を元に、SaaSやECサイトの収益を増やすための方法・生成AIを使った効率化や新しい事業モデルの模索などに挑戦する。

関連記事

生成AIは開発者の自己学習を加速する

lacolacoさんのブログが面白かったので、最近あった自分の体験をちょっと共有したいなと思います。 若手開発者の育成がAIによってむしろ有益になる理由 スキルの低い開発者にAIで下駄を履かせて生産性を補強するということ […]

生成 AI の考えを理解するために、ADR を作成する

最近オライリーの「ソフトウェアアーキテクチャの基礎」を1章ずつですが読んでいます。その中で見かけた「アーキテクチャデシジョンレコード(ADR)」に生成 AI を開発者・アーキテクトとして迎え入れる際のヒントを感じたので、 […]

2025年振り返り – 2回の転職にカンファレンスリブートなど

気がつけばあと5時間くらいですね。「あれもいる、これは買い忘れた」なんてことを言っていたら、年末は掃除と買い出し三昧だった気がします。 レイオフからはじまった2025年 いろんな意味で2025年は節目の年になりました。な […]

外資レイオフから日本の会社を経由してまた外資に行った話

万事塞翁が馬とはよく言ったもので、2025年もあと1ヶ月という状況に立ってみると、「案外悪くないところに着地できたな」という感じです。 どんな経歴だったのか? もともと内定も取れない文系大学生だったところから、アルバイト […]