1. 治理和托管模式

1.1. 開源的理念源自黑客社群，他們看到了現有軟件生產和使用方法中的問題

1.2. 擁有有效的治理模式是長期成功和可持續發展的關鍵

1.3. 開源治理旨在為社群提供類似的清晰度，并為項目的運作奠定了基礎

1.4. 項目的需求和社群的文化會隨著時間的推移而改變，調整治理模式以支持這些需求能夠確保得到支持并提升參與度

2. 開源治理

2.1. 開源治理就是開源項目需要具備的流程和政策，以使開源項目能夠正常運行

• 2.1.1. 項目如何接受代碼？

• 2.1.2. 項目如何發布代碼更新？

• 2.1.3. 由誰決定哪些代碼可以進入項目，哪些代碼不可以？

• 2.1.4. 需要做什么才能為項目貢獻代碼？

• 2.1.5. 項目如何處理問題？

• 2.1.6. 如何解決和披露安全漏洞？

• 2.1.7. 誰可以作為項目代言人？

• 2.1.8. 誰擁有項目的名稱、作品和其他資產？

2.2. 行動至上

• 2.2.1. 最基本的治理模式是由實際做工作的人驅動的，這通常被稱為“行動至上”

  • 2.2.1.1. 精英治理

• 2.2.2. 開源通常是由其用戶和貢獻者驅動的

• 2.2.3. 許多人是有償從事開源工作的，但他們的報酬是由那些希望看到特定項目成功的人支付的

• 2.2.4. 行動者需要解決各自的問題，可能會存在沖

• 2.2.5. 行動者在做事效率上有些起伏不定，導致代碼倉庫中的某些部分發展得更快，而其他部分則停滯不前。從外部看，?“行動至上”的項目往往

• 2.2.6. “行動至上”的項目往往看起來像是封閉的俱樂部，這會給新加入者帶來挑戰

2.3. BDFL

• 2.3.1. 終身仁慈獨裁者(Benevolent Dictators for Life，BDFL)模式

• 2.3.2. 當項目陷入沖突或困境時，我們經常看到他們回頭尋求創始人的指導

• 2.3.3. 在關鍵決策方面也會尊重他們的意見

• 2.3.4. 項目的文化從一開始就與創始人的愿景一致

• 2.3.5. BDFL可以是項目從一開始就采取的一種治理模式，也可以從前述的“行動至上”模式演變而來

• 2.3.6. Rasmus Lerdorf于PHP，Linus Torvalds于Linux，Guido van Rossum于Python

• 2.3.7. 在BDFL中，治理是一把雙刃劍

  • 2.3.7.1. 許多成功的項目都有謙虛、包容和富有創造性的創始人領袖，他們幫助設定了社群運作的積極基調

  • 2.3.7.2. 有一些項目則存在分歧，導致項目出現分支

• 2.3.8. 即使有最好的BDFL，仍然會面臨所有決策都要通過一個人的瓶頸問題

  • 2.3.8.1. Linus也意識到了這一點，因此他在Linux中設立了幾個關鍵維護者來分擔工作，畢竟Linux內核每天都有數千行代碼的改動

2.4. 技術委員會

• 2.4.1. 創始人的角色充滿挑戰，問問任何一個創建過公司的人就知道了

• 2.4.2. 創始人也很難判斷何時該下放權力

• 2.4.3. 創始人通常對公司的運營和形象塑造有著敏銳的眼光

• 2.4.4. 創始人會意識到他們需要讓其他人來處理組織中的一部分工作

• 2.4.5. 幫助項目建立一個技術指導委員會(Technical Steering Committee，TSC)

  • 2.4.5.1. 可以作為一個團隊來領導項目，而不是僅僅依賴一個人

• 2.4.6. 如何讓人們能夠主動承擔領導角色

• 2.4.7. 許多技術人員更熱愛技術本身，而對領導的官僚作風不太感興趣

• 2.4.8. 作為創始人和領導者，需要吸引更多人參與進來，通常也包括社群中那些愿意主動承擔領導責任的人

  • 2.4.8.1. 也是自我任命的委員會治理的核心意義

• 2.4.9. 技術委員會是“行動至上”理念的正式化，旨在構建一個可持續發展且沒有獨裁領導的項目

  • 2.4.9.1. Apache軟件基金會、學院軟件基金會、LF AI和Data基金會以及LF能源基金會中的許多項目都是如此

  • 2.4.9.2. 最初開發者對一個項目產生興趣，然后挺身而出逐步領導項目

2.5. 選舉

• 2.5.1. 社群會開始尋求更加民主的方式來治理，這就引出了選舉類型的治理模式

• 2.5.2. 選舉治理模式是從技術委員會模式演變而來的，其中相應角色是選舉產生的而不是自我提名的

• 2.5.3. 通常發生在項目中個人和公司之間出現利益沖突時，并且項目需要確保決策是公正和公平的，為了解決這個問題，項目成員會進行選舉

• 2.5.4. 可以用來選出領導者，他們將在一定期限內任職

