資料ダウンロード

ククログ

株式会社クリアコード > ククログ > 「雑に立てられるissue」で疲弊しないためにOSS開発者ができること

「雑に立てられるissue」で疲弊しないためにOSS開発者ができること

要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。

結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。

「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言などが話題になっていました。私自身も、Firefox用にタブをツリー表示するサイドバーを提供するアドオンの「Tree Style Tab」をはじめとして、いくつかOSS開発プロジェクトを公開していて、数日に1件程度のペースではあるものの、日常的に報告を受けている2側の身として、そういった声を上げたくなる状況への同情が生じるのは否めません。

ですが、軽率な行動を咎める方向での提言や、相手をビビらせて追い払うような対応の仕方で、「質の低い報告が減り、開発がより快適に行えるようになる」効果が得られるかどうかについては、私は懐疑的です。というのも、真に開発者を困らせる雑な報告をする人は、そもそもそういった提言を見もしないし、気にも留めない3からです。その一方で、善意ある慎重な人は「もしかしたら、自分のしようとしているこれは迷惑なのかもしれない……」と報告自体を尻込みして去っていくことになります4。これではS/N比が悪化していく一方で、開発者にとっては辛くなるばかり5でしょう。

そこでこの記事では、OSS開発者向けに、「自分が疲弊しないための対策」「協力してくれる意志やポテンシャルがありそうな人への門戸は開きつつ、質の低いissueや無責任な人を遠ざけられるであろう方法」となることを期待して、私が個人的に実践していることや、社内で他の人が実践していることをご紹介したいと思います。

なお、私の経験上は、「困った報告」は英語で寄せられることが多いです6。よって、以下の文でも適宜英語の例文を挙げています。私は英語が達者な方ではないため、詳しい方が見れば違和感のある書き方になっているかもしれませんが、とりあえず「こう言ったら引き下がってもらえた」例ではあるということで、ご容赦下さい。 （ただ、近年は機械翻訳の精度が向上して利用者が増えたためか、日本語でしか書いていない情報に英語で問い合わせが来ることも度々あります。英語力に自信が無い場合、とりあえず日本語でだけでもいいので、まずは「書いておく」ことが有効かもしれません。）

この記事の目次

issue管理におけるプロジェクトオーナーの責任範囲を縮小しよう

OSS開発プロジェクトのオーナーとしての責任って、何でしょう。

忘れている人もいるかもしれませんが、オープンソースライセンスには大抵、「作者はソフトウェアに関して何の責任も負わない」という旨の免責事項が書かれています7。ですから本来は、「そんなん知らんがな」とあっさり言ってしまって構わず、イシュートラッカーを公開する義務も、メールで報告を受け付ける義務すらも、開発者にはありません8。

そこで「知らんがな」と言える人には私からは特に言うことは無いのですが、この記事のような話題に関心がある人はきっと、「知らんがな」とは言えない性格の人でしょう。相手に嫌な思いをさせたくない、相手から嫌われるのが嫌だ、自分が相手に冷たく振る舞った様子を第三者に見られて評判が落ちるのが嫌だ、自分の矜持に関わる、など、人によって理由は色々あると思います。かくいう私も、他人の目を気にして断りづらいタイプの人です。そういう人でも疲弊しないでいるためには、意識して適度に責任を手放すことが肝要です。

イシュートラッカーの運用目的を決めて、目的に沿わない状態のissueは閉じよう

GitHubのイシュートラッカーは、良く言えば自由度が高い、悪く言えばざっくりした管理しか行えないシステムです。「こういう目的で運用しよう」という意志を持って取り組まないと、あっという間に運用が破綻してしまいかねません。

私の場合、イシュートラッカーは「ソフトウェアの開発やメンテナンスを進めるため」ということを目的として、その目的に寄与するissue以外はクローズする、と決めています。具体的には、未解決のissueとしては、以下に該当するものだけをオープンにするようにしています。

  • 登録されて以後、プロジェクトオーナーがまだ目を通していない要望・報告
  • プロジェクトオーナー側で対応が進行中の物
  • プロジェクトオーナー側で目を通して、報告者による追加の情報提供待ちの物

これらに該当しない物は、後述する方針に則って機械的にクローズするようにしています。例えば、以下のようなissueは、オープン状態になっていても先述の目的には寄与しないため、クローズの対象にしています。

  • プロジェクトオーナーが目を通して、報告者による情報提供を待っているが、応答がない物
  • 既にある別のissueと全く同じ話題を扱っている物
  • Firefox側の不具合、OS側の制限など、外部要因による問題で、そちらでの解決が長期間図られないままの物
  • プロジェクトオーナー側で対応して、問題が解消されたか・機能が期待通りに動作しているか報告者に確認を求めている状態で、報告者の反応がない物9
  • 使い方やカスタマイズに関する「質問」

このようなissueにまったく意味が無い、とは私も思っていません10。ただ、あくまで私の決めた運用目的上は、「オープン」の状態にしておく理由がないのです。何かあればコメントを付けてもらえれば再度オープンする方針にはしていますが、これまでの所は、抗弁のコメントが寄せられるケースはほぼなかった認識です。

個人の性格による部分も大きいと思われますが、私は、閉じられていない状態のissueが大量に並んでいると、気分が滅入ってしまい、やる気が減退する感覚があります。どうも、プロジェクトオーナー側で何もできることがないissueと、対応が必要なissueとを見分けるという「判断」が日常的に多発するだけで、精神的な消耗が発生するようです。そういったissueは、「存在するだけでプロジェクト運営上マイナス」とすら言えます。

