開源項目治理需要回答的6個問題
要說開源代碼項目該發揮什么作用，很多朋友首先想到的就是開源許可。一方面，不少人認為不符合開源代碼倡議（OSI）許可的項目根本就不能算真正的開源。另外，選擇使用GNU通用公共許可證（GPL）、MIT許可證等公共版權許可，則有可能給項目的使用方式與社區發展帶來深遠影響。
但Linux基金會開發者關系副總裁Chris Aniszczyk看來，許可本身并不會真正提示我們該如何管理項目。因此，如何對項目進行開放式管理才是問題的核心。他還補充道，在糾紛出現之前回答這些問題，并對一切參與者提供開放、公平的見解表達渠道，正是項目在規模擴大的過程中取得長期成功的前提。
開源項目需要解決以下6大治理難題： 誰來做出決策？ 如何添加維護者？誰擁有域內權利？誰擁有商標權？具體事件如何治理？誰負責確定構建系統的運作方式？
面對上述難題，可以看見并不存在那種百試百靈的正確答案。無論是出于社區的特定需求、還是某些歷史原因的影響，不同項目以及托管項目的基金會往往采用自己的方法。
也正因為如此，不少項目決定選擇“傳遞的獨裁者”（BDFL）模式。在這種模式當中，將由一個人（通常是項目的創始者）對重大項目決策擁有最終裁定權。默認情況下，不少項目止步于此，Linux內核項目本身就是這樣的例子。但是，Red Hat公司的Joe Brockmeier卻在觀察中發現，BDFL已經成為一種典型的“反模式”。“雖然確實有一部分項目在BDFL的推動下取得了成功，但更多項目也由此徹底迷失了前進方向。”
Aniszczyk發現，“不同的基金會往往擁有不同的章程、條款及其組織方式，而且具體組織層面存在大量差異因素。例如，Apache Way就頗具盛名，這也是Apache指導自身運作的方式。這是一種孵化器過程，各個項目需要憑借自己的努力一步步走向畢業。從項目管理角度來看，這基本屬于「廣撒網」的競爭篩選方式。”
Aniszczyk就項目管理提出了一些最低要求。他強調，“在眾多Linux基金會與云原生計算基金會（CNCF）項目當中，我們采取的是Governance.md文件模式，其中描述了如何制定決策、如何管理事物、如何添加/撤銷維護者、如何進行子項目添加/刪除、如何發布開發成果等等。這些僅僅只是第一步。”
其次，他認為“如果不以中立方式設定資產所有權，就根本不可能實現開放式治理。畢竟最終，域、商標權及某些其他版權必然歸屬于某個人或某些人。不少運營出色的組織在這方面就采取極輕量化機制，例如Apache基金會、Software in the Public Interest以及Software Freedom Conservancy等，都做出了自己的嘗試。”
Aniszczyk還提到，目前相當一部分常用方法都在某種程度上屬于反模式。以貢獻者許可協議（CLA）為例，其中定義了代碼等知識產權進行項目貢獻時應當依據的條款。在他看來，如果企業希望“制造產品或使用雙重許可類模型，那么CLA無疑值得考慮。但對于其他需求，我認為CLA反而會給開發人員帶來巨大的困擾。”
相反，Aniszczyk鼓勵人們“使用所謂「開發者原研證書」（Developer Certificate of Origin）。作為Linux內核項目選擇的解決方案，它吸納了CLA中的大部分主體內容，例如「這段代碼是我親手所寫嗎？我是否承諾從未將其復制到其他項目？我是否有權將這些成果移交給您，并由您認可及處置？」這是一套非常成功的模型，已經在Linux內核及多種其他生態系統中發揮了作用。除非有著嚴格的業務需求，否則我個人真的不太建議使用CLA。”
他還發現了很多命名錯誤情況。“項目品牌非常重要。人們往往會先在企業內部或者以個人方式啟動一個項目，比如說「Docker」，之后據此建立生態系統，接著是創建起Docker公司，最終是Docker產品或企業級方案。所有這一切，都將服務于不同的受眾，也因此引起不少誤解。所以我個人有一種固有信念，即某一事物的名稱天然具有附加的價值主張。因此，大家最好能把企業名稱、項目名稱與產品名稱區分開來。”
最后，Aniszczyk還提到了開放式治理在建立信任與項目信心方面的作用。通過這種方式，企業會強調自己不會只在項目中單方面強調自己的需求與規劃。他總結道，“要想建立起強大的社區，信任是一種必要的前提。如果開源項目缺少開放治理機構的支持，貢獻者很難說服自己為項目貢獻寶貴的時間與精力。”