• 2.5.5. CNCF的技術監督委員會(Technical Oversight Committee，TOC)就是這樣做的，并制定了正式的選舉程序和時間表

  • 2.5.5.1. 確保領導者定期輪換，這不僅有助于為項目帶來新的想法和觀點，還有助于確保避免領導者因為覺得無法離開項目而筋疲力盡

• 2.5.6. ApacheWay的一個關鍵原則之一是共識決策

  • 2.5.6.1. ApacheWay的一個關鍵原則之一是共識決策

  • 2.5.6.2. 通過針對一個問題征求?1、0或+1的投票來實現，如果有人投了一個?1的票，就需要他們提出一個替代解決方案，或者詳細解釋為什么他們投反對票

  • 2.5.6.3. 好處是它為建設性的分歧意見提供了空間，并幫助形成了一個包容各方反饋的建議

2.6. 單一供應商

• 2.6.1. 這種治理模式根植于單個組織創建的開源項目，該項目可能是組織現有產品的衍生品，或者可能是他們想要開源發布的一些內部工具

2.7. 供應商中立的基金會

• 2.7.1. 一個成功的開源項目也會遇到天花板

  • 2.7.1.1. 不清楚項目的資金來源或運作方式，或者人們認為它主要惠及單一供應商

  • 2.7.1.2. 沒有中立的資產所有者，包括項目名稱、標志、域名、社交賬戶和其他資產

  • 2.7.1.3. 項目的版權所有者是單一的實體，他們可以單方面更改許可證和知識產權政策，而無須社群的參與

  • 2.7.1.4. 利用該技術的供應商認為他們沒有公平合作的空間，特別是當他們之間存在競爭關系時

  • 2.7.1.5. 項目的法律、信托和財務方面由一個組織管理，沒有透明度或既定的流程

  • 2.7.1.6. 最好的解決方案是尋求供應商中立的基金會治理

• 2.7.2. 建立自己的基金會

  • 2.7.2.1. Rust基金會、Python語言基金會、PHP基金會、Ruby Central和GNOME基金會

• 2.7.3. 選擇像Apache軟件基金會、Eclipse基金會、Linux基金會或OASIS開放組織這樣的現有基金會

3. 開源項目中的角色

3.1. 用戶

• 3.1.1. 開源項目中的每個人都是從使用項目開始的

• 3.1.2. 用戶數量增加不僅會提高用戶轉化為貢獻者的可能性，還能提升社交方面的影響，從而向潛在貢獻者展示成為貢獻者的價值和機會

• 3.1.3. 目標是至少有一些用戶來幫助形成社群，這需要通過貢獻來實現

3.2. 貢獻者

• 3.2.1. 當你為一個項目做了一些有益的事情時，你就成了一個貢獻者

• 3.2.2. 開源項目認為貢獻者是那些直接向項目提供代碼的人

• 3.2.3. 當有貢獻者能夠為項目提供高標準代碼時，你就可以看出他們對項目的深切投入

3.3. 維護者

• 3.3.1. 作為一名維護者，有時也被稱為提交者，既是一份承諾，也是一份信任

• 3.3.2. 承諾來自個人對項目的持續關注和推動項目向前發展的興趣

• 3.3.3. 這類人認為項目對他們有價值，可以解決一些問題，并能夠幫助他們完成任務

• 3.3.4. 信任也是成為維護者的重要組成部分

  • 3.3.4.1. 維護者可以更改項目中的代碼，這是巨大的信任

  • 3.3.4.2. 維護者也了解代碼倉庫的所有細微差別和細節，維護者知道代碼哪里好，哪里還可以，哪里需要改進

• 3.3.5. 在較小的項目中，維護者是首要角色

3.4. 領導者

• 3.4.1. 開源社群的領導者不是獨裁者

• 3.4.2. 源項目的領導者會確立方向、解決沖突、幫助平衡優先事項，但更重要的是，他們為社群服務

• 3.4.3. 開源項目的領導者意味著必須確保項目和社群中的每個人都能成功

• 3.4.4. 服務型領導者，意思是成為一個為他人提供支持、資源和指導的領導者

4. 記錄開源項目的治理結構

4.1. 記錄治理結構很重要，因為理解過去的決策有利于在未來做出更好的決策

4.2. 可發現性

• 4.2.1. 就是要讓治理的源頭容易被找到

• 4.2.2. 從一個好的README文件開始通常是很好的方式

  • 4.2.2.1. 這個項目是什么？它能夠做什么？

  • 4.2.2.2. 如何安裝和使用該項目？

  • 4.2.2.3. 如果你有問題或疑問，應該去哪里尋求幫助？

  • 4.2.2.4. 如果你想為項目作出貢獻，應該怎么做？

  • 4.2.2.5. 項目將走向何方（也稱為路線圖）?？

• 4.2.3. 許可證(LICENSE)，詳細說明項目的開源許可證

• 4.2.4. 貢獻文件(CONTRIBUTING)，使人們知道如何為項目貢獻代碼

• 4.2.5. 發布文件(RELEASE)，使人們知道新版本是如何發布的