ここで述べたような「積極的にクローズしていく」方針に転換して以降、オープン状態のissueの数が激減したからか、私の精神的な負担は大きく軽減されました。

議論や質問はフォーラムに誘導しよう

イシュートラッカーは「問題を解決する」ためのツールですが、この「問題」とはあくまでOSS開発プロジェクトにとっての問題のことです。個人の問題、例えば「使い方が分からない」「設定の仕方が分からない」といったことを質問して解決策を得るのに有用なようにはできていません。ですが、この両者の区別を知らないためか、イシュートラッカーに個人の問題を個人の問題として投稿してしまう人は度々現れます11。

こういったissueは、issueとしてはクローズすると同時に、フォーラムへ誘導するのがよいです。

フォーラムは、Fluentdのユーザーコミュニティのように独自のサイトを立ち上げてもいいですし、GitHubで運用している開発プロジェクトの場合、Discussionsという機能を使う手もあります。リポジトリの設定で「Options」の画面の下のようにある「Discussions」にチェックを入れるだけで、StackOverflowやRedditのようなスレッドフロート掲示板式の機能が有効になりますし、issueを個別に閲覧したときの右のサイドバーの下の方にある「Convert to discussion」をクリックするだけで、issueをDiscussionsの投稿として移動することもできます。

フォーラムでは、ユーザー同士で個々人の問題を相互に解決し合うことができます。不具合の原因調査や修正方法の検討といった「ソフトウェアの問題解決」には開発の知識が必要ですが、そういった知識が無くても、「個人の問題解決」は使い方の工夫の範囲で行える場合が多いです。そのため、イシュートラッカーに比べると参加が容易で、回答も付きやすい傾向があるようです12。また、質問したくて訪れた人が、他の人の質問への回答者になってくれることもあります。単純な使い方の質問があまりに多く寄せられる場合には、ユーザーフォーラムを検討してみることをお薦めします。

報告者にリアクションを促そう

現在の所私は、いわゆるspamに該当するような場合を除いて、プロジェクトオーナー側で何も対応を取っていない状態のissueを即座に閉じるということは、基本的にはしていません。

では、「そのままでは対応できないissue」や「対応したくないissue」に対してはどうしているかというと、私はまず一旦は報告者のリアクションを求めるようにしています。

そうして、「オーナーが報告者にリアクションを求めたが、報告者からのリアクションがない」と言える状態にしてからissueを閉じる、という作戦です。これなら、issueが閉じられたのは報告者の責任ということになるので、必要以上に心を痛めずに済みますし、恐らく、傍目から見た印象もそう悪くはならないでしょう。

私の個人的見解ですが、「情報が不足しているissue」を投稿する人の多くは、「どのようなフォーマットを満たしていれば開発者にとってありがたい報告なのか」「そういった情報をどうすれば採取できるのか」を単純に知らないのだと、私は思っています。そういう人をすげなく追い返すよりは、「良い報告をしてくれる人」になってもらえるよう誘導することが、巡り巡って自分のためにもなる、と私は考えています。

どういう情報が書かれていると嬉しいのか・どうすれば情報を採取できるのかを案内することで、何人かに一人でもそれを実践してくれるようになれば、儲けものです。また、それを他の人のプロジェクトに対する報告でも実践してくれるようになれば、OSSの開発コミュニティ全体にとってプラスになるはずです。逆に、他の人のプロジェクトでそのように誘導された人が、私のプロジェクトで良い報告をしてくれれば、それももちろんありがたいことです。

報告者のリアクションがないissueは、botに自動で閉じさせよう

「情報提供を求めたが、一向に反応がない」という場合、どこかで期限を切って「応答がないのでクローズする」扱いにする必要があります。そうしないと、イシュートラッカーはすぐに「応答がなかったissue」で溢れてしまいます。

そのようにルールを決めていたとしても、問題が直っていないままのissueをクローズするのは心が痛むかもしれません。また、そもそも「最後に情報提供を求めてから何日経過した」ということをいちいち把握して、issueをクローズしたりリマインダーのコメントを付けたりするのは、それもまた大きな負担です。

GitHubで運用しているプロジェクトの場合、GitHub Actionsを使えば、そのようなissueを完全に自動で閉じることができます。そのためのActionとして、私が作ったのがこの2つです。

リポジトリのActionsが有効な状態で、.github/workflows/close-expired-issues.yml の位置にYAMLファイルを作成し、ラベルや日数を設定すれば、それだけでもう利用できます。実際に、Tree Style Tabプロジェクトでの設定例では、以下のように設定しています。

  • help wanted（手助けを求む）のラベルが付いてから30日（1ヵ月）経過したか、Firefox-issue（Firefox側の問題）のラベルが付いてから365日（1年）経過しており、且つ最後のコメントから1週間（7日）以上経過している物は、staleのラベルを付ける。
  • duplicated（重複）、expired（期限切れ）、wontfix（対応しないと判断した）、out of scope（プロジェクトのスコープに合致しない）、intentional（意図的な動作である）、invalid（このプロジェクトへの報告として不適切）のいずれかのラベルが付いてから1週間（7日）経過した物は閉じる。
  • has-workaround（回避策あり）、fixed（修正済み）、stale（進展なし）のいずれかのラベルが付いてから2週間（14日）が経過した物は閉じる。ただし、Reopenされたり、コメントが追加されたりした場合は、その都度クローズまでの期限を1週間（7日）延長する。
  • in-progress（対応進行中）のラベルが付いていない状態で、maybe fixed（恐らく修正できた）のラベルが付いてから2週間（14日）が経過した物は閉じる。ただし、Reopenされたり、コメントが追加されたりした場合は、その都度クローズまでの期限を1週間（7日）延長する。

