OSS が静かに死んでいく道筋を、gpdf と gsql で塞いでいる話

今朝の Hacker News に「Dumb Ways for an Open Source Project to Die」という記事が流れていました。OSS プロジェクトが静かに死んでいく典型的なアンチパターンを並べた技術エッセイで、長年メンテナをやってきた著者の苦みが滲んでいる文章です。読み終わって、gpdf v1.0 を 2026 年 3 月にリリースしたあとの自分が、まさにこの「静かな死」とどう向き合うかを決めかねている時期だったことに気づきました。

「静かに死ぬ」の正体は、決定の不在

著者が並べているアンチパターンは、PR を放置するとか、ロードマップを公開しないとか、表面的にはありがちなチェックリストに見えます。でも一段降りて読むと、ぜんぶ「決定が下されていない状態が長く続いている」という同じ根を持っていることに気づきました。Issue の優先度を決めない、リリースのタイミングを決めない、外部 PR を merge するか close するか決めない。死ぬのは活動が止まるからではなく、決定が止まるからです。

これは個人 OSS で特に致命的に効きます。会社の OSS なら誰かが「決定の在庫」を抱えてくれますが、私のように 兼業で複数の Pure Go OSS を並走させている 場合、決定の在庫は私一人にしか積み上がりません。1 つの Issue に対する「今は対応しません」という回答を 200ms で返す力が、長期的なメンテ可能性の中で一番効く筋肉だと感じています。

gpdf が死なないようにしている3つの仕掛け

gpdf v1.0 は 2026 年 3 月にリリースしました。リリースから 2 ヶ月で、3 つの仕掛けを意識的に入れています。

1 つめは 「外部 PR を歓迎しない」と最初から明言する ことです。MIT で公開しているので clone と fork は自由ですが、本家への PR は基本的に merge しない、と README に書いてあります。これは冷たく見えるかもしれません。ただ外部 PR を merge するということは未来の自分が他人のコードの責任を持つということで、兼業で OSS を回す前提では持続できないと判断しました。代わりに antirez が DS4 を solo OSS mode に切り替えた のと同じく、報告と要望は Issue で受けて自分の手で書き直す方針にしています。

2 つめは リリースを「半年に 1 回」と決めて、それ以外の小さい変更を main にためる ことです。私がリリースを頻繁にやろうとすると、必ず途中で他のプロダクトの締切に押し出されて止まってしまいます。最初から年 2 回と決めておくと、Issue が来ても「次のリリースで」と返せて、心理的負荷が下がります。リリース日が決まっていることそのものが、決定を強制する装置になります。

3 つめは 失敗ベンチマークを _benchmark ディレクトリにそのまま置いておく ことです。これは公開している記事の主張のソースになるので、将来「あの数値はどこから来ていたか」を 3 ヶ月後の自分が辿れます。OSS の死因の多くは「過去の決定の根拠が消えること」だと思っているので、決定の痕跡を残しておくこと自体が延命策だと考えています。

gsql はまだ「死にやすい」段階にいる

正直に書くと、gsql のほうは gpdf より弱い構えで動いています。まだ v1 を切れておらず、Reddit の demand test で集めたフィードバックを反映するかどうかを保留にしている Issue が複数あります。元記事の表現を借りれば、私の gsql は「静かに死ぬ準備のいくつかの兆候」を既に持っていると感じています。

何が違うのかを考えると、リリースの儀式を一度通ったかどうかが大きい気がします。gpdf は v1.0 を出すために「PDF/A 準拠を v1 に含めるか」「電子署名 API は v1 で公開するか」のような決定を強制的に下しました。その儀式で決定する力が鍛えられたと感じています。gsql は儀式をまだ通っていないので、決定の在庫が積み上がりやすい状態のまま動いています。

これを書きながら、gsql の v0.x → v1.0 の cut を 2026 年第 3 四半期に置こう、と決めました。記事を書く副次効果でこういう決定が下りるなら、それも OSS を死なせない仕掛けの一つかもしれません。

質問への応答

「外部 PR を歓迎しない」は単に閉鎖的なだけでは?

そう聞こえるのは理解しています。ただ私が観察してきた範囲では、個人 OSS で外部 PR を歓迎して長続きしているプロジェクトはほぼ例外なく、メンテナの本業がその OSS に近いか、コミッタが複数人いるか、のどちらかでした。私の場合はどちらでもなく、本業はベンチャーの受託開発、コミッタは自分一人、夜と土日でメンテしている、という構造です。

この構造で外部 PR を merge すると、merge した瞬間にレビュー責任が残り、その PR が将来不具合を起こしたときに私が直すことになります。Issue で要望を受け、内容を理解し、自分の手で書き直す、という方針なら、コードベース全体の前提が私の頭の中で一貫して保てます。閉鎖というより、保てる構造に合わせて設計しているだけです。

今朝の他に読むべき記事

• Cursor ships Composer 2.5, claiming 10x efficiency over rival models (Cursor Blog) Composer 2.5 が $1/タスク以下で Claude Opus 4.7 相当の品質を出すと主張しています。AI コーディングが安くなることは個人で OSS を並走させる経済性に直接効いてくる、という意味で読みました。
• NGINX CVE-2026-42945 Exploited in the Wild (The Hacker News) CVSS 9.2 の RCE で、18 年前から潜んでいたヒープバッファオーバーフローが実環境で悪用開始しています。長寿命 OSS のセキュリティ負債の重さを示す事例です。1.30.1 へ即時アップグレード。
• Apple unveils new accessibility features with Apple Intelligence (Apple Newsroom) VoiceOver Image Explorer や Vision Pro の眼球コントロール車椅子など、AI とアクセシビリティの統合が一気に進みました。プロダクト設計の最低ラインが上がりそうな予感があります。
• Google just declared itself a contender in AI design (TechCrunch) Google が I/O 2026 で「Pics」「Stitch」を発表し、Figma と Canva に正面から張り合う宣言を出しました。デザインツール市場の構造変化が短期で起きそうです。
• Jury dismisses all claims in Elon Musk's lawsuit against Sam Altman (NPR) 陪審員が 90 分で全面棄却。OpenAI の IPO と営利化への法的障害が一段下がった、という意味で記録しておきます。
• Mistral AI acquires Emmi AI to expand physics AI (tech.eu) 欧州 Mistral が物理 AI に特化したオーストリアの Emmi AI を買収。3 ヶ月で 2 件目の M&A で、フロンティア LLM と垂直特化を束ねる戦略が見えてきました。

次に gsql の v1.0 cut の議論を始めるとき、決定が止まることが死なのだ、という今朝の文を、たぶん思い出します。