• 4.2.6. 支持文件(SUPPORT)，使人們知道去哪里尋求支持

4.3. 簡單性

4.4. 靈活性

• 4.4.1. 為了有效地發展，開源項目需要能夠隨著時間的推移輕松地進行調整

  • 4.4.1.1. 這就是靈活的治理模式發揮作用的地方

• 4.4.2. 靈活意味著理解社群，并與他們合作尋找解決方案

• 4.4.3. 最重要的是，當有分歧時，應該理解他們的擔憂并努力適應他們

5. 開源項目的財務支持

5.1. 開源的“自由如同言論自由，而不是免費啤酒”

5.2. 開源的自由部分指的是你可以自由使用代碼，而不僅僅是開發或所有權的免費

5.3. 開發軟件，無論是開源的還是專有的，都有經濟成本，而這個成本必須由某人承擔

5.4. 開源的成本往往由維護者承擔，因為他們投入了時間和精力運營一個廣泛使用的開源項目

5.5. 現代應用程序堆棧有很多依賴，有的依賴很快就會成為一個關鍵的依賴，而人們卻沒有意識到維護者的負擔有多大

5.6. 小費

• 5.6.1. 小費資助模式與街頭藝人演奏樂器類似，他們把樂器箱打開，希望路人能投錢進去

• 5.6.2. 模式背后的心態是：?“這是我寫的一些代碼，如果對你有價值，請隨意捐贈。?”

• 5.6.3. 一些項目維護者會提供PayPal或Venmo賬戶來接收捐款

• 5.6.4. 小費資助模式最大的挑戰是它不可持續，這意味著收入時高時低

• 5.6.5. 另一個主要挑戰是，如果你看一下支持一個用戶的成本，往往可能超過他們給出的小費

• 5.6.6. 小費資助的方法會讓用戶感覺他們當下的貢獻是用小費來資助項目，而他們其實可以提供更有益的貢獻

5.7. 眾籌

• 5.7.1. 眾籌可能是一個許多人都熟悉的概念，因為它已經通過Kickstarter、Patreon和GoFundMe等網站成為我們社會的一部分

• 5.7.2. 在開源中，眾籌已經從非正式的小費資助模式過渡到更為結構化的模式

• 5.7.3. 眾籌可以為特定的開發籌集資金

  • 5.7.3.1. 一種方式是維護者為特定問題或功能發布資金請求，一旦所需的資金到位，維護者就會進行開發

    5.7.3.1.1. 這不僅是幫助維護者籌集工作資金的一種方式，還有助于維護者評估工作對社群的價值

  • 5.7.3.2. 看到捐贈者會得到一定程度的認可，就像各種劇院或藝術項目會對不同級別的捐贈者表達感謝一樣

  • 5.7.3.3. 通常需要一個合法的組織來接受捐贈

    5.7.3.3.1. 許多捐贈者根據自己所在地的相關法規，希望能夠享受某些稅收優惠，如果項目不具有非營利性質，這可能會增加接受捐贈的間接成本

5.8. 單一組織資助

• 5.8.1. 如果一個組織認為開源項目對他們的業務有價值，通常會尋求為其提供資金支持，可以通過捐贈、提供資金讓開發者能夠參加相關會議或活動，或者雇用那些關鍵開發者成為他們的員工，使其全職投入項目的開發與維護中

• 5.8.2. 該組織成為確保項目繼續推進的關鍵

5.9. 基金會

• 5.9.1. 基金會資助模式背后的主要思想是將所有資金投入一個單一的、供應商中立的實體，并由多個利益相關者監督，由一個獨立的組織管理日常財務

• 5.9.2. Python軟件基金會(Python Software Foundation，PSF)，它是一家美國501(c)(3)非營利公司，是單個項目基金會的一個例子

  • 5.9.2.1. 一些員工幫助管理后端操作，并幫助籌款

  • 5.9.2.2. 還有一個管理委員會提供監督

  • 5.9.2.3. 委員會和員工都不會參與項目本身的技術開發或優先事項

  • 5.9.2.4. PSF的法人實體類型是美國501(c)(3)實體

    5.9.2.4.1. 501(c)(3)實體的捐贈通常是可以免稅的

• 5.9.3. 傘形項目基金會的一個很好的例子是LF能源(LF Energy，LFE)基金會，這是一個專門針對能源行業的開源項目家園，由Linux基金會托管

  • 5.9.3.1. 員工和委員會都不參與項目本身的技術開發或優先事項

  • 5.9.3.2. LFE的法人實體類型是美國501(c)(6)實體

  • 5.9.3.3. 501(c)(6)實體被美國國稅局視為“貿易組織”?，這意味著它由會員資金驅動

    5.9.3.3.1. 向501(c)(6)實體的捐贈在美國是不可免稅的

• 5.9.4. 托管多個項目時，需要在項目之間進行一些監督和協調，同時確保每個托管項目具有自主權

• 5.9.5. 技術咨詢委員會(Technical Advisory Council，TAC)

  • 5.9.5.1. TAC擁有指導原則來幫助他們確定哪些項目適合，哪些不適合