期限到来時には、「何日経過したのでstaleのラベルを付けました、応答がなければ何日後にクローズされます（This issue has been labeled as "stale" due to no response by the reporter within N days. And it will be closed automatically N days later if not responded.）」や「Xというラベルが付けられてから何日間応答がなかったので閉じました（This issue has been closed due to no response within N days after labeled as X." ）」といったコメントが投稿された上で、ラベルが設定されたりissueがクローズされたりします。とにかく機械的に容赦なく処理してくれるので、未解決のissueクローズする後ろめたさから完全に解放されて、私としては非常にありがたいと感じています。

なお、「1週間」や「2週間」といった期限は、私の普段の開発ペースと、「まあそれくらいの期間があれば何かしらコメントしてくれるやろ」という希望に基づいて、恣意的に決めました。このあたりは、ご自身の時間感覚や状況に応じて適宜設定して下さい。

（これらのActionは、bdougie/close-issues-based-on-labelという既存のActionに基づいています。こちらは元々は「当該のラベルが設定されていたらcronでissueを閉じる」というシンプルな仕様だったのですが、上記のような「報告者がアクションを取るまでの猶予を持たせる」運用を取りたかったことなどから、色々と仕様を拡張して、このようにしてみました。元が簡単なRubyスクリプトだったので、irbを使ってoctokitでAPIを叩いた結果のレスポンスを見ながら、見よう見まねで改造することができました。）

繰り返しになりますが、イシュートラッカーは何のためにあるかというと、問題を解決してプロダクトをより良くするためだ、と私は考えています。実装もされない・対応の予定もない・まったく動きがないissueが積み上がることはその目的にとってマイナスなので、そういうissueはクローズされていた方がプロジェクトのためである、と割り切っています。

要望や提案を断りやすくしよう

ここまでの話は、「対応する」「対応しない」といった判断を行った後のissueの処理についての話でした。しかし、そもそも「対応しない」という判断をすること自体に迷う人もいることでしょう。

OSSを開発していると、自分自身での思いつきや、公開後に寄せられた提案・要望を、良かれと思って無制限に取り込んでしまいがちです。しかし、その末路は、コードの肥大化で身動きが取れなくなることによる破綻と自滅です。そうならないためには適宜「NO」を表明することが必要です。

ただ、頼まれごとを断るのは勇気が要ります。嫌われる・見捨てられることへの恐怖には、一体どうやって立ち向かえば良いのでしょうか？

何を「やらない」かを判断して、理由を言葉で説明しよう

問題の報告に対して「修正するか、しないか」、新機能の追加の要望に対して「追加するか、しないか」など、やるかどうかの判断をする場面では、実は「やる理由」だけでなく「やらない理由」も重要です。「やる理由」は意識していても、「やらない理由」は意識していない、という人は結構いるのではないでしょうか13。

例えば、私は実際に、Firefox用の拡張機能「Tree Style Tab（TST）」に寄せられた要望に対し、以下のような「やらない」判断をしたことがあります。

要望 示した判断 英語での言い方
Safariに対応して欲しい APIの制限のため、Geckoベースでないブラウザーへの移植は今のところ不可能です。 TST cannot be ported to non-Gecko browsers for now, due to API limitations.
何々というオプションを増やして欲しい 「高いカスタマイズ性」はプロジェクトのスコープ外なので、そのオプションは追加しません。オプションを増やしすぎると、TSTのコンセプトが曖昧になり、私がこのプロジェクトで大事にしたい物と違う物を欲する人を意図せず引き付けてしまって、最終的にプロジェクトの破滅につながるからです。
新しいオプションを受け入れるかどうかは、以下の判断基準に従って決めます：（中略）ただし、歴史的経緯によって、これらのポリシーに反するオプションが現存している場合があることに注意が必要です。		 The option won't be added, because high customizability is out of scope. Too many options would kill this project, because they would cloud the main concept of TST and would attract people who don't share my core vision.
Here is a list of policies about accepting or rejecting new option requests: (snip.) Please remind that some existing options may violate these policies due to historical reasons.
Pale Moon（非常に古いバージョンのFirefoxからの派生ブラウザー）に対応して欲しい 個人の時間では対応しきれないため、Mozillaのサポートが行われなくなったバージョン、およびそれらを元にした派生ブラウザーには、対応しないことにしています。 I never support expired versions of Firefox (and other projects based on such versions) anymore, because I can't take enough private time to support them.

大事なのは、どの判断も言葉で理由を説明しているという点です。「なんとなく」では済ませないのがポイントです。

私の経験上は、「やらない」理由を詳しく言葉で説明すると、大抵の場合は引き下がってもらえる印象があります。食い下がられるケースでも、根拠を挙げてさらに詳しく説明すると、納得してもらえることが多いと感じています14。

