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