學會管理成長中的項目

你們的項目正在成長，也有人參與進來，你們承諾保持這樣的狀態。在這個階段，你們可能想知道如何將常規項目貢獻者納入你們的工作流程，無論是否給他們提交權限或者解決社區辯論。如果你們有疑問，我們給出了答案。

在開源項目中使用正式角色的示例有哪些？

許多項目遵循類似的貢獻者角色和認可結構。

這些角色實際上意味著什么，完全取決于你。這里有一些你可能認識的角色類型：

• Maintainer（維護者）
• Contributor（貢獻者）
• Committer（提交者）

對于一些項目來說，"maintainers" 是在項目中有提交權限的人。在其他項目中，他們是作為維護者被名字被列在 README 中的人。

維護者不一定要是為項目編碼的人。他可能是為你們項目的宣傳做了很多工作的人，或者是為項目編寫文檔以方便其他人使用的人。無論他們每天做了什么，維護者是對項目的方向有責任感以及致力于改善項目的人。

一名 "contributor" 可以是任何評論過 issue 或者 pull request 的人，給項目帶來價值（無論是對 issues 進行分類，編碼，或者組織活動）的人，或者任何合并過 pull request 的人（可能是貢獻者最狹隘的定義）。

image.png

對于 Node.js 來說，項目社區中的每個人都參與評論 issue 或者提交代碼。這意味著他們從用戶過度到了貢獻者。
— @mikeal, "Healthy Open Source"

術語"提交者"可能是用于區分提交權限，它是一個有著明確責任的角色類型，來自其它形式的貢獻。

雖然你們可以以任何你們想要的方式定義項目角色，但
請考慮使用更廣泛的定義來鼓勵更多來自其他形式的貢獻。你們可以利用管理者的身份認識為項目做出特別貢獻的人，不論他們的技能是什么。

image.png

你們可能認為我是 Django 的“發明者”...但事實是當她誕生一年后我才參與這份工作。（...）人們懷疑我成功了，因為我的編程技能...但我最多只是個普通的程序員。
— @jacobian, "PyCon 2015 Keynote" (video)

我如何正式化這些領導者角色？

正式化你們的領導者角色能夠幫助人們有歸屬感并告訴社區中的其他成員他們可以向誰尋求幫助。

對于小項目來說，指派領導者可以和將他們的名字添加到你們的 README 或者 CONTRIBUTORS 的文本文件中一樣簡單。

對與比較大的項目來說，如果你們有網站，可以創建一個團隊網頁或者將你們項目的領導者們排列在上面。例如 PostgreSQL 有一個詳細的團隊頁面并有每個貢獻者的簡單信息。

如果你們的項目有個非常活躍的社區，你們可能形成一個維護者的“核心團隊”，甚至擁有來自不同 issue 領域（例如：安全，issue 分類或者社區準則）的人組成的小組委員會。讓大家自己組織并志愿選擇他們喜歡的角色，而不是分配給他們。

我們補充了核心團隊和幾個“子團隊”。每個子團隊專注于一個特定領域（如：語言設計或者庫）。（。。。）為了整個項目的協作和強大，每個團隊的愿景要與整個項目愿景保持一致，每個子團隊由一名來自核心團隊的成員領導。
— "Rust Governance RFC"

領導者團隊可能想要創建一個指定的通道（像 IRC）或者定期會面來討論項目（像 Gitter 或者 Google Hangout）。你們甚至可以組織這樣的公開會議以便其他人參與。例如，Cucumber-ruby 的每周辦公時間。

一旦你們建立了領導者角色，請記得以文檔的形式記錄告訴大家如何聯系他們！給大家如何成為你們項目的一名維護者或者僅僅是加入一個子委員會建立一個清晰的流程，并將之寫進你們的GOVERNANCE.md中。

有些工具像 Vossibility 可以幫助你公開跟蹤誰給項目了貢獻（或者沒有）。記錄這些信息可以避免社區認為維護者是一個團體，可以私下作出決定。

最后，如果你們的項目在 GitHub 上，請考慮將你們的項目從個人賬號轉移到一個組織并添加至少一個備份管理員。GitHub 組織

我什么時候應該給一些人提交權限？

一些人認為你們應該給所有參與貢獻的人提交權限。這么做能夠讓更多的人對項目有歸屬感。

一方面，特別是對于比較大，很復雜的項目，你們可能只想把提交權給那些已經表示了忠心的人。這種事沒什么對錯，你們開心就好！

如果你們的項目在 GitHub 上，你們可以利用受保護的 branches管理誰可以在什么情況下像某個特定的 branch 進行 push。

image.png

無論什么時候有人向你們發送一個 pull request，請給他們你們項目的提交權限。雖然這聽上去非常愚蠢，但是使用這樣的策略能夠讓你們充分利用GitHub的優勢。（。。。）一旦大家有了提交權限，他們就 不用再擔心他們的補丁沒有合并了...造成他們浪費了大量的時間。
— @felixge, "The Pull Request Hack"

開源項目的一些常見治理結構有哪些？

這里有三個與開源項目有關的常見治理結構。