判断の理由を一度言語化しておけば、似た要望が寄せられた場合に、「それはやらないことにしている。理由はこちらを見てほしい」と案内したり、説明文をコピー&ペーストしたりといった形で、より少ない手間で説明できるようになります15。また、issueに対応する時だけでなく、自分で実装したりメンテナンスしたりするときも、以前に行った判断に機械的に従うだけでよくなります。判断の理由の言語化には、このように、issueの対応のみならず普段の開発においても、考える事が減って、心理的な負担が軽減される効果があります。

判断を示さずに曖昧なままにしていたり、放置していたりすると、同じ要望が何度も何度も繰り返し寄せられることになります。ユーザーは残念ながら、あなたの真意を察してはくれません。「言わないと分からない」ということで16、対応する可能性がない要望には早々に「対応しない」とはっきり言ってしまいましょう。その方が、報告者もすっぱり諦めが付いて、早く前に進めるというものです。

外部要因に基づく判断の場合、そのように明記しよう

要望を断る理由として最も言いやすいのが、外部要因による制約です。仕様上の制限事項だったり、依存ライブラリの制限事項だったりといった、自分ではどうにもできない理由である場合には、そう明記するようにしましょう。前項の例でも、「Safariに対応して欲しい」という要望に対して「（ブラウザーが機能を提供していない、という）APIの制限のため」と判断理由を示しています。

このような場面では、私は「due to ～」（～のせいで）という表現をよく使います。APIの制限のせいで実現不可能なら「It is impossible due to restrictions of API.」、OS自体の不具合のせいで修正不可能なら「It can't be fixed due to a bug of the OS itself.」という具合です。

また、依存ソフトウェアの該当issueのURLや、仕様のドキュメントのURLなど、説明の根拠になる情報へのポインタも示しておくと、なおよいです。「作者が言ってるだけ」よりは「依存ソフトウェアの開発者もそう言っている」といった様子を確認できた方が、より説得力が増します。

そういったことを「責任転嫁」と取る人もいるかもしれませんが、強引ななすりつけでない限りは、責任分解点を正しく見極めただけのことです。むしろ、責任分界点を踏み越えて自分の側で勝手なことをしすぎてしまう方が、後々より大きな問題を招く場合もあります。

例えば、Firefoxはかつてアドオン側に大きな自由度を認めていたことから、Firefox本体に動的にパッチを当てるような形で、本来Firefox側で解決するべきだった問題までアドオン側で無理矢理解決してしまっていた場合が度々ありました。そのようなアドオンは自然と、Firefoxの特定のバージョンの実装内容に強く依存します。そのため、「アドオンが動かなくなった」という苦情を避けるために、Firefox本体に修正も改良も加えられない状態が発生してしまっていました。

そういった事態を防ぐために「自分のプロジェクト側では対応しない」と判断するのは、OSS開発者の取るべき正しい対応である、と私は考えています。正しい判断をしたことを責められる謂れはありませんので、報告者からそれ以上の対応を懇願されても、良心の呵責に悩む必要は無い、と私は割り切ることにしています。

「できるけど、やらない」と判断した結果を一箇所にまとめて、プロジェクトのスコープを明確化しよう

技術的に実現可能でも、すべての要望に応えられるわけではないです。寄せられた要望に対して「うーん……」と少しでも悩んだときには、それは「可能でも、やらない方がいいこと」かもしれません。

そのような判断の基準となるのが、「プロジェクトのスコープ」です。私の場合、「その要望はプロジェクトのスコープ外なので、やらない（I won't do that, because it is out of the project scope.）」という断り方は非常によく使います。

スコープとは、物事の影響範囲や対象領域のことです。OSS開発プロジェクトでは、「これは何のためのプロジェクトか、このプロジェクトでは何をやるのか（プロジェクトの目的）」を定義すると同時に、「これは何のためのプロジェクトでないか、このプロジェクトでは何をやらないのか」を定義する物でもあります。プロジェクトの健全性を保つには、前者と後者の両方が必要です。

とはいえ、プロジェクトの開始時点からはっきり「ここからここまで」とスコープを言葉で説明できないことは多いでしょう。なので私は、プロジェクト開始時点では、ざっくりした目的（「何をするか」）だけ決めるようにしています。その上で、自発的なものであるか、ユーザーからの要望であるかを問わず、機能を追加するかどうか判断の必要が生じる度に、「やるべきか、やらないべきか。やらないのなら、それは何故か」を考えて、判断基準を文章として形にして、その結果をスコープの定義に加える、ということを継続して行い、スコープを整備するようにしています。

実際、先の表の例の「何々というオプションを増やして欲しい」という要望に対しての「スコープ外なのでやらない」という判断は、複数の人からさまざまなオプション追加の要望が寄せられる度に行った、個別の「これはやる、これはやらない」という判断の集積です。本稿執筆時点で示したことがある、Tree Style Tabプロジェクトのスコープに関わる言語化された説明には、以下のようなものがあります。

