[[392851]]

初次參與開源代碼項目時，我們首先需要確定項目的眾多參與者中有哪些人有權協助做出貢獻。而這種在開源軟件項目中定義誰能做什么、應該怎么做的規則與慣例，就被稱為項目的治理模型。只有了解這些規則與慣例，才能幫助大家順暢對接項目運作、成功做出自己的貢獻。

每個開源項目與社區都根據治理模型保持運行，但不同項目之間的治理模型仍有高下之分。本文將向大家介紹一些最常見的開源項目與社區治理模型，并為采用各種模型的項目提供入門性指導。

“專制政體”模式

采取“專制政體”治理模式的開源項目，往往不會發布正式且詳盡的治理公約，而是將絕大部分決策權集中在特定人員手中。換句話說，專制項目的成員需要通過穩定且一致的貢獻幫助自己贏得權威地位。在這種模式下，同行評議工作仍然普遍存在，但個人貢獻者更傾向于保留項目中特定組成部分，通常是其接觸最多部分的客觀決策權。

因此，有些專政項目會強調自己根本沒有治理模式，而是依靠各利益相關者結合自身權限做出決定。但這種“無需治理”的思維明顯是錯的，任何開源項目都必然擁有自己的一套治理模型。多數情況下，這種治理模型隱含在項目成員的日常交互當中。結果就是，老成員可能把新生力量視為潛在威脅，新人則發現自己難以融入，甚至不知道該怎么立即參與、或者如何為貢獻內容申請核準。

要在項目中建立治理模型，第一步就是設定一個存在改進空間的特定點位。我們可以回顧項目的變更歷史記錄，借此確定如何讓自己的貢獻成果贏得老成員們的青睞。隨著貢獻接納量的增加，大家將逐漸在社區中累積起影響力。

“創始人/領導者”模式

“創始人/領導者”治理模型在新項目、或者貢獻者較少的項目中最為常見。在這類項目中，創始個人或團體同時也負責項目管理，包括確定發展愿景、控制代碼合并權限，并承擔起在公共場合代表項目發言的權利。也有一些項目將創始人/領導者稱為“傳遞的獨裁者”。在這類項目當中，權利與權限的邊界通常非常明確。而一切重要的項目事務，最終決策者都由創始人/領導者擔任。

隨著項目增長至一定規模，這種模型的局限性也變得顯而易見。最終，創始人/領導者的個人偏好會與項目設計的最佳決策區分開來，這時候創始人/領導者反而成為項目決策中的瓶頸。在極端情況下，創始人/領導者模型可以在項目中創建一種“種姓制度”，因為非創始人會逐漸感受到自己根本無力改變創始人的意愿與思路。這種分歧可能導致項目分裂，甚至一旦創始人/領導者出于心理倦怠或計劃內退休等理由而選擇離開，項目也許會瞬間土崩瓦解。

對于采用這類治理模型的項目，大家可以首先瀏覽項目的通信郵件列表，或者訪問討論論壇與項目創始人/領導者建立初步聯絡，而后一一解決該如何提交貢獻成果的問題。這會幫助我們對項目需求建立起全面了解，并據此分析自己最擅長、或者最適合在哪個方面做出貢獻。另外，您需要明確理解創始人/領導者對項目的基本構想，否則一旦與構想有所抵觸、我們提議的變更恐怕會被直接否決。在起步階段，不要指望提出任何不利于創始人/領導者基本愿望的項目修改方案。

自我任命的理事會或董事會模式

認識到“創始人/領導者”模式的缺點，自我任命的理事會或董事會模型希望建立起更順暢、更穩定的領導者繼任制度，借此推動社區走向成功。在這種模式下，開源項目的成員可以任命多個領導小組來管理項目中的各項工作。此類小組可能包括督導委員會、提交者委員會、技術運營委員會、構建委員會或者董事會等。各個小組大多擁有自己的一部分決策慣例與繼任規程。

如果項目缺乏贊助基礎、而且很難建立起選舉機制，那么這種自我任命理事會或董事會治理模型往往能夠發揮良好作用。但請注意，如果自我任命的領導小組被項目社區所孤立、或者代表性不足時，這種模型的弊端就開始顯現。在這種情況下，成員的甄選過程往往會引發激烈沖突，而之后建立的領導文化可能帶來一定抵觸。此外，社區成員可能覺得自己處于被挑選的消極地位，因此對貢獻工作也許缺乏充分的積極性。

要在使用這種治理模型的項目中展開探索，我們不妨先從入門文檔起步。首先需要明確，這種治理模型在較為成熟的開源項目中相當常見，因此社區往往會整理出比較全面的貢獻者入門說明素材。請認真閱讀這些材料，再結合項目的治理文檔確定治理模式的運作方式。在大多數情況下，您都可以聯系理事會或董事會了解項目貢獻中的具體問題。組織內將有專人監督您的貢獻，并回答您可能抱有的疑問。

選舉人制度模式

一部分開源項目會采取選舉人制度進行治理。例如，社區成員會組織各類職務選舉，也可以通過投票進行項目政策及規程的批準或更新。在選舉人制度下，社區將建立并明確記錄下得到成員們普遍認可的選舉規程，而后將這些程序制定為常規決策流程。

