フリーソフトウェアについて人々がよくする最初の質問は、 "プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？" といったものです。 私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 実力主義、協力、そして動くコードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。 この章では、成功しているオープンソースプロジェクトに共通している、 基本的な仕組みを説明します。 "成功している" というのは、ただ技術的に質が高いだけでなく、 プロジェクトが健全に運営されており、生き残る力が強いことを言います。 新しいコードや開発者を受け入れたり、 バグレポートに素早く反応することを継続できていれば、 プロジェクトは健全に運営されているといえます。 特定の個人やスポンサーに依存しなくてもプロジェクトを続けられれば、 生き残る力が強いといえます。 —  プロジェクトを立ち上げたメンバー全員が他に移ったとしても、 プロジェクトが生き残る可能性があるかを考えてみてください。 バス係数 という用語が知られています。これは、(たとえて言うと)どれくらいの人がバスに轢かれたらプロジェクトが破綻するかを示す数です。 https://en.wikipedia.org/wiki/Bus_factor も参照してください 技術的に成功することは難しくありません。 しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、 プロジェクトが初期段階で成功して膨張したり、 カリスマ的な人がいなくなったときに、対応できないかもしれません。 オープンソースプロジェクトを成功させる方法はたくさんあります。 議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、 新しい機能を企画するなどの、 型にはまった統治の仕組みもあれば、 形になって表れないものとして、 メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、 より意識的に自制することも含まれます。 プロジェクトは、 参加する人達がよく理解している習慣や手続きに支えられて存続するという意味で、 どちらも行き着くところは同じです。 これらの方法は、中央集権的なプロジェクトより、 自発的に成長するプロジェクトで重要になります。 自発的に成長するプロジェクトでは、少なくともしばらくは、 よくないことが全体に影響することを参加する人が意識しているからです。 開発者をフリーソフトウェアプロジェクトに繋ぎ止め、 必要な時に妥協してもらうのに不可欠な要素は、 コードが 派生する ことです。つまり、 誰かがソースコードのコピーを使って、 新しい競合プロジェクトを立ち上げることです。これは フォーク という用語でも知られています。 逆説的なのは、プロジェクトが分裂する 可能性 の方が、 まれながら実際に分裂することよりも、 フリーソフトウェアプロジェクトにとって大きな力になるということです。 プロジェクトが分裂することは万人にとってよくないことなので、 (詳細な理由は、 の で述べています。) その恐れが大きくなればなるほど、 人々はそれを避けようとして妥協する可能性が大きくなります。 プロジェクトが分裂すること、いやむしろその可能性と言った方がよいでしょう。 この可能性こそが、フリーソフトウェアプロジェクトに本当の意味での独裁者が存在しない理由になっています。 これはオープンソースプロジェクトで "独裁者" とか "暴君" と呼ばれる人がいるとよく聞くことを思えば、突飛な主張かもしれません。 しかし、この手の "暴政" という言葉は特別なもので、伝統的に理解されている暴政の意味とは違うものです。 いつでも自分の王国をコピーでき、 いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。 そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振舞いをするでしょうか？ するはずがないですよね。 そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、 重要な決定をする段になると民主主義の仕組みを使います。 コードを複製できるということは、それを使って競合プロジェクトを立ち上げ、プロジェクトを分裂させられるということです。 プロジェクトが分裂させられるということは、 それを避けるために合意が形成されることを意味しています。 全員がひとりのリーダーに従うこと（もっとも有名な例が、Linux kernel 開発の Linus Torvalds です）もあるかもしれませんが、 これは 完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを 選んでいる からです。 独裁者がプロジェクトを魔法のように支配しているわけではないのです。 全てのオープンソースライセンスに当てはまる、鍵となる性質は、 コードの変更のしかたや、使用方法について、特定の集団を差別しないということです。 仮に独裁者が突然よくない決断をしはじめたとしましょう。 その場合不穏な空気が漂い、結局反乱が起きてプロジェクトが分裂してしまいます。 もちろん、そこまでひどくなることは滅多にありません。 そうなる前に独裁者のほうが譲歩するでしょうから。 しかし、 プロジェクトが分裂することがプロジェクトで権力を行使することに歯止めをかけているからといって、 プロジェクトを統率するやり方に重大な違いがあるわけではありません。 決断をするたびに、競合プロジェクトを立ち上げようと思ってる人いる？ と質問したくはないはずです。 そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。 次のふたつのセクションでは、 ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。 そこではふたつ例をあげていますが、いささか極度に理想的なものです。 多くのプロジェクトは、ふたつの状態の間のどこかに位置しているのです。 優しい独裁者(Benevolent Dictator) モデルとは、 正確には次のようなものです。 つまり、最終的な決断を行う権限が、 人格や経験が優れているという理由で、 賢明に権限を行使できるひとりの人に委ねられていることです。 "優しい独裁者" （略して BD ともいいます）という言葉は、 こうした役割に対して標準的に使われる用語ですが、 むしろ "コミュニティーが認めた調停者" もしくは "審判" と考えた方がいいでしょう。 一般的には、優しい独裁者が実際に全ての、 もしくはほとんどの決定を行っているわけではありません。 ある人がプロジェクトの全ての領域に渡って、 優れた決断を一貫して行う十分な技能があることはまれです。 そして優れた開発者は、プロジェクトの方向性に影響を与えられなければ、 結局プロジェクトから去ってしまいます。 よって、優しい独裁者は普通多く指示を出したりはしません。 むしろいつでも可能な限り、議論や実験を行う作業を開発者に任せておきます。 優しい独裁者は議論そのものには参加しますが、普通の開発者として、 自分より優れた技能を持つメンテナーの領域では、たびたび彼らに従います。 結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に 望んでいる 場合だけ、 彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。 命令することで決定するのを我慢するのは、 成功している優しい独裁者に事実上共通する特性です。 これが、彼らが優しい独裁者という役割を維持している理由のひとつなのです。 優しい独裁者になるには複数の特性が必要です。 まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、 これは言い替えれば自制を働かせるということです。 議論の最初の段階では、 自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。 人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。 もちろん、優しい独裁者であっても必ず愚かな考えを述べることがあります。 だから、自分が悪い決断を下したときに、それを認識し、 受け入れる能力も必要になるのです。— ですが、この資質は優れた開発者であれば、 特にプロジェクトに長い間留まっている人であればなおさら 誰でも 持っているはずの資質にすぎません。 しかし、優しい独裁者が違うのは、 自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、 たびたび間違いを犯す余裕があることです。 年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。 だからこそ優しい独裁者は、 技術的な面でも精神的な面でも、自分の言葉が伝える重みに敏感になって、 批判をしたり反対意見を述べるべきなのです。 優しい独裁者は、 プロジェクトにいる誰よりも技術的なスキルが優れている必要は ありません。 コードを書く能力に十分優れ、 コードに加えられたあらゆる変更を理解し、 思いやりをもってそれにコメントしなければいけませんが、それだけです。 優しい独裁者の立場は、誰かから教わって得たものではありませんし、 コードを書くスキルが恐ろしくあるという理由で得たものでもありません。 重要なのは 経験と総合的な設計センスです。— 必要に応じて優れた設計を生み出す能力ではなく、 優れた設計をソースコードから認識する能力なのです。 優しい独裁者は、プロジェクトの創始者であることが普通です。 しかし創始者であることは、優しい独裁者となる原因以上の相関関係はありません。 正確にいうと、プロジェクトをうまく始められる資質 — 技術的なスキル、 他の人をプロジェクトに参加するよう説得できること、などなど — が、優しい独裁者になるのに必要な資質です。 そしてもちろん、創始者は自動的にプロジェクトの古株としてスタートするので、 そのことで優しい独裁者への道が殆ど抵抗なしに開かれることは往々にしてあり得ます。 プロジェクトが分裂する可能性が二つあることを忘れないでください。 優しい独裁者は他の人と同様、容易にプロジェクトを分裂させられますし、 大多数の開発者が望んでいるプロジェクトの方向性が、 自分が望むものと違っていると感じたときは、 時折優しい独裁者以外の人もそうすることがあります。 コードはコピーできるので、 優しい独裁者がプロジェクトのメインサーバの root 権限（システム管理者の権限）を持っているかどうかは問題になりません。 人によっては、サーバの管理権限を持っていることがプロジェクトの最終的な権限の源であるかのように話すひとがいますが、実際は無関係です。 ある特定のサーバで開発者のコミットパスワードを追加したり、削除したりできる権限は、 そのサーバにあるプロジェクトのコピーにのみ影響します。 そうした権限に関する苦情が、優しい独裁者や他の開発者かどうかに関係なく長期間続くと、 単に開発が他のサーバに移っていくだけです。 プロジェクトに優しい独裁者がいる方がうまくいくか、 中央集権をいくらか緩めた仕組みの方がうまくいくかは、 役割を果たす人達がどれだけいるかにかかっています。 一般的なルールとして、優しい独裁者に誰がなってもいいことが明らかな場合は、 そうするとよいでしょう。しかし、誰もなり手がいないのが明らかな場合は、 次のセクションで述べる分権的な決定プロセスを使うべきでしょう。 プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、 より開かれた民主主義的なプロセスに移行します。 これは特定の優しい独裁者に必ずしも満足していないからではありません。 単にグループ主体の統治の方が、 生物学のメタファーを借りて言えば "進化的に安定している" からです。 優しい独裁者が身を引いたり、 決定する権限を多くの人に平等に与えようとするときはいつでも、 グループが新しい、独裁的でない仕組みに移行する機会になります — これは言ってみれば組織化を行うということです。 開発者のグループは最初の1、2回はこの機会を利用しませんが、 結局は利用することになります。いったんそうしてしまえば、 もとの仕組みに戻ることはありません。何故かは常識でわかることです。 仮に N人 からなるグループが、ある人に特別な権限を与えていると仮定すると、 N - 1 人が自分の影響力を弱めることに合意していることになります。 独裁的でない仕組みでは、普通特別な権限を特定の人に与えたいとは思いません。 たとえ望んだとしても、結果として行使できる権力は条件付きのものになります。 優しい独裁者を任命しても、これは明らかなことですが、 グループが後に辞めさせてしまうことができるからです。 それゆえに、プロジェクトがいったんカリスマ的な人のリーダーシップをとる仕組みから、 より型にはまったグループベースの仕組みに移行すれば、滅多に元に戻ることはないのです。 こうした仕組みがどう機能するかを詳細に見ていくと、 中身は変化に富んでいますが、共通した要素が二つあります。 ひとつは、グループはほとんどいつも合意に基づいて動くこと。 ふたつめは、合意に達しないときに投票の仕組みを使うことです。 合意 とは、皆が受け入れようと一致することです。 これはあいまいな状態ではありません。 誰かが合意に達したんじゃないかと提案し、 それに対して誰も反対を表明しない場合、あるグループは合意に達したといえます。 合意に達したんじゃないかと提案する人は、 合意とは何かということと、 仮に明らかでない場合は、 合意の結果どのような行動をとるのかを具体的に述べるべきです。 プロジェクトで交わされるほとんどの会話は技術的な話題です。 たとえば、正しくバグを直す方法とか、 ある機能を追加するか、しないか、 プログラムのインターフェイスをどの程度厳密に文書化するか、などです。 合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。 議論が終わるまでに、どの方向性をとるかについて合意がよく成立します。 通常は議論を終了するという投稿をし、 同時に何が決まるのかをまとめた上で、合意に達したよねと暗に提案します。 これが "待った！ 俺は反対だ。もう少し徹底的に話し合う必要があるね。" と言える最後の機会を与えているのです。 規模が小さく、議論に値しない事柄を決めるときは、 合意に達したという提案も暗黙に行われます。 たとえば、開発者がバグ修正を自発的にコミットした場合、 そのコミット自体が合意に達したことを提案することになります。 つまり、"このバグは直す必要があり、 この修正が正しいやり方だと皆が合意したと見做すよ" と言っているのです。 もちろん、開発者は実際にそんなことを言っていません。 彼はただ修正をコミットしただけですし、 他の開発者はわざわざ同意すると口に出して言ったりしません。 なぜなら黙っていることは合意することだからです。 コミットされた修正が、合意を得られないと判明した場合、 プロジェクトではそれがまだコミットされていないかのように議論されます。 このやり方がうまく行く理由は次のセクションで述べていきます。 プロジェクトのソースコードがバージョン管理されているということは、 ほとんどの決定が元に戻せるということを意味します。 変更を元に戻す原因としてよくあるのが、 皆にとって良いものだと間違って思い込み、変更をコミットするというものですが、 これは結局コミットした後に反対意見が出てくることになります。 こうした反対意見は決まって、 以前の議論を見逃したことを詫びることから始まりますが、 反対する人がメーリングリストのアーカイブにこれにあたる議論を見つけられなかった場合は省略されます。 どちらにせよ、変更がコミットされる前と後とで議論の口調を変える理由はありません。 少なくとも、あるコミットに依存する変更が行われた時点 （i.e. もともと加えられていた変更が突然削除され、新しい変更がそれを壊していた場合） まで、変更は取り消すことができます。 バージョン管理システムは、プロジェクトにとってよくない、 または性急な判断から生じた結果を元に戻す手段を与えているのです。 これは言い替えれば、開発者が何かをする前にどのくらいのフィードバックが必要かということを、 自分の直感を信頼して判断してよい、ということでもあります。 このことは、合意を得る手続きを型にはめる必要がないということでもあります。 ほとんどのプロジェクトはこの手続きを感覚で扱っています。 小さな変更は、議論をしないか、最小限の議論だけして、2、3の賛成があったあとに行われます。 より重要な変更、特に多くのコードを不安定にさせる変更については、 開発者達は合意に達した、 つまり単にメールを頻繁にチェックしていなかっただけの理由で重要な議論をないがしろにしたヤツはいないはずだ、 という合理的な根拠があるとみなす前に、１日か２日の間を置くべきです。 というわけで、自分がやるべきことを理解しているのなら、 単に作業を進めてやり遂げるべきです。これはソフトウェアの修正だけでなく、 ウェブサイトの更新、ドキュメントの変更、 そして議論になりそうにない他のあらゆることに当てはまります。 通常、とられたアクションを元に戻す必要がある事例は少ししかないでしょうし、 そうした事例はケースバイケースで扱えます。 もちろん、聞く耳を持たないことを奨励すべきではありません。 議論中の事項と、既に実行されて効果が表れている決定事項の間には、 いくら技術的に元に戻せるとはいっても精神的な差があります。 開発者達は勢いが行動に繋がるといつも思っていますし、 実際に行われた変更を元に戻すのは、 はじめに変更するのをやめさせるほど、気が進まないものです。 ある開発者がこの事実を悪用し、議論が必要かもしれない変更を急いでコミットする場合、 他の開発者達は文句を言えますし、言うべきです。 そして事態が好転するまで、より厳しい基準をその開発者に守らせるべきでしょう。 議論によっては、結論がでないことが必ずあります。 行き詰まった状態を打開するあらゆる手段が失敗に終わった場合、 投票が打開策になります。 投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。 ここで、普段やっている技術的な議論をしてみると、 結論を出す手続きと意外によく合っていることが再びわかるでしょう。 投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。 こういう複雑な議論では、 仲裁人 の役割を果たす人が普通ひとりかふたりはいます。 彼らは定期的にさまざまな主張をまとめたものをポストし、 反対（賛成）意見の核がどこにあるのかを追いかけています。 こうしたまとめは、議論がどの位進んでいるのかを知ったり、 どういう問題に取り組んでいるのかを覚えておくのに役立ちます。 また、実際に投票が必要になった場合に、投票用紙のひな型として役立つかもしれません。 仲裁人が仕事をうまくこなせば、 時が来れば皆に投票しましょうと呼びかけることもできるでしょうし、 プロジェクトは彼らが作ったまとめをベースにした投票用紙を使うことができるでしょう。 仲裁人自身は、議論に参加していても構いません。 つまり、対立する人の意見を理解し、中立的に表現でき、 自分の同志の気持ちが議論を中立的にまとめるのを妨げなければ、 賛成、反対の立場を超越した立場にいる必要はないのです。 投票用紙の実際の内容は、議論の余地がないものになるのが普通です。 投票が実際に行われるまでに、反対意見は２、３のキーとなる問題にまとめられ、 理解できるラベルや簡単な説明が付けられます。 開発者が投票用紙の形式そのものに反対する場合もあります。 そういう人は、たとえば重要な選択肢が抜けていたり、 選択肢に対する正確な説明がないといった、 投票が正しいものかどうかを心配していることがありますが、 投票によって出る結論が自分の望むものに絶対ならないことを多分知っていて、 投票を避けようとしているだけの場合もあります。 この手の妨害行為をどう扱うかは、 の、 を参照してください。 投票システムを必ず決めるようにしましょう。なぜなら、 投票システムにはたくさんの種類があり、どういった手続きがとられるのかについて 参加者が間違った想定をしている可能性があるからです。 ほとんどの場合に適しているのは 認定投票 です。 このシステムでは投票者が自分が好む選択肢をできるだけ多く投票できます。 認定投票は説明するのも、得票数を数えるのも簡単ですし、他の方法と異なり、 一回の投票で済みます。認定投票と他の投票システムの詳細については、 を参照してください。 しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう。 （当然、 投票システムを決めるのにどの投票システムを使うかを議論することになるからです！） 認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです。 — つまり、投票システムはできるだけ公平であるべきということです。 最後に、投票は公開の場で行いましょう。 どちらにせよ、公開の場で議論した問題について、 秘密投票にしたり、匿名投票にしたりする必要はありません。 オブザーバが投票を記録し、結果をチェックできるように、 そしてすべてをアーカイブに記録するために、 投票の参加者には、 プロジェクトのメーリングリストに自分の投票をポストさせるようにしましょう。 投票で最も難しいのは、いつ投票を行うかです。一般的には、 投票に実際に踏み切ることは滅多にすべきではありません— つまり、他のあらゆる手段が失敗したときの最後の手段にすべきです。 投票が議論を解決する素晴らしい手段だと看做さないでください。 実際、そうではないのです。投票は議論を終結させ、 それによって問題について創造的に考えることもやめさせてしまうのです。 議論が続いている限り、皆が好む新しい解決策を誰かが思い付く可能性があります。 これは驚くほどたびたび起こります。活発な議論は、 問題について新しい考え方を生み出しますし、結局皆を満足させる提案にも繋がります。 たとえ新しい提案が生まれなくても、投票を行うよりは、 妥協案を仲介してもらった方が通常はまだマシです。 妥協したあとは、皆がちょっと悲しい思いをします。 一方で、投票をしたあとは喜ぶ人がいる一方で、悲しい思いをする人もいます。 政治的な観点からは、前者の方が好ましいといえます。 なぜなら、少なくともひとりひとりが自分の悲しい思いに対して対価を支払っているからです。 満足はしないかもしれませんが、それは他の誰もが同じなのです。 投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。 しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、 頭数で問題を解決してしまいます。私は、オープンソースプロジェクトで経験を積めば積むほど、 人々が問題を投票によって解決したがらなくなるのがわかってきました。 むしろ、以前考えたこともない解決策を探ったり、 もともとの計画よりも厳しい妥協をしようとします。 早まった投票を避けるために様々なテクニックがあります。もっとも明白なやり方は、 "まだ投票を実施する段階ではないと思うよ。" といって、何故かを説明することです。 別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。 その反応が明らかに一方に偏っていたら、 正式に投票を行うのを避けるために、積極的に妥協することを人々に促すことになるでしょう。 もっとも効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組めるように、 新しい解決策や、以前の提案に基づいた新しい視点を示すことです。 まれなケースとして、示された全ての妥協案は、 妥協していない全ての案よりも劣っていることで全員が一致することがあります。 この場合、投票を実施することに反対しにくくなります。なぜなら、 投票の方がより優れた解決に繋がる可能性がありますし、 どのような結果になっても全員が過度に悲しい思いをすることはないからです。 たとえそうであっても、投票を急ぐべきではありません。 投票に至るまでの議論は有権者にいろいろなことを教えるので、 議論を早い段階でやめてしまうと、投票の結果出てくるものの質が悪くなるかもしれません。 （投票をしたがるなというアドバイスは、 の で説明している、 ソースコードに大幅な変更を加える投票には当てはまりません。 そこでは、投票は対話のメカニズムとして働き、 有権者を変更をレビューする手続きに参加させる手段となります。 それによって、 有権者は与えられた変更がどの程度のレビューを経ているのかを区別することができるのです。） 投票システムを使うとなると、有権者に関する疑問が出てきます。 誰が投票権を得るのか、という問題です。これは繊細な問題となる可能性があります。 なぜなら、どの人が熱心にプロジェクトに参加しているかとか、 どの人がよりよい判断を下せるか、 ということをプロジェクトに公式に認めさせることになるからです。 一番よいのは、既にある権限の区別、 つまりコミット権限を単純に利用し、その権限に投票権限も付加することです。 完全なコミット権限と、限定的なコミット権限を提供しているプロジェクトで、 限定的なコミット権限を持つ人に投票権を与えるかどうかは、 コミット権限を与える手続きがどのようなものかに大きく依存します。 たくさんのサードパーティーのツールをリポジトリで管理させるようなやり方で、 プロジェクトがコミット権限を気前よく配分している場合、 限定的なコミット権限が単にリポジトリにコミットする権限だけで、 投票権限はないことを明確にすべきです。 逆に考えると、同じことが当然当てはまります。 つまり、完全なコミット権限を持つ人には投票権限もあるのだから、 彼らはプログラマーとしてではなく、投票権限のあるメンバーとして選ばれなければならない。 ということになります。 メーリングリスト上で破壊的な発言をしたり、 プロジェクトを妨害する傾向がある人がいる場合は、 プロジェクトはたとえその人が技術的に優れていたとしても、 コミット権限を与える際に注意する必要があります。 完全なコミット権限にせよ、限定的なものにせよ、 新しいコミッターを選ぶには投票システムを使うべきですが、 この場合は秘密投票が適切になるまれな事例のひとつです。 コミッターになる可能性がある人について、メーリングリストで投票を行うことはできません。 なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。 代わりに普通使われるのは、 コミッターのみで構成されるプライベートなメーリングリストに、 コミット権限を与える提案をし、 それに対して既にいるコミッターが投票する方法です。 他のコミッターはそこで行われる議論がプライベートなことを知っているので、 自分の思うところを自由に述べていきます。 そこで反対意見が出ないために、投票が必要ないこともあります。 他のコミッターに反対意見を述べるチャンスを必ず与えるために２、３日待ったあと、 提案者はコミッターになる候補者にメールしてコミット権限を与えます。 反対意見があった場合は、他の問題と同じように議論が行われ、おそらく投票が行われるでしょう。 このプロセスをオープンかつ率直なものにするにせよ、 議論はとにかく非公開で行うべきです。 コミット権限を与えようと考えている人が、何が起きているのかを知っていて、 権限を貰えなかった場合、自分は投票権も失ったんだと決めつけてしまったり、 傷ついてしまう可能性もあるでしょう。 もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、 受け入れるか拒むかの回答を明示的に行うしかありません。 仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。 たとえば "開発者チームは君のパッチを気に入っているけれども、量がまだ十分でない。" とか、 "開発チームは君のパッチを全て高く評価しているけど、適用する前にかなり調整が必要なんだ。 だからコミット権限を与えるのが好ましいと思えない。 このことは時間をかけて改善して欲しいと願っている。" という感じです。 ただ、その人との信頼関係の度合によりますが、 あなたの発言が相手にショックを与える可能性があることを忘れないように。 メールを書くときは、相手の視点からメールを眺めるようにしましょう。 新しいコミッターを加えることは、 他のほとんどの一度限りの決定よりもより重大なので、 プロジェクトによっては投票に特別な要件を課すところもあります。 たとえば、その提案には 少なくとも n 票の賛成票が必須で、 反対票があってはいけないとか、圧倒的多数の賛成票が必須、といったものです。 正確な賛成票の数は重要ではありません。 中心となる考え方は、開発チームが新しいコミッターを加えるのに慎重であるべき、というものです。 コミット権限を 奪う 場合にも、投票には似たような、 あるいはもっと厳格な要件が必要です。 まぁしかし、こんなルールを必要としないのが望ましいのですが。 コミット権限を与えたり、奪ったりすることの、投票以外の側面に関する詳しい情報は、 の を参照してください。 ある種の投票では、有権者を広げた方がいいかもしれません。 たとえば、 与えられたユーザーインターフェイスがユーザーのソフトウェアの使い方と合うかどうかを、 開発者が決められない場合、 プロジェクトのメーリングリストを購読している人全員に尋ねてみるのがひとつの解になります。 これは投票というよりむしろ 世論調査 ですが、 開発者はその結果を拘束力のあるものとして扱っても構いません。 どういった調査であっても、 与えられている選択肢以外の回答を記入できることを必ず参加者に明示するようにしましょう。 調査の質問として与えられた選択肢よりも優れた回答を考えている人がいる場合、 調査の結果、その回答がもっとも重要だとわかる場合があるからです。 プロジェクトによっては、 拒否権 として知られる特別な投票権を許しています。 拒否権は性急に、または思いつきで行われた変更で、 少なくとも皆でもっと議論する時間が必要な場合に、 開発者がそれをやめさせる手段になります。 拒否権は、とても強い反対と、 議事の進行を妨害することの中間に位置すると考えるとよいでしょう。 正確な意味はプロジェクトによって異なります。 プロジェクトによっては拒否権を無効にするのがとても難しいところもありますし、 おそらくは、 もっと議論をするために強制的に時間を置いたあとで、 通常の投票権で多数の得票を得れば、 拒否権を無効にできるプロジェクトもあります。 どんな拒否権であっても、説明が一通り行われてから行使すべきです。 説明もされないのに行使された拒否権は無効なものと考えるべきでしょう。 拒否権を許すと、それが濫用されるという問題が起きます。 開発者たちは、もっと議論が必要なときに拒否権を行使することで、 リスクを増やしたくないと考えています。 あなたは、自分自身が拒否権をとても慎重に行使し、 そして拒否権を多く行使し続けている人がいる場合に、 丁寧にそれを指摘することによって拒否権の濫用を防ぐことができます。 必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、 拒否権に拘束力を持たせるよう求めることもできます — 結局は、明らかに大多数の開発者が X を望んでいる場合は、 その X が将来何かにつけ発生するでしょうから。 その場合は、拒否権を行使している開発者がそれを取り下げるか、 グループが拒否権の力を弱くする決定をすることになるでしょう。 拒否権を行使するのに "-1" と書く人を見かけるかもしれません。 この使い方は、高度に組織化された投票と拒否権システムを持つ Apache Software Foundation で生まれたものです。 これについては に説明があります。 Apache プロジェクトの基準は他のプロジェクトにも広まっているので、 オープンソース界の多くの場所で、 彼らの規約が形を変えて使われているのを見ることになるでしょう。 技術的には、Apache プロジェクトの基準に照らしても、 "-1" という表現が正式に拒否権を行使していることを必ずしも表すわけではありません。 しかし、非公式には拒否権を行使している、 もしくは少なくとも強い反対の意志を示していると普通は受け取られます。 投票と同じく、拒否権の効果は遡って適用できます。 疑問が持たれている変更が既にコミットされている、 もしくはアクションが既に起こされているという理由で、 （既にプレスリリースが出ている場合のように、 取り返しが付かないものでなければ） 拒否権に対して異を唱えるのはよくありません。 言いかえれば、何週間、何ヶ月もたったあとに拒否権が行使されても、 それが真面目に取り上げられる可能性は少ないですし、 真面目に取り上げるべきでもありません。 プロジェクトの規約や合意の数が多くなり過ぎるために、 ある時点でどこかに記録しておく必要が生じます。 記録を正統なものにするためには、 メーリングリストでの議論や既に有効になっている合意をベースにしていることを明示するようにしましょう。 実際に記録するときは、 メーリングリストのアーカイブにある関連したスレッドを参照するようにし、 不明な点があるときにはもう一度尋ねるようにしましょう。 記録した文書には人々を驚かせるようなことを書くべきではありません。 なぜなら、その文書は合意の根拠ではなく、合意の中身を説明したものに過ぎないからです。 もちろん、成功すればそれを権威あるものとして人々が引用しはじめるかもしれませんが、 それはその文書がプロジェクトの総意を正確に反映しているだけに過ぎません。 これが の で述べた文書になります。 当然、プロジェクトが若いうちは、 長く続いているプロジェクトの歴史のような、 ためになる話抜きでガイドラインを書かねばならないでしょう。 しかしプロジェクトが成長するにつれ、 明らかになってきた事柄を反映させた形で、文書を改訂することができます。 文書を包括的なものにするのはやめましょう。 どんな文書でも、プロジェクトに参加するのに必要なことを全て網羅することはできません。 プロジェクトで生まれる多くの規約は、ずっと暗黙のもので、 決して明示的に言及されることがないにもかかわらず、 メンバー全員がかたくなに守っているものなのです。 単に当り前過ぎるので言及されないものもありますし、 重要だけど曖昧なのでただ避けているだけのものもあります。 たとえば、"メーリングリストでは礼儀正しくし、他人を尊重しましょう。 また、フレームウォーを始めてはいけません。" とか、 "綺麗で、読みやすくバグのないコードを書きましょう。" といったことをガイドラインに書いても意味がありません。 もちろん、これらは望ましいことではありますが、 これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。 メーリングリスト上で失礼な発言をしたり、バグだらけのコードを書いている人がいたとして、 彼らはプロジェクトのガイドラインにやめろと書いてあるからといってやめはしないでしょう。 こういう状況は包括的なガイドラインであらかじめ対処するものではなく、 問題が起きたときに対処すべきものなのです。 一方で、あるフォーマットですべてのAPIを文書化するルールのような よいコードの書き方に関するガイドラインがプロジェクトにある場合は、 できる限り完全なものを書いておくべきです。 ガイドラインに盛りこむ内容を決めるよい方法は、初心者がよく尋ねる質問や、 経験豊富な開発者がよくこぼす不満に関する文書を基にすることです。 これは必ずしも FAQ を基にすべきというわけではありません — ガイドラインは、FAQ よりわかりやすい物語風の構造が必要になるでしょうが、 FAQ と同様、将来起こりうる問題よりも、 実際に起こった問題に取り組むという現実的な原則に従うべきです。 プロジェクトに優しい独裁者や、特別な才能に恵まれた幹部（社長とか議長とか、そういったものです）がいる場合は、 引継ぎの手続きを明文化する良い機会になります。 何らかの理由で優しい独裁者がプロジェクトから突然去る場合は、 特定の人を後継者として単に指名すればいいだけの場合もあります。 一般的には、優しい独裁者がいる場合、彼だけが後継者を指名することができます。 投票で選ばれた幹部がいる場合は、彼らを選ぶのに候補者を選び、 投票する手続きを踏む手続きがはじめに行われたことを文書に記録すべきです。 そうした手続きがもともとなかった場合は、文書に手続きを明文化する 前に メーリングリスト上で手続きに関する合意を得るようにします。 階層的な支配構造に神経質な態度をとる人もいるので、こうした話題を扱うときは気を使う必要があります。 こうしたルールは見直すことができる、というのを明示しておくことが多分一番重要です。 たとえ文書に記録された規約がプロジェクトを妨害しはじめたとしても、 その文書が開発者グループの意図を強く反映したもので、 プロジェクトへの不満や障害の源ではない、ということを周知しておきましょう。 規約が自分の邪魔をするたびに見直しを求める人がいる場合は、 その人と議論する必要は必ずしもありません。— 無視しておくことが最良の選択となることもあります。 規約に不満があることで一致している人が他にいるなら、彼らが同調するでしょう。 それは何かを見直すべきことをあらわしています。 誰も同調しなければ、見直しを求める人に返答する人はいなくなるでしょう。 そして規約は以前の状態のまま残るのです。 開発者向けガイドラインの良い例がふたつあります。 ひとつは にある、Subversion Cummunity Guide です。 もうひとつは、 と にある、Apache Software Foundation の統治に関する文書です。 Apache Software Foundation は実際はソフトウェアプロジェクトの集合体ですが、 非営利組織として合法的に組織されています。 よって彼らの文書には、開発する際の規約よりも、 プロジェクトを統治する際の手続きについて多く記述されています。 ですが、まだ読む価値は大いにあります。 なぜなら、それはたくさんのオープンソースプロジェクトの経験を集積した文書だからです。 24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details. poss2 tbd Mention Software Freedom Conservancy, SPI, ASF, GNOME, any others. Note "non-profit" vs "not-for-profit". Mention Kuali et al as models. Problems of consortiums. Don't assume the U.S. tax code benefit is familiar everywhere. Emphasize clear separation between the legal infrastructure and the day-to-day running of the project: the organization is there to take care of the things the developers don't want to deal with, not to interfere with the things the developers already know how to do. Explain fiscal sponsorship when talking about fundraising. Note trademark ownership as well as copyright ownership, and link to this section as appropriate from the licensing/copyrights chapter and from the money / corporate involvement chapter.