日本語での表現 英語での表現
「ブラウザーのタブをツリー構造で管理する」というコンセプトに関係のない機能は、原則として提供せず、その機能を提供する他のアドオンと併用してもらう。機能をうまく併用できない場合、併用できるように修正するか、連携するためのAPIを設ける。 If the requested feature is not related to the concept "management of tabs with tree structure", it won't be added generally. Instead I recommend you to add another addon providing the feature. If its feature does not work together with TST well, fix the incompatibility or add API for better collaboration, on any side TST or the addon.
Firefox自身のブックマーク管理機能や、Windowsのエクスプローラのフォルダツリー、Adobe Illustratorのレイヤツリーなど、類似した既存のUIがある場合、ユーザーの混乱を最小化するために、操作性はそれに合わせる。言い換えると、既存の実装とあまりに異なる操作を求める動作にはしない。 If there are any other existing applications providing similar UI (e.g. bookmarks tree of Firefox itself, folder tree of Windows Explorer, layer tree of Adobe Illustrator), TST should simulate their experience as possible, to minimize users' confusion. In other words, some behaviors won't be introduced if they are quite different from experiences on existing implementations.
一貫性に則って最適な動作を自動判断できるなら、例外的な動作の選択肢をユーザーには示さない。膨大な数のオプションでユーザーを混乱させないため。 If TST can react to something based on its consistent behaviors, TST just provides fixed auto-detected behavior instead of user-choosable options. Because to avoid users' confusion from too much options.
タブの動作について、Firefoxがそのようなオプションを提供しているなら、TSTでもその動作を再現するオプションを実装するのが望ましい。 If Firefox has the option around browser tabs, TST also should provide similar option to emulate it.
TSTがFirefoxの動作を模している部分で、Firefoxがオプションを提供していないなら、TSTもオプションを提供しない。 If TST imitates Firefox's UI and Firefox doesn't provide any options to control them, TST basically don't provide options for them.
アクセシビリティ的に重要な場合、TSTにオプションを実装するのが望ましい。 If it is essential for accessibility, TST should provide the option.
単純なCSSでのカスタマイズで実現できない場合、オプションを実装するのが望ましい。 If it is impossible to be done via simple CSS tricks, TST should provide the option.
他の拡張機能との組み合わせでできることの場合、オプションを実装しない。 If it is already available during combination with another extension, TST don't provide options for them.

判断基準を言語化するにあたっては、「状況が変わったので、判断を変える」あるいは「状況が変化していないので、従来の判断に従う」といった決断をスムーズに行えるように、それぞれの基準の根拠も併せて言語化しておくとよいでしょう。

issueのコメントで「やらない」判断を理由を挙げて説明した後は、それを後日参照しやすくするように、一箇所にまとめて整理することをお薦めします。具体的には、以下のような運用があり得るでしょう。

  • README.mdに「プロジェクトのスコープ（project scope）」という見出しを作り、箇条書きにしていく。
  • README.mdにFAQのセクションを作り、そこに「要望」と「やらない理由」を一問一答形式で転記する。
  • WikiにFAQのページを用意し、そちらに箇条書きにしていく。

「FAQ」は「Frequently Asked Questions（頻繁に聞かれる質問）」の略とされていますが、私は一度聞かれただけの物でも（何ならまだ一度も聞かれていない物でも）記載していいと考えています。「これが機能として含まれていないのはなぜ？」「こうなっていないのはなぜ？」の答えは、言葉を使って説明するしかないからです。

言語化された基準を集積して整理する過程で、判断がぶれていると感じた場合、そこには全く別の判断基準が隠れている可能性があります。そのようなときは、次に回答するときに口ごもらないで済むように、「なぜそう判断したのか、なぜ判断がぶれたのか」を掘り下げて考えてみることをお薦めします。

寄せられた要望を断るのは、ストレスになりがちです。勢い、「断らざるを得ない要望を寄せられること」自体を苦痛と感じてしまうかもしれません。ですが私は今のところは、言葉にして説明することでプロジェクトのスコープを明確化するいい機会になる、と前向きに捉えることで、今までになかったタイプの要望が寄せられることに対しては、そこまでの強いストレスを感じずに済むようになったと思っています。

自分では対応しきれない場合、実装を提供してもらえるのを待とう

技術的に可能で、且つ、プロジェクトのスコープに合致する要望でも、自分で手を動かして実装する気が起こらないケースはあります。例えば以下のような場合があるでしょう。

  • 自分では使いそうにない機能である。
  • 自分では実装が大変そうである。
  • 自分では試せない環境17の話である。

こういう場合に、寄付金を募る方針を選ぶ人もいますが、私は基本的にはコードや労力の提供を募るようにしています。具体的には、「いい提案だけど、私は使わない機能なので、私の手で実装する予定はないです。機能の必要性が高い場合、forkして機能を実装した上で、必要に応じてプルリクエストして下さい。もしかしたらマージするかもしれません（The idea sounds good. But sorry I have less motivation to implement it by myself, because I personally won't use the feature on my daily life. If you seriously need it, please fork this repository and implement it the feature, and send me a pull request if needed. I may merge it if it is enough reasonable for this project.）」のように、先に挙げた例のような理由を示した上で、実装待ちの姿勢であることを表明することが多いです。

「それで本当に実装してくれる人が現れるのか？」というと、私の経験上は、実装までしてくれる人はほぼいません。なので大抵の場合は、「作者がさじを投げて、誰も実装せず、放ったらかし」という見え方になることが多いです。

そうなると分かっていながら「実装待ち」の姿勢を取ることを、「無責任だ」と思う人もいるかもしれません。私もかつては、要望を出す側としても要望を受ける側としても、そう思っていました。ですが、それは作者の責任を過剰に大きく捉えた考え方です。むしろ、判断の理由を言葉で説明したり、報告者が次に取るべきアクションまで案内したりしているなら、すでにもう十分に「持ち出し」で動いている状態です。

