4章プロジェクトの政治構造と社会構造 の 「プロジェクトが分裂する可能性」 では、 プロジェクトが分裂する 可能性 がプロジェクトの管理体制に重大な影響を及ぼすことを取り上げました。 しかし、実際に分裂した場合はどうなるのでしょう? どうやって処理するのでしょうか? それがどんな影響を及ぼすのでしょうか? 逆に、あなたのほうがそうしなければならないことはあるでしょうか?
その答えは、状況によって変わります。 プロジェクトの進む道に関して相容れない意見の相違が出てきたために 友好的にプロジェクトが分かれることもありますが、 おそらくそれよりもっと多いのは 技術的な意見の相違や人間関係の問題によって プロジェクトが分裂することでしょう。 もちろん、これらを明確に区別できるとは限りません。 技術的な議論は往々にして個人的な議論の要素も含んでいるからです。 共通しているのは、ある開発者グループ (あるいはひとりの開発者だけのこともあります) にとってその他のメンバーとの共同作業のコストに見合う利益が 得られないと判断したということです。
プロジェクトが分裂したときの、どちらが「本家」だとかどちらが「元祖」 だとかいう問いへの明確な答えはありません。「プロジェクト P から分裂した F」というように、あたかも P は何も変わらないままで F がそこから新たに分岐したと話す人もいます。 しかし、実際のところこれは「その人がどのように感じているか」 を言っているにすぎません。 これは基本的に認知度の問題です。周囲の大多数が同意すれば、 その主張が真実だということになります。 客観的にみた真実が最初からあるというわけではありません。 不十分ながらも「なんとなくこうじゃないかな」と考えることしかできません。 そして、まわりの認知度こそがむしろ客観的な真実と言えます。 結局のところ本家 (あるいは分家) の区別 というものは人の心の中にのみ存在するものだからです。
もしプロジェクトを分裂させようと考えた人が メインプロジェクトから離れて新たなブランチを立ち上げたのなら、 認知度に関する問題はすぐに解決するでしょう。 開発者もユーザーも、 新たに登場した競合プロジェクトが新しいプロジェクトであることを認め、 新しい名前 (元の名前に由来するものかもしれませんが、 容易に区別できるもの) や新しいウェブサイト、 新しい目標を持つものであることを認めることでしょう。 しかし、両方の陣営が「自分のほうこそがこのプロジェクトの本流であり、 名前を使い続ける権利がある」と考えている場合は話がややこしくなります。 もしそのプロジェクト名の商標権やドメイン、ウェブページなどを 何らかの組織で管理している場合は、通常はその組織の考えで問題を解決されます。 どちらが本家でどちらが分家なのかをその組織が決めることになるわけです。 というのも、広報合戦になればその組織にはかないっこないからです。 当然、そんな事態になることはめったにありません。 力関係についてはみんなよくわかっており、 結果のわかっているケンカなどしないでしょうから。
幸いなことに、たいていの場合は「どっちが本流でどっちが傍流か」 といった争いは起こりません。というのも、 実際に分裂してしまうかどうかは、 その動きに対する信任投票のような力学で決まるからです。 もし開発者の過半数がプロジェクトを分裂させる動きに賛同したのなら、 通常はもはやそうする必要はありません。 強情な独裁者がプロジェクトを仕切っているのでもない限り、 わざわざ分裂させなくてもそのプロジェクトの中で動きを進めていけばいいのです。 一方、もし分裂させようと考えているのが全体の半数より少ないのなら、 それは明らかに少数派の反乱です。礼儀的な意味でも、 また常識で考えても彼らが本流となることはないでしょう。 本流から分岐した別のものと考えるべきです。
プロジェクト内で誰かが新しい競合プロジェクトを立ち上げる動きを見せ始めたら、 まずは落ち着いてあなたの長期目標を思い出しましょう。 分裂すること自体はプロジェクトにとって害ではありません。 むしろそれによって開発者やユーザーを失うことが問題なのです。 つまり、あなたのやるべきことはそうした動きの芽を摘むことではなく その被害を最小限に抑えることなのです。 腹が立つかもしれません。 そんな動きは不当なものであり、 また不要なものであると感じるかもしれません。 でも、そんな感情を表に出したところで、 態度を決めかねている開発者をあなたから遠ざけることにしかなりません。 開発者たちに、態度を明確にするよう要求してはいけません。 そして、新しくプロジェクトを立ち上げる人たちともできるだけ協力的に接するようにしましょう。 まず第一に、誰かが新しいプロジェクト側で作業をすることになったからといって、 その人のコミット権を剥奪するようなことはやめましょう。 新しいプロジェクトの側で作業をすることになったからといって、 元のプロジェクトにおけるその人の権限が即刻失われるというわけではありません。 これまでコミッターであった人は、これからもコミッターであり続けるべきです。 さらに、新しいプロジェクト側とはできるだけ仲良くやっていきたいという意志を示すことも大切です。 必要に応じて、お互いのプロジェクトの変更内容を相手側にも反映させられるような関係を保ちましょう。 もしあなたがプロジェクトのサーバの管理権限を持っているのなら、 プロジェクトを始めるにあたってのインフラの支援を提案しましょう。 たとえば、そのプロジェクトの過去のバージョン管理リポジトリのデータのコピーを提供すれば、 彼らが過去のデータを使えるようになります (使用するバージョン管理システムによっては、 わざわざそうしなくても過去のデータを利用できるものもあります)。 何か必要なものがないかどうかを彼らに聞き、 可能な限り支援するようにしましょう。 あなたが邪魔をするつもりがないこと、 そして (他の要因ではなく) あくまでも実力次第で新しいプロジェクトの成功か失敗が決まるような状態にすることを態度で示すことが大切です。
これらすべてを (公式に) 行う理由は、 新しくプロジェクトを立ち上げる人たちを助けるためではありません。 「こっち側にいたほうが何かと安全ですよ」 ということを、できるだけ押しつけがましくない方法で開発者たちに伝えるためです。 戦争においては、どちらの陣営に属するのかを明確にさせることにはそれなりの意味もあります (戦略的な意味、あるいは人間的な意味において)。 しかし、フリーソフトウェアの世界においてはこれはまったく無意味です。 実際、プロジェクトを立ち上げた後でも両方のプロジェクトでおおっぴらに活動する開発者も中にはいます。 両者の互換性を保つために力を注いでいたりするわけです。 彼らのおかげで、分裂した後でも両方のプロジェクトの間の交流ができるようになります。 彼らは、新しいプロジェクトの側で追加したすてきな新機能をあなたのプロジェクトにもたらしてくれるかもしれません (そう、あなたの望むものをあちら側で作っている可能性もあるでしょう)。 そして、将来ふたたび両者が合流するという望みも残してくれます。
時には新しいプロジェクトのほうが大成功を収めることもあります。 最初に分裂させた当事者でさえ自分たちのほうが分家だと認めているにもかかわらず、 みんながそちらのバージョンのほうをずっと好むようになり、 結局本家に取って代わるようになるといったものです。 有名なのは GCC/EGCS の例です。 GNU Compiler Collection (GCC、これは以前は GNU C Compiler という名前でした) は、オープンソースのネイティブコードコンパイラとしてもっともよく知られているもので、 またもっとも多くの環境に移植されているコンパイラでもあります。 GCC の公式メンテナーと Cygnus Software [36] との間の意見の相違が原因で、GCC のもっとも活発な開発者グループのひとつであった Cygnus は GCC を離れて EGCS という新しいプロジェクトを立ち上げました。 EGCS 側は、意図的にオリジナルと敵対することを避けました。 EGCS の開発者は、決して自分たちのバージョンを公式な GCC にしようとは思わなかったのです。 そうではなく、EGCS をよりよいものにすることだけに注力し、 パッチを受け入れる頻度も公式の GCC メンテナーより多くしました。 EGCS の人気は増し、大手の OS ディストリビュータの中にも デフォルトのコンパイラとして GCC ではなく EGCS を採用するところが出てきました。 ここにきて、さすがに "GCC" の名前を持っている本家 GCC のメンテナーたちもわかってきました。 みんなが EGCS に移行するときにわざわざ名前を変更しなければならないのは面倒だということ、 そしてもはや GCC の名前を引き渡さざるをえないということを。 そこで、GCC は EGCS のコードを受け入れることにしました。 GCC は再び統一されたのです。 オリジナルから分かれて、新たにプロジェクトを立ち上げたおかげで、 中身はとても改良されたものになっています。
この例ひとつとっても、 プロジェクトの分裂を単純に悪とみなすべきではないことがよくわかります。 実際に起こったときは苦痛を感じてあまり歓迎されないかもしれませんが、 それが成功するかどうかなんてそのときには知ることはできません。 したがって、あなたを含むプロジェクトのメンバーができることといえば、 彼らを見守り続けて新機能やコードを取り込めるように準備しておくことくらいです。 もしそのほうがプロジェクト全体の利益になると皆が同意したら、 究極の選択として彼らに合流することも考えるべきでしょう。 もちろん、それ加わるメンバーをみれば それが成功するか失敗するかをある程度予測できることも多いでしょう。 たとえば、プロジェクト内で文句ばかり言っていた人が 一握りの不満分子 (彼らもプロジェクト内では建設的な振る舞いをしていませんでした) を引き連れて新たな競合プロジェクトを立ち上げたとしましょう。 こんな場合は、むしろそうしてくれたほうがありがたかったでしょうね。 彼らが本家に取って代わることを心配する必要もないでしょう。 しかし、もし皆に尊敬されている実力者が新しいプロジェクトに参加しているというのなら、 なぜそんなことになったのか自分に問い返してみましょう。 おそらく、あなたのプロジェクトには制約が多すぎ、 やりたいことの一部 (あるいはすべて) を実現するにはプロジェクトのコピーを使って競合プロジェクトを立ち上げるしかなかったのでしょう。 要するに、自らが行動することで他の分裂の動きを避けるということです。
ここでのアドバイスは、最後の手段としてオリジナルのコピーを使い、 競合プロジェクトを立ち上げざるを得なくなった人たちに向けたものです。 立ち上げを始める前に、まず他の可能性を徹底的に試すようにしましょう。 実際に競合プロジェクトを立ち上げると、 ほとんどの場合は開発者を失うことになります。 仮に後で新しい開発者が増えるとしても、そうなる確証はありません。 また、競合プロジェクトを立ち上げるということは、 ユーザーの気を引くための競争が始まるということを意味します。 そのソフトウェアをダウンロードしようとした人たちはみんな悩むことでしょう。 "で、いったい私はどっちをダウンロードすりゃいいの?" あなたがどちらのプロジェクトにいたとしても、状況は混沌としています。 そんな質問は、プロジェクトが分裂する前には出なかったわけですから。 中には、プロジェクトが分裂することはソフトウェアの生態系上ごく自然なことだという人もいます。 自然淘汰の結果、一番環境に適合したものが生き残る。 つまり、結局はみんながよりよいソフトウェアを使えるようになるというわけです。 生態系という意味ではそれが真実かもしれませんが、 個々のプロジェクトにおいては決して真実であるとはいえません。 プロジェクトが分裂しても、 新たに立ち上がったプロジェクトが成功することはほとんどありません。 また、ほとんどのプロジェクトは分裂してもよい結果を生みません。
結論としては、議論のネタとしてプロジェクトが分裂することを持ち出してはいけないということです。 —"俺の言うとおりにしてくれなきゃプロジェクトが分裂しちゃうよ!"— といった具合に。 なぜなら、みんな知っているからです。 プロジェクトを分裂させたとしても、 開発者の興味をひくことができなかったら、 新しい競合プロジェクトの行く末は長くないことが多いということを。 すべての関係者 (開発者だけではなくユーザーや各 OS 向けのパッケージ作成担当者なども) がどちら側を選ぶのかの判断を迫られることになります。 したがって、あくまでもそれ以外のやり方がないことが確実に主張できる状況にならない限り プロジェクトを分裂させるのは避けるようにしましょう。
プロジェクトを分裂させることで生まれる、 新しいプロジェクトが成功するかどうかの可能性を評価するにあたっては、 すべての 要素を考慮にいれることを忘れないようにしましょう。 たとえば、 プロジェクトの開発者の多くが同じ雇い主のもとで働いているとしましょう。 たとえ彼らが不満を抱いて個人的に新しいプロジェクトの立ち上げを考えたとしても、 雇い主がそれに反対していると知れば 声を大にしてそれを言うことはないでしょう。 フリーソフトウェアプログラマーの多くは、 コードにフリーなライセンスが適用されていたら 特定の企業に開発が左右されることはないと考えがちです。 究極の意味では、ライセンスが自由を保証しているというのは事実です。 だれかが本当に元のプロジェクトから分かれて、 新しい競合プロジェクトの立ち上げを望み それだけのリソースがあるのなら、できないことはないでしょう。 しかし実際のところは、いくつかのプロジェクトの開発チームは ほぼ特定の団体が資金源になっていることが多く、 それを隠そうとしても無意味です。 その団体がそうした動きに反対しているようなら、 たとえ開発者が参加する気があったとしても 実際には参加することがないでしょう。
それでもまだ「今のプロジェクトから分かれて、 新しいプロジェクトを立ち上げる以外ない」と思っているなら、 まずは個人的に賛同してくれる仲間を集めましょう。 それから、そうすることを (けんか腰ではなく) おだやかに宣言します。 たとえ現在のメンテナーにたいして怒りや失望の気持ちがあったとしても、 それを実際に言ってはいけません。 あなたが決心したきっかけは何なのかということ、 そして現在のプロジェクトに対して悪意はまったくないということを冷静に説明します。 プロジェクトを分裂させるつもり (元のプロジェクトを緊急待避させるのではなく) であるなら、あくまでもコードを派生させるのであってオリジナルと同じ名前を使うのではないということを強調し、 元のプロジェクトの名前と衝突することのない名前を選びます。 元のプロジェクトときちんと区別できるような名前であれば、 その一部に元のプロジェクトの名前を含めることもできます。 もちろん、新しいプロジェクトのホームページで 「これは元のプログラムから分離したものであり、元のプログラムを置き換えることを目指している」 と説明するのはかまいません。 区別しにくいような状況にユーザーを陥れてしまうことは避けましょう。
最後に、よいスタートを切るためのひとつの方法として、 元のプロジェクトのコミッター全員に対して (たとえ明示的に新しいプロジェクト立ち上げに反対していたとしても) 新しいプロジェクトのコミット権を与えてしまうというものもあります。 たとえ彼らがそのアクセス権を一切使用しなかったとしても、 あなたからの 「意見の不一致はあったけれども、敵になったというわけではない。 よいコードならどなたからのものでも歓迎します」というメッセージは伝わります。