這種模型在大型開源代碼項目中較為常見，這里眾多通過資質認證且抱有濃厚興趣的貢獻者共同參與治理工作。此外，擁有穩定贊助方的項目(例如基金會)也普遍采用選舉人制度，這是因為選舉流程能夠提升贊助方資源的分配透明度。選舉型治理傾向于對項目中的各角色、規程與參與方式做出精確記錄。在如此明確的制度依托之下，新的貢獻者將在項目中最大程度發揮自己的力量與熱情。

但選舉人制度也有問題。對于全體項目成員，無論其是否實際參與貢獻，投票結果都可能引起爭議、耗費精力與時間。也有部分社區會在選舉當中要求為某些知名項目成員提供無限期的領導職務;但一般除非項目中明確規定了任期限制，否則選舉與管理團隊成員變動往往沒有關系。

要融入采取這種治理模型的項目，大家可以參考項目網站上公布的選舉結果與領導團隊名單。請認真閱讀這些文檔，確定項目指定的聯系人。擁有良好治理質量的開源社區，一般會在項目網站上闡明關于提議及社區審查的投票流程。隨著您對項目做出有益貢獻、建立堅實的聲譽，您最終有望成為項目中特定領導職位的候選人。請確保與其他貢獻者開展富有成效的互動與協作，可能有一天他們會用自己手中的投票權向您表達支持與敬意。

單一供應商模式

有時候，個別企業或行業協會可能也會遵循某些開源代碼許可條款發布軟件，借以吸引潛在的開發者與用戶。但這類項目往往并不接納受眾做出的項目貢獻。這種方式可能是為了加快工作速度、激勵軟件平臺上的開發活動、支持插件生態系統，或者避免社區在吸納外部開發者方面投入大量資金。

在這種模式下，理事機構通常不接受任何外部人士的貢獻。相反，開源代碼與封源代碼創新只發生在項目邊緣。因此，也有評論者將這種治理模型稱為“圍墻花園”。有時候，遵循此類模型的項目會采用更嚴苛的公共版權許可證，廠商方面希望以這種方式向其他商業競爭對手表示威懾(即迫使具有生產要求的競爭者及客戶購買這款軟件的非開源版本，這種方式也被稱為雙重許可法)。但在這種模型下，項目在事實上沒有開放社區，因為其整體歸企業或財團全資擁有。

要融入采用這種治理模型的項目，大家首先可以考慮自己雇主與項目發起公司之間的關系。接下來，評估項目中的許可條款，并回顧歷史變更記錄與錯誤跟蹤機制，確定您能否以自己喜歡的方式為項目中的特定方面做出貢獻。根據項目的特定規則，您可能會接觸到這些特定方面，但并不算是直接為項目做出貢獻。

基金會支持模式

為了更好地控制資源與項目代碼，某些開源項目會選擇由NGO(非政府組織)專門管理，例如慈善性非營利組織或貿易協會等。這種方式將讓項目擁有相關服務方、商標、專利與保障等資源的明確所有權。

在某些情況下，基金會領導與項目領導將形成單一的治理結構，共同管理開源項目的各方面工作。但也有一些基金會會直接管理部分事務，例如商標與線下活動，并由項目領導團隊負責代碼核準等其他治理事務。

這種規模較大的開源項目，往往需要遵循一系列資金與法律要求。但也有一些小型項目會選擇加入較大的保護性基金會，例如Software Freedom Conservancy或者Linux基金會，借此獲得支持型治理模式的優勢。對于需要與第三方建立法律關系，或者要求在關鍵人物離開后仍可順利過渡及運行的項目，這種治理模型無疑是最佳選擇。這套方案也有助于防止單一廠商支持的項目過度轉向商業化。

但基金會支持治理模型的顯著缺點，在于高昂的運營開銷，不僅是嚴格的財務考量，在貢獻者時間投入方面同樣巨大。部分基金會會以行業協會的形式存在，并由贊助企業在組織內進行管理。不同的協會對于項目貢獻者的參與度也有不同的要求。某些協會相對開放，而某些則把權利牢牢限定在企業管理者手中。

要融入采用這種模型的開源項目，如果基金會方面不參與管理日常項目貢獻活動，請直接參閱入門文檔并遵循內容要求(具體參考自我任命理事會或董事會部分)。但請注意，雖然基金會管理的一切項目都遵循某些基本的貢獻流程，但不同基金會下不同項目可能也會設置自己的專項管理者。要確定項目負責人，您可以向基金會成員郵件列表發送申請。您也可以查閱項目的歷史變更記錄，明確哪些成員貢獻頻率最高(請參閱「專制政體」部分)并與他們聯系。多數基金會還設有基于貢獻的投票系統，因此請熟悉成為基金會正式投票成員的必要流程。如果基金會為僅限成員參與的行業協會，請確定您的雇主是否是其中成員。如果不是，請與上級領導討論項目對工作的重要性，并詢問您的雇主是否考慮加入。無論哪種情況，基金會項目都可能需要簽署書面的貢獻者申請文件。請在法律部門的協助下審查并簽署此份文件。