個人が行うOSS開発プロジェクトでは特に、「作者が困っている事を優先して対応する」「作者が困っていないことは後回しにする」という判断をすることが大事だと、私は思っています。

「他人の要望に振り回されて、ソフトウェアが作者自身にとって不便な物になってしまい、作者自身がそのソフトウェアを使わなくなってしまうこと」や「作者が疲弊してプロジェクトが停滞してしまい、解決したかった困りごとが解決されなくなること」は、個人のプロジェクトにおいて最も避けるべき事態です。そのような状況に陥らないように、プロジェクトを・作者を守るための判断は、プロジェクトオーナーであるあなたが下すしかありません。他の誰も、プロジェクトやあなたのことを守ってはくれないのです。

次の項で詳しく述べますが、自由に再利用できる形で実装の詳細を開示した段階で、あなたはもう最低限の責任は果たしたと思って大丈夫です。「要望に対応できないこと」に申し訳なさを感じなくてはならない道理はないので、安心して断りましょう。

プロジェクトの手離れをよくしておこう

「私の手では実装する予定はないので、プルリクエストして下さい」にせよ、「このプロジェクトでは要望に対応しないと判断しましたが、どうしても必要ならforkして改造して、別プロジェクトとして運営して下さい（I decided to reject your feature request on this project, but if you seriously need the feature, please fork this repository and improve it as you like.）」にせよ、そのように言うためには、「相手がforkを安心して実行できること、他の人が開発を引き継げる可能性が閉じられていないこと」が大前提になります。

  • コードにオープンソースライセンスが設定されていないと、他の人は、安心して派生版を開発・公開できません。ライセンスを明示し忘れている場合は意外とあるので、忘れずにライセンスを設定しておきましょう。
  • ライセンス面の問題がなくとも、リーダブルでないコードは、他人が見た時に手を入れにくいです。書籍「リーダブルコード」を読んでみるなどして、意図を把握しやすい名前付けや設計を心がけるようにしましょう。
  • FAQの話とも重なりますが、「なぜそうしているのか」「なぜそうしなかったのか」という情報は、コードからは読み取れません。それらの説明になるように、コメントやドキュメントも、できる範囲で整備しましょう。
  • 開発環境のセットアップ手順やビルド手順などは、READMEに「開発者・コントリビューター向けの情報（For developers and contributors）」のような見出しを設けて説明を用意したり、自動実行で完結できる部分は自動化したりして、誰でもすぐに開発を始められる状態を整備しておきましょう。

総じて、「プロジェクトの手離れをよくしておく」のが大事です。そうしておくことで、「私は、現実的に可能な範囲で私にできることをしています。誰でもすぐ開発に参加できる・開発を引き継げる状態にしてあるのだから、バトンはもうあなたの側に渡っているのです」と言える状態になります。開発者として、「これ以上のことはしなくても責められる謂れはない」という、ある意味で心の免罪符が手に入るわけです。相手が「私にはとてもできない！」18と言ったとしても「うん、でもプロジェクトオーナーの私にもできないんだ」と返すわけです。

なお、初めての人でも開発を引き継ぎやすいようにしておくのには、もう1つメリットがあります。それは、実際に誰かが引き継いでくれるかどうかに関わらず、そのプロジェクトのことを常に考えなくてもよくなるということです。

自分の脳内にしかない情報に強く依存した、初見の人には何が何だか分からない状態のプロジェクトは、少しでも離れてしまうと、作者自身であっても途端に再開が難しくなります。状況が分からなくなるのを防ぐためには、四六時中そのプロジェクトに張り付いたままにならざるを得ません。それでは他のことに手を出せず、活動の幅が狭まってしまいます。そのように1つのことに縛られずに、気軽に目を離して、それなりの期間放置してしまった後でも、必要になったらまた戻ってきて、スムーズにプロジェクトを再開できる、という状態になっていた方が、結果的には長続きするプロジェクトになるというのが、私の持論です。

責任を抱え込みすぎないようにしよう

ダメ押しでもう一度書きますが、OSS開発プロジェクトで疲弊しないために大事なのは、「プロジェクトオーナーだけにすべての責任が降りかからないようにすること」だ、と私は考えています。

プロジェクトを健全な状態に保とう

ここまでの話では、issueのテンプレートを整備したり、ドキュメントを整備したり、判断基準を定めたり、といった色々な施策をお薦めしてきました。そういった施策をコストをかけて実施することを、億劫と感じる人もいると思いますが、私は、それらは「プロジェクトが生きていくために避けられない、必要なこと」だと考えています。

独り暮らしをしている人にとって、家事は「義務」ではありませんが、「他に誰もやってはくれない」「やれば生活は快適になる」「快適な生活を手に入れたければ、対価を払って誰かにやってもらうか、自分でやるかしかない」ものです。私は、それと同じだと考えています。あるいは、プログラミングの文脈では、「自動テストの整備と同じようなもの」と言った方が伝わりやすいかもしれません。

また、これは完全な私見ですが、「自分が立ち上げたOSS開発プロジェクト」について、「作者」としての執着自体を持たないようにすると、責任を取ることを求められても「知らんがな」と言いやすくなると思っています19。

