合意と投票で構築されるOSS開発の社会構造：オープンソースソフトウェアの育て方（3/4 ページ）

[Karl Fogel， ]

誰が投票するのか？

　投票システムを使うとなると、有権者に関する疑問が出てきます。誰が投票権を得るのか、という問題です。これは繊細な問題となる可能性があります。なぜなら、どの人が熱心にプロジェクトに参加しているかとか、どの人がよりよい判断を下せるか、ということをプロジェクトに公式に認めさせることになるからです。

　一番よいのは、既にある権限の区別、つまりコミット権限を単純に利用し、その権限に投票権限も付加することです。完全なコミット権限と、限定的なコミット権限を提供しているプロジェクトで、限定的なコミット権限を持つ人に投票権を与えるかどうかは、コミット権限を与える手続きがどのようなものかに大きく依存します。

　たくさんのサードパーティーのツールをリポジトリで管理させるようなやり方で、プロジェクトがコミット権限を気前よく配分している場合、限定的なコミット権限が単にリポジトリにコミットする権限だけで、投票権限はないことを明確にすべきです。逆に考えると、同じことが当然当てはまります。つまり、完全なコミット権限を持つ人には投票権限もあるのだから、彼らはプログラマーとしてではなく、投票権限のあるメンバーとして選ばれなければならない。ということになります。メーリングリスト上で破壊的な発言をしたり、プロジェクトを妨害する傾向がある人がいる場合は、プロジェクトはたとえその人が技術的に優れていたとしても、コミット権限を与える際に注意する必要があります。

　完全なコミット権限にせよ、限定的なものにせよ、新しいコミッターを選ぶには投票システムを使うべきですが、この場合は秘密投票が適切になるまれな事例の1つです。コミッターになる可能性がある人について、メーリングリストで投票を行うことはできません。なぜなら、候補者の感情（評判）を傷つけてしまう可能性があるからです。

　代わりに普通使われるのは、コミッターのみで構成されるプライベートなメーリングリストに、コミット権限を与える提案をし、それに対して既にいるコミッターが投票する方法です。ほかのコミッターはそこで行われる議論がプライベートなことを知っているので、自分の思うところを自由に述べていきます。そこで反対意見が出ないために、投票が必要ないこともあります。

　ほかのコミッターに反対意見を述べるチャンスを必ず与えるために2、3日待った後、提案者はコミッターになる候補者にメールしてコミット権限を与えます。反対意見があった場合は、ほかの問題と同じように議論が行われ、恐らく投票が行われるでしょう。このプロセスをオープンかつ率直なものにするにせよ、議論はとにかく非公開で行うべきです。コミット権限を与えようと考えている人が、何が起きているのかを知っていて、権限をもらえなかった場合、自分は投票権も失ったんだと決めつけてしまったり、傷ついてしまう可能性もあるでしょう。もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、受け入れるか拒むかの回答を明示的に行うしかありません。

　仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。例えば「開発者チームは君のパッチを気に入っているけれども、量がまだ十分でない」とか、「開発チームは君のパッチをすべて高く評価しているけど、適用する前にかなり調整が必要なんだ。だからコミット権限を与えるのが好ましいと思えない。このことは時間を掛けて改善してほしいと願っている」という感じです。ただ、その人との信頼関係の度合によりますが、あなたの発言が相手にショックを与える可能性があることを忘れないように。メールを書くときは、相手の視点からメールを眺めるようにしましょう。

　新しいコミッターを加えることは、ほかのほとんどの一度限りの決定よりもより重大なので、プロジェクトによっては投票に特別な要件を課すところもあります。例えば、その提案には少なくともn票の賛成票が必須で、反対票があってはいけないとか、圧倒的多数の賛成票が必須、といったものです。正確な賛成票の数は重要ではありません。中心となる考え方は、開発チームが新しいコミッターを加えるのに慎重であるべき、というものです。コミット権限を奪う場合にも、投票には似たような、あるいはもっと厳格な要件が必要です。まぁしかし、こんなルールを必要としないのが望ましいのですが。コミット権限を与えたり、奪ったりすることの、投票以外の側面に関する詳しい情報は、章8.ボランティアの管理のコミッター項を参照してください。

世論調査vs投票

　ある種の投票では、有権者を広げた方がいいかもしれません。例えば、与えられたユーザーインタフェースがユーザーのソフトウェアの使い方と合うかどうかを、開発者が決められない場合、プロジェクトのメーリングリストを購読している人全員に尋ねてみるのが1つの解になります。これは投票というよりむしろ世論調査ですが、開発者はその結果を拘束力のあるものとして扱っても構いません。どういった調査であっても、与えられている選択肢以外の回答を記入できることを必ず参加者に明示するようにしましょう。調査の質問として与えられた選択肢よりも優れた回答を考えている人がいる場合、調査の結果、その回答が最も重要だと分かる場合があるからです。

拒否権

　プロジェクトによっては、拒否権として知られる特別な投票権を許しています。拒否権は性急に、または思いつきで行われた変更で、少なくとも皆でもっと議論する時間が必要な場合に、開発者がそれをやめさせる手段になります。拒否権は、とても強い反対と、議事の進行を妨害することの中間に位置すると考えるとよいでしょう。正確な意味はプロジェクトによって異なります。プロジェクトによっては拒否権を無効にするのがとても難しいところもありますし、おそらくは、もっと議論をするために強制的に時間を置いた後で、通常の投票権で多数の得票を得れば、拒否権を無効にできるプロジェクトもあります。どんな拒否権であっても、説明が一通り行われてから行使すべきです。説明もされないのに行使された拒否権は無効なものと考えるべきでしょう。

　拒否権を許すと、それが濫用されるという問題が起きます。開発者たちは、もっと議論が必要なときに拒否権を行使することで、リスクを増やしたくないと考えています。あなたは、自分自身が拒否権をとても慎重に行使し、そして拒否権を多く行使し続けている人がいる場合に、丁寧にそれを指摘することで拒否権の濫用を防ぐことができます。必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、拒否権に拘束力を持たせるよう求めることもできます――結局は、明らかに大多数の開発者がXを望んでいる場合は、そのXが将来何かにつけ発生するでしょうから。その場合は、拒否権を行使している開発者がそれを取り下げるか、グループが拒否権の力を弱くする決定をすることになるでしょう。

　拒否権を行使するのに「-1」と書く人を見かけるかもしれません。この使い方は、高度に組織化された投票と拒否権システムを持つApache Software Foundationで生まれたものです。これについては「Consensus Gauging through Voting」に説明があります。Apacheプロジェクトの基準はほかのプロジェクトにも広まっているので、オープンソース界の多くの場所で、彼らの規約が形を変えて使われているのを見ることになるでしょう。

　技術的には、Apacheプロジェクトの基準に照らしても、「-1」という表現が正式に拒否権を行使していることを必ずしも表すわけではありません。しかし、非公式には拒否権を行使している、もしくは少なくとも強い反対の意思を示していると普通は受け取られます。

　投票と同じく、拒否権の効果は遡って適用できます。疑問が持たれている変更が既にコミットされている、もしくはアクションが既に起こされているという理由で、（既にプレスリリースが出ている場合のように、取り返しがつかないものでなければ）拒否権に対して異を唱えるのはよくありません。言いかえれば、何週間、何カ月もたった後に拒否権が行使されても、それが真面目に取り上げられる可能性は少ないですし、真面目に取り上げるべきでもありません。