• BDFL:SDFL 表示 ”Benevolent Dictator for Life（仁慈的獨裁者的生活）”。在這個模式下，只有一個人（通常是項目的作者）對項目的主要決議有最終得決定權。Python 就是一個經典的示例。小項目一般默認是 BDFL，因為他們只有一兩個維護者。如果是公司的項目可能也會使用這中策略。

• Meritocracy（精英）: (注意：這個術語 "meritocracy（精英）"對一些社區來說帶有消極的意味，同時用有一個復雜的社會以及政治歷史。)在精英模式下，活躍的貢獻者（展示"價值"的人）被賦予了一個正式的決策者角色。決議通常是通過純投票的形式抉擇。這個權威的概念是由 Apache Foundation 首創；所有 Apache 的項目都是精英。貢獻僅由他們個人提供，而不是公司。

• Liberal contribution（自由貢獻）:在自由貢獻模式下，做最多工作的人被認為是最有影響力的，但是是以現在的當前工作為基準而不是過去的貢獻。項目的主要決議都是通過尋求共識的方式得到的，而不是以純投票的形式，并努力考慮社區中更多的觀點。使用自由貢獻模式非常流行的示例包括：Node.js 和 Rust。

你們應該選擇哪種？這取決于你們！每種模式都有有點以及需要權衡之處。雖然咋一看他們有著很大的不同，但是他們的共同點要比看上去的多。如果你們有興趣采用其中的一種模式，可以瀏覽這些模板：

• BDFL model template
• Meritocracy model template
• Node.js's liberal contribution policy

當我的項目啟動時我需要編寫管理文檔嗎？

雖然沒有合適的時間寫下你們項目的管理文檔，
但一旦你們看到你門的社區動態表現，它就容易定義了。開源管理的最好（最難的）部分是它是由社區塑造的！

一些早期文檔不可避免的是用于你們項目的管理。所以，開始寫下你們可以寫的。例如，在你們項目啟動的時候你們可以清晰地說明期待什么樣的行為，或者你們的貢獻者如何處理工作。

如果你們是參與公司開源項目啟動的成員，在項目發布之前，你們有必要進行內部討論，了解你們的公司如何保持并決定項目的進展。你們也可以公開解釋貴公司將如何（或不會）參與該項目的任何事情。

image.png

我們分配小團隊來管理GitHub上的項目，他們實際上在Facebook工作。例如，React是由一位React工程師管理。
— @caabernathy, "An inside look at open source at Facebook"

如果公司的員工開始提交貢獻會發生什么？

成功大開源項目會被很多人和公司使用，以及甚至有些公司的收入會與這些項目有關。例如，公司可能使用開源項目中大代碼作為他們商業服務的一部分。

隨著項目被廣泛地使用，會需要更多具有專業知識的人，你們可能就是他們中的一個！同時，有時大家在為項目工作時會得到報酬。

重要的是平常心對待商業活動，并且將之視作其他資源發展的動力。當然，不應該區別對待有報酬的開發者和其他無薪酬的；每個貢獻都應該根據其技術特點進行評估。然而，大家應該開心地參加商業轟動；同時當爭論對項目有利時，大方地陳述他們的用例。

“商業”和“開源”是兼容的。“商業”僅僅是意味著有金錢的參與，軟件被用于商業，這有利于項目的發展和推廣。（雖然非開源產權中使用了開源軟件，但整個產品依然是“專利”軟件。開源可以用于商業或者非商業目的。）

和任何人一樣，具有商業動機的開發者也是通過他們貢獻的質量和數量提高影響力的。很明顯，得到報酬的開發者可能會比沒有報酬的做的更多，但這是被允許的；金錢只是影響一些人做少事情的很多因素中的一個。讓你們的項目討論側重于貢獻，而不是關注使人們能夠做出貢獻的外部因素。

我需要一個法律顧問來支持我的項目嗎？

你們不需要法律顧問來支持你們的開源項目，除非涉及到金錢。

例如，如果你們想創建商業業務，你們將要建立 C Crop 或者 LLC （如果你們位于美國）。如果你們只是做與你們的開源項目相關的合同工作，你可以作為獨資經營者接受金錢，或設立一個 LLC（如果你在美國）。

如果你們的開源項目想要接受捐贈，你們可以設置一個捐贈按鈕（例如使用 PayPal 或者 Stripe,還有中國的支付寶和微信支付），除非您是符合條件的非營利機構（如果您在美國），否則這筆錢不會免稅。

很多項目為了省去建立非盈利機構的麻煩而去找一家非營利機構贊助他們。非營利機構代替你們接受捐贈，但你們需要給他一定比例的捐款。自由軟件保護, Apache 基金會, Eclipse 基金會, Linux 基金會 和 Open Collective 都是為開源項目提供贊助的組織。

image.png

我們的目的是提供可被商業持續使用的基礎設施，因此創造一個每個人（包括貢獻者，支持者，贊助者）都能受益的環境。
— @piamancini, "Moving beyond the charity framework"

如果你們的項目與某種特定的語言或者生態系統聯系緊密，那么你們可以和與之相關的基金會合作。例如，Python 軟件基金會幫助支持用于管理 Python 包的 PyPI，Node.js 基金會幫助支持一個 Node 基礎框架項目 Express.js。