「世の中にこういう問題があるが、どうもまだ誰も解決策を実装していないようだった。そこで、解決策の具現化に挑戦して、成果にオープンソースライセンスを設定して公開した。そうして共有財産として社会に解き放った時点で、自分はもう、一人のコントリビューターとしての責任は充分に果たした。後はみんなで解決していきましょう。自分のアカウント配下にあるのは、その社会の共有財産の1つ目のforkでしかなく、他の人のforkとの間で地位に差は無いですよ」というくらいのスタンスでいると、疲弊して心を病んだりしないで済むのではないでしょうか。

OSS開発プロジェクトによっては、開発者やコントリビューターが従うべきCode of Conduct（行動規範）が明示されている場合があります。一般的によく目にするCoCで言われていることは、要するに「お互いに敬意を持って、建設的に議論し、協力しあおう」ということです。私はこれを、「プロジェクトオーナーといえども滅私奉公する必要は無く、自身にできる範囲でプロジェクトに関わればそれで問題ない。そのようなプロジェクトオーナーを悪し様に罵って『要求を呑ませてよい』権利は、誰にもない」ということだと解釈しています。

CoC違反に罰則を与える上位者が存在しない以上、毅然とした判断を示してCoC違反に対処できるのは、プロジェクトオーナーだけです。皆さんもどうか、プロジェクトと皆さん自身を守った上で、健全に且つ長く、プロジェクトを継続してもらえればと思います。

企業でも要領は同じ

ここまでの話は個人のOSS開発者を想定して書いていますが、企業の名前の下で公開するOSSでも、同じ事が言えます。

自社のビジネスに直結するソフトウェア20や、自社のブランドとして育てたいようなソフトウェアだと、そうもいかないのですが、「自社内での利用のために作ったちょっと便利なツールやライブラリ」くらいの物であれば、ここまでに述べたのと同様の方針でプロジェクトを公開・運営して問題無いと、私は考えています。

この記事で述べたような方針であれば、障害の報告や要望への対応が、普段の業務に大きな影響を与えることはそうそうないでしょう。そうして小さいところからでもOSS開発コミュニティと関係を持つことによって、ゆくゆくは、優秀な技能を持った開発者の採用などにつながるかもしれません。

責任を持って何かをするのは、仕事でやっている人に任せよう

「責任を抱え込みすぎないようにしよう」と散々述べましたが、「そんな誰も責任を取ってくれない物、企業じゃ怖くて使えないよ！」と思う人もいるかもしれません。

そのような場合のためにあるのが、有償のサポートサービスです。実際、私が所属する株式会社クリアコードでは、FirefoxやThunderbirdの法人向け有償サポートサービスの範囲内で、お客さまからの依頼に基づいて、既存のサードパーティ製アドオンの不具合の調査をしたり、特定顧客向けに改造版を作成・提供したり、新規のアドオンを開発したりしています。

対価を支払ってでも責任を取って欲しい人（企業）と、責任を取る代わりに対価を得たい人（企業）がいると、そこにビジネスが生まれます。オープンソースライセンスを設定しているのであれば、ビジネスをしたい人達は、プロジェクトオーナーのあなたに関係なく勝手にビジネスを始めるものです。

サポートを申し出た企業があなたに「うちは金をもらってるんだ、なんとかしてくれ！」と泣き付いてきたとしても、もちろん（ここまでで述べたとおり）あなたがそれに応える義務はありません。そもそも、そういったサポートを提供できる企業とは、「元作者に泣き付かなくても、いざとなればforkをして顧客向けに責任を果たせる」だけの技術力があるか、もしくは、そういったケースはサポート対象外になるような条件で、契約を顧客と結んでいるものです。なので、プロジェクトオーナーのあなたは安心して無視を決め込んで大丈夫です。

まとめ

以上、私の個人的な経験をベースとして、issue対応に追われがちなOSS開発者が、なるべく疲弊しないでプロジェクトを継続するために行える、issue対応や開発の意思決定での工夫をご紹介しました。

「相手の抱える問題が解決されていようがいまいが、プロジェクト側で決めたクローズ条件に従ってissueをクローズする」という結果だけを見ると、要望を無下に突っぱねるドライで厳しい対応と感じられるかもしれません。 ですが、同じ「断る」という結論であっても、私はなるべく相手に納得して引き下がってもらいたいですし、「自分の努力と工夫次第で道は開ける」という希望を持ってもらいたいと思っています。 そのように説得的に振る舞うことで、問題解決に取り組む側に回る人が少しでも増えてくれることを、願ってやみません。

また、GitHub Actionsアドベントカレンダーへのエントリーということで、このブログで過去に取り扱ったGitHub Actionsの記事も紹介しておきます。OSS開発プロジェクトの定型タスクを自動化したい開発者の方に、参考にして頂ければ幸いです。

