# 分叉 在[Chapter?4, *社會和政治的基礎架構*](# "Chapter?4.?社會和政治的基礎架構")的[the section called “分叉能力（forkability）”](# "分叉能力（forkability）")，我們說了*潛在的*分叉能力對于項目管理的重要影響。但是當分叉確實發生時，我們應該怎么做？你應該如何處理，會發生怎樣的情況？與之對應，何時你應當*開始*一個分叉。 答案取決于你選擇的分叉類型。有一些分叉源于對于項目方向的友善但不可調和的異議；也有一些由于技術分歧和個人沖突。當然，很難說清楚二者之間的區別，因為技術爭論也會包含個人元素。所有分叉的共同之處是有一隊開發者（有時僅僅是一個開發者）認為與某些人或所有其他人一起工作的成本已經大于收益。 一旦項目分叉，對于分叉與“原”項目誰是誰非，沒有明確的答案。人們會通俗的說分叉F來自于項目P，好像P繼續沿著自然路徑保持不變，而F則進入新的領域，但這實際上是一個觀察者的聲明。但這純屬個人感覺：當足夠高百分比的觀察者認可，這個斷言便成為真。并不是說一開始就有一個客觀事實，而只是一開始的一個不太完美的感覺。此外，感覺*是*客觀事實，因為最終一個項目—或一個分叉—僅僅是存在于人們思想中的一個實體。 如果開始分叉的人們感覺自己是在建立主項目的一個分支，則感知問題可以立刻輕易的解決。每個人，開發者和用戶會將分叉視為新的項目，有新的名稱（或許基于舊有的名稱，但容易與之區分），一個單獨的網頁以及單獨的哲學或目標。當雙方都認為自己是原項目遺產的守衛者，理所當然繼續使用原來的名稱時，事情會變的復雜。如果某個組織擁有這個名稱的商標權，或對于域名或網頁有法律控制，通常可以平滑的解決這個問題：這個組織可以決定誰是這個項目，誰是分叉，因為它擁有公共關系戰爭中的所有卡片。很自然，一般不會如此過分：因為每個人都知道權利動力學，他們會避免一場結局已定的戰斗，會直接跳到結局。 幸運的是，大多數情況下可以輕松的區分哪個是項目，哪個是分叉，因為分叉從本質上是一個自信的投票。如果過半的開發者傾向于采納分叉的過程，通常意味著沒有必要分叉—這個項目可以自己走這條路，除非它有一個頑固的獨裁者，按照獨裁方式運行。另一方面，如果支持者少于一半，則分叉則明顯是少數派的反叛，根據禮貌和常識，它應當認為自己是分叉，而不是主線。 ### 處理分叉 如果某人在項目中威脅進行分叉，請保持冷靜并牢記你的長期目標。分叉的*存在*不是對項目的傷害，而是開發者和用戶的損失。你真正的目標，不是為了鎮壓分叉，而是最小化其損害。也許你會生氣，你或許感到分叉是不公正和不請自來的，但如果這樣公開表示則是對未決定用戶的疏遠。相反，不要強制人們做出唯一的選擇，要與分叉實行可行的合作。首先，不要因為某人決定在分叉上工作，而刪除其在你的項目中的提交權限。在分叉上工作并不意味著他立刻失去了在原項目工作的資格；之前的提交者之后還是提交者。此外，你應當展示與分叉保持兼容的愿望，并表達你希望開發者能夠在二者之間搬運合適的變更。如果你對項目服務器有管理權限，一開始就公開提供分叉的基礎架構幫助。例如，如果他們無法通過其他方法獲得，可以為他們提供一個完整的，版本控制庫的深度歷史副本，這樣他們就不必以無歷史數據作為開始（必要性取決于版本控制系統）。詢問他們是否有其他的需要，并盡你所能提供。這種支持表明了你不會阻撓他們，而且希望該分叉以自己價值成功或者失敗，僅此而已。 這樣做—以及公開這樣做的—原因實際上并不會幫助分叉，但是通過盡可能的展示非報復心態，會使開發者相信你這邊是安全帶。戰爭中有時強制人們選擇一邊非常有意義（戰略意義，而不是人的感覺），但是自由軟件幾乎從不這樣做。實際上，分叉后一些開發者會公開的在兩個項目同時工作，并盡可能保持二者兼容。這些開發者保持了分叉之后的交流。他們允許您的項目從分叉中有趣的新特征中獲益（是的，分支也有你想要的），另外也會增長在未來合并的可能。 有時，某個分支變得異常成功，即使他最初的煽動者也認為他們開始于一次分叉，但成為人人都喜歡的版本，最終由于其流行性取代了最初的版本。一個著名的實例是GCC/EGCS分叉，*GNU Compiler Collection*（*GCC*，以前稱為*GNU CCompiler*）是最著名的開源本代碼編譯器，也是世界上最便于移植的編譯器。源于對GCC官方維護者和Cygnus軟件的分歧。[[29](#)]GCC的一個最活躍的開發團隊，Cygnus創建了一個GCC的分叉，稱為*EGCS*。該分叉謹慎保持非敵對位置：從任何角度看，EGCS開發者從沒有試圖把他們版本的GCC描繪成新的官方版本。相反，他們集中精力使EGCS盡可能的好，比官方的GCC維護者以更快的頻率整合補丁。EGCS受到了歡迎，最終一些主流的操作系統發布商決定將EGCS而不是GCC作為打包產品的默認編譯器。此刻，對于GCC的維護者很清楚，堅持“GCC”的名稱，而讓所有人切換到EGCS分叉上需要每個人承受毫無必要的名稱修改負擔，對防止切換毫無意義。所以GCC采用了EGCS的代碼基，再一次只有一個GCC，但因為分叉獲得了極大的改進。 這個例子向我們展示了為什么不能單純的將分叉視為一件壞事。分叉時可能充滿痛苦和不受歡迎，但你不能必然知道它是否會成功。因而，你和項目的余下部分要一直留意它，不僅僅要準備好吸收可能的特性和代碼，在極端情況下，如果分叉獲得了項目的精神占有率，甚至需要加入分叉。當然，通過觀察誰加入了分叉你也能預測到其成功的可能性。如果分叉由項目最大的抱怨者開啟，并有少數不滿的看起來起不到建設作用的開發者加入，他們將無法通過分叉解決問題，你也無須擔心分叉會將原項目的動力帶走。但是如果你看到有影響和令人尊敬的開發者支持這個分叉，你必須問自己這是為什么。或許整個項目被限制了，最好的方案是在主線項目采納一些分叉打算的行動—從本質上，通過變成它而避免分叉。 ### 初始一個分叉 這里的所有建議假設你將分叉作為最后的依靠。初始分叉前耗盡了所有的可能性。分叉總是意味著丟失開發者，只留下一個不確定的在以后獲得新產品的承諾。它也意味著開始了對用戶注意力的競賽：每個下載這個軟件的人都會問自己：“哦，這個還是那個？ ” 無論你是哪個，情況也是骯臟的，因為出現了原本不存在的問題。一些維護分叉的人們會維護軟件的整體生態系統的健康，通過標準的自然選擇論點：適者生存，意味著最終每個人得到更好的軟件。從生態學的角度這或許是正確的，但對于單個項目來說則并不正確。大多數分叉并不成功，大多數項目不喜歡被分叉。 一個推論就是不要使用分叉的威脅作為極端的辯論技巧—“按照我的方式，否則我要將項目分叉！ ”—因為每個人都會意識到如果是無法吸引開發者離開原項目的分叉，不太可能長久存活。所有的觀察者—不僅是開發者，還有用戶和操作系統打包者—會對選擇哪一方做出自己的判斷。你不必表現出極端不情愿分叉，這樣如果你最終這樣做了，你可以光榮的宣布這是最后一條路。 在評估你的分叉成功可能性時，不要忽視*所有的*因素。例如，如果項目的許多開發者都有同一個雇主，那么即使他們不滿且私下里傾向于分叉，也不太會大聲說出他們的雇主是贊成還是反對。許多自由軟件程序員以為如果代碼有自由許可證，那么沒有哪個公司可以控制開發。許可證確實如此，是一種終極意識，自由的保障—如果其他人強烈的希望分叉項目，并有足夠的資源，它可以這樣做。但是在實踐中，一些項目開發團隊大多由一個實體資助，沒有證據說明這些實體的支持無關緊要。如果他們反對分叉，他們的開發者不會離開，即使私下里希望如此。 如果你還是確認必須分叉，最好首先私下聯絡好支持，然后使用不含敵意的語調宣布分叉。即使你對當前的維護者感到憤怒，或者失望，不要在這些信息中寫出來。只需要不露聲色的陳述導致你決定分叉的動機，以及你對所分叉原項目并無敵意。假定你考慮一次分叉（相對于對原項目的緊急保存），強調你分叉的是代碼而不是名稱，并選擇一個與原項目不會沖突的名稱。你可以使用一個包含或引用原名稱的名稱，只要不會造成識別上的混淆。當然，在分叉的主頁上也可以突出解釋其來自的原始程序，甚至對于替代它的期望。但是不要迫使用戶解開識別爭議，給他們帶來額外的麻煩。 最終，通過為原項目的所有提交者，包括那些公開反對分叉的提交者賦予提交權限，就可以自動讓事情開始運轉。即使他們不會訪問，但你的信息是明確的：這里存在爭議，但是沒有敵人，你歡迎來自所有競爭源的代碼貢獻。 [[29](#)] 現在是RedHat（[http://www.redhat.com/](http://www.redhat.com/)）的一部分。