当社では、お客さまのご相談に応じて様々なOSSのサポートを提供しております。 法人でのOSSの運用に際して技術的な詳細の問い合わせ先をお探しのご担当者さまは、是非当社までお問い合わせ下さい。

  1. 具体的には「issueを立てるな！」という記事です。丁寧に読むと「良いissueの立て方をしよう」ということが書かれているのですが、そこまで読み取る前に「そうかissueは立てない方がよいのか」とだけ受け取る人が多のではないか、と私は思っています。 ↩

  2. 具体的には、Tree Style Tabプロジェクトのイシュートラッカーは11年間で2633件となっており、約1日半で1件（1日あたり0.6件）の登録があったことになります。 ↩

  3. 実際に、私のOSSプロジェクトでは「GitHubでissue登録時に必ず自動入力されるテンプレートをわざわざ消してまで、雑な内容のissueを登録する」ケースは珍しくないです。 ↩

  4. 少なくとも私は、そうして尻込みしてしまう側でした。また、希望者を募って開催している、その人自身が遭遇したトラブルやつまずきをOSSのプロジェクトにフィードバックしてみる体験をする取り組みの「OSS Gateワークショップ」の中で、「こんなしょうもないこと、報告していいんでしょうか……」と相談を度々受けています。商用ソフトウェアでも似たような状況らしく、多くの場合、日本語話者のユーザーはむしろフィードバックをしなさすぎ（不満があっても黙って去るだけなので、一向に製品の品質向上につながらない）なくらいのようです。 ↩

  5. 同様の現象は、「SNSで若い女性に粘着するおじさん（良識ある人はセクハラを懸念して去り、良識のない・欲望に忠実な人が残ってしまう）」や「迷惑行為を繰り返す撮り鉄（注意されてもやめない鈍感な人が残ってしまう）」など色々なジャンルで起こっているようです。 ↩

  6. むしろ、私が記憶している限りは、日本語でそういう報告が寄せられたことは無かったように思います。ただ、これは取り扱っているソフトウェアの分野によるのかもしれません。ゲームなどのコンシューマー寄りの分野では、報告のていをなしていない報告や無理筋の要望などが多く寄せられると聞いた事があります。 ↩

  7. MITライセンスであれば、3段落目の「THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.」が該当します。ただ、「使用で生じた損害への賠償責任や、寄せられる要望に応える責任は、作者には無い」とは思いますが、私は、「作者は自身の良心と見識に従って、脆弱性やバックドアの混入を防ぐなど、技術的に正しい判断をし、プロジェクトを健全な状態に保つよう努めることが望ましい」とも考えています。この記事は、その具体的な実践方法について語る物です。 ↩

  8. 実際に、有名なOSS開発プロジェクトでも開発自体はクローズドに行う方針を取っている物はあり、例えばプログラミング言語Luaの開発プロジェクトは、リポジトリもイシュートラッカーも非公開です（参考：Lua はオープンソフトウェアだが、オープン開発されたことは一度もない）。 ↩

  9. 結果を確認しないまま無反応になる報告者が結構多く、「確認が終わるまでクローズしない」という運用にすると、永遠にクローズされないissueばかりになってしまうため、このようにしています。 ↩

  10. 「未解決の問題がある」ということ自体有用な情報ですし、そこには暫定的な回避策が記載されているかもしれません。内容が本質的には重複するissueであっても、既存のissueと違う切り口で書かれた物であれば、それは「その切り口で問題を捉えて、解決策を探している人」が正しい情報に辿り着くためのヒントになる、という意義はあります。 ↩

  11. 同じ話題でも、問題の立て方を変えて「私のような属性のユーザーが使い始めようとしたときに、使い方が分からず戸惑いやすい状態になっているのは、プロジェクトの問題である。なので、プロジェクトのために解決する必要がある」としてイシュートラッカーに投稿するのは有りです。ただし、その場合には、「そのようなケースをプロジェクトとしてケアする十分な理由がある」ことを、報告者の側からエビデンスを添えて示す必要があります。 ↩

  12. もちろん、回答してくれる人が現れなければ放置状態になってしまうのですが…… ↩

  13. ビジネスの場などで「できない・やらない理由ばかり挙げるな、どうすればできるかを考えろ」といった言い方が度々なされますが、これは「プロジェクトの方針として意志決定したことについて、どうやって方針を遂行するかを考えろ」という話です。あなたがオーナーであるOSS開発プロジェクトにおいては、あなたは「決定した方針に従う人」である以前に、「方針を決定する人」でもあります。あなたはプロジェクトオーナーの特権を行使して、「やらない」という判断を下すことができる立場にいる、ということをどうか忘れないで下さい。 ↩

  14. もしかしたら、単に「こいつに言っても、言うだけ無駄だ」と諦められているだけかもしれませんが。 ↩

  15. 少なくとも、「説明はした」という言い訳はできます。 ↩

  16. 「言っても分かってもらえない」場合はもちろんありますが、「そもそも言わないと分からってもらえる可能性すらない」のも間違いないです。 ↩

  17. 特定のOSでの動作時に固有の不具合や、有料のサブスクリプション契約をしていないと使えないサービスとの組み合わせでのみ発生する不具合など。 ↩

  18. 大抵「私（報告者）には実装の知識が無いのでできない」といった言われ方をしますが、私は「アドオン開発のチュートリアルはこちらで公開されていますので、是非挑戦してみて下さい」と、開発に着手するのに必要な情報に誘導するようにしています。Firefoxのアドオンについて言えば、Firefox 56以降のWebExtensionsベースの仕組みになったことで、最初の一歩が大幅に簡単になっており、「自分でやってみて」と言いやすくなりました。なお、こうして誘導した結果として、実際にアドオン開発に取り組んでくれるようになったケースが何例かあります。 ↩

  19. もちろん、その実装が犯罪教唆になるようなケースや、直接的に誰かの権利を侵害しているようなケースは、話が別ですが。 ↩

  20. それが普及すると自社のビジネス上の利益が増すようなタイプのソフトウェア。 ↩

関連情報

現在クリアコードではソフトウェア開発者を募集しています！ フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。

クリアコードのYouTubeチャンネルです。メンバーの登壇動画や、開発プロダクトに関する動画を公開しています。