1. 領導者的過渡

1.1. 偉大的領袖未必是做大事的人，而是能夠讓別人做大事的人。

• 1.1.1. Ronald Reagan

1.2. 一個人的成就不是靠你自己的雙手創造的，而是靠你對他人的影響和作用來建立的

1.3. 貢獻者和用户不是員工，他們和項目社羣沒有財務上的約束，他們參與只是因為他們想要參與

1.4. 開源項目的成功很大一部分都是源自這些貢獻者和用户，如果沒有他們，開發資源很快就會匱乏，項目也就沒有了受眾

1.5. 要成為一名優秀的領導者，就必須確保這些貢獻者和用户能夠在項目中或利用項目產生的代碼出色地完成工作

1.6. 開源項目的領導也是一份吃力不討好的工作

1.7. 所有開源項目的代碼都是在開源許可證下發布的，因此開源項目理論上是無限期的，但那些貢獻者和維護者並不會永遠存在

2. 為何要考慮領導者的過渡

2.1. 不是所有的項目都是永恆的，但代碼一旦在開源許可證下發布，就會永遠存在

2.2. 如果一個項目已然日薄西山​，也完全可接受

2.3. 如果這個項目正有着很活躍的用户和社羣，引入新的領導者對項目的可持續發展就非常重要

2.4. 原因

• 2.4.1. 職業變動

• 2.4.1.1. 在我們之前的幾代人中，終生從事同一職業的人往往比較常見，但在如今的世界，這是不現實的

• 2.4.1.2. 開源項目通常會作為職業生涯的跳板

>  2.4.1.2.1. 僱主一般都會非常積極地允許他們維護自己的項目，因為他們之所以被僱用，通常是由於該項目對僱主來説相當重要

• 2.4.1.3. 隨着時間的推移和新技術的不斷涌現，趨勢會發生變化，開發者很可能跟不上時代的步伐

• 2.4.2. 即將退休的項目領導者

• 2.4.2.1. 職業變動是需要進行領導者過渡的一個方面，而退休更是我們所有人最大的職業變動

• 2.4.2.2. 就像職業變動模式一樣，你通常看到的模式是，現任領導者採用仁慈獨裁者模式，然後要麼過渡到新的領導者，要麼採用技術委員會或供應商中立的基金會治理等模式

• 2.4.2.3. 通常很難找到與現任的領導者一樣充滿熱情並具備廣泛技能的人

• 2.4.2.4. 或者是項目已經被廣泛使用了，一個領導者無法處理所有事務

• 2.4.2.5. 像Ruby、Python和PHP這樣的項目都是從仁慈獨裁者模式過渡到了供應商中立的基金會治理模式

• 2.4.2.6. 改變項目的治理模式可能會造成非常大的影響，所以專注於繼任和長期資產管理是首要問題

• 2.4.3. 項目停滯不前

• 2.4.3.1. 當你啓動一個開源項目時，總會有很多令人興奮的事情

>  2.4.3.1.1. 代碼開始源源不斷地涌入，代碼倉庫被組織起來，人們開始下載代碼並嘗試使用

• 2.4.3.2. 有超過2600萬個GitHub倉庫自2021年就沒有更新過，而自2021年之後更新的僅有1200多萬個

• 2.4.3.3. 最後提交時間並不是一個很好的評價指標，再説，一個項目也可能被認為是功能完備或完成，所以不會有太多變動

• 2.4.3.4. 尊重維護者是至關重要的，他們將自己的知識產權以開源許可證發佈，並幫助你解決了問題，因此請與他們合作使代碼變得更好，而不是在不向他們回傳代碼的情況下進行分支

3. 制定繼任計劃

3.1. 繼任計劃是許多組織（特別是大型和長期運營的組織）會花費大量時間制定的事務

3.2. 組織制定繼任計劃是因為有人依賴這個組織，他們可能是員工、客户或投資者，他們都對組織的成功持續運營有着切實的關注

3.3. 開源項目同樣依賴於龐大的用户社羣，因此也必須考慮繼任計劃。繼任計劃不是一個單一的過程，它涉及不同的環節，並可能需要花一些時間才能完全完成

3.4. 記錄項目的運營

• 3.4.1. 不僅是為了讓每個人都清楚事情是如何運作的，更重要的是，因為人們都很容易忘記項目的所有政策和流程，特別是當他們不經常使用的時候

• 3.4.2. 項目使用的所有服務（社交媒體、構建資源、代碼倉庫、掃描工具和任何其他協作工具）的憑證

• 3.4.3. 構建和測試基礎設施的工作方式，包括所使用的服務和工具，以及它們如何互動和協同工作

• 3.4.3.1. 如何安裝或部署項目代碼

• 3.4.3.2. 發佈計劃和路線圖

• 3.4.3.3. 代碼架構和設計

• 3.4.4. 文檔記錄是一個持續的過程，項目應儘早開始並持續維護

3.5. 新領導者的時間安排和培養

• 3.5.1. 完成文檔編寫的工作後，下一階段就是開始實施領導者過渡的流程

• 3.5.2. 你永遠不知道CEO何時會離開組織、去世或表現不佳，因此讓潛在的繼任者做好準備有助於加快領導者的過渡

• 3.5.3. 讓組織有機會利用現任領導者的智慧和經驗來指導和培養未來的領導者

• 3.5.4. 在現任維護者的指導下逐步有計劃地培養新維護者是最好的方法

• 3.5.5. 現今的開源項目通常沒有能力像商業公司一樣有潛在的領導者能隨時準備好被任命為新的項目領導者

• 3.5.5.1. 找到願意領導項目的人已經很難，更不用説是合格的人了

• 3.5.5.2. 開源項目並沒有分佈全球的數千名員工，大多數都是單一維護者項目，只有少數項目擁有超過幾十名維護者

• 3.5.5.3. 開源項目維護者很少獲得報酬，而且即使有，也遠遠低於市場水平

• 3.5.6. 開源項目可以從上市公司的繼任計劃中學到一些東西，提前規劃總好過為時已晚的倉促應對

• 3.5.6.1. 評估現任維護者/領導者預計在其崗位上工作多久

• 3.5.6.2. 認為某個人可以取代現任維護者/領導者的想法可能不太現實，可能應該由多人分擔這個角色

• 3.5.6.3. 確定潛在的領導者，讓他們承擔部分職責，並跟隨現任領導者

• 3.5.6.4. 就領導結構的任何變化徵求社羣關鍵成員的意見

>  3.5.6.4.1. 關鍵的是，你要為新的領導者和領導結構的順利運作做好準備

• 3.5.6.5. 公開宣佈新的領導者和領導結構

>  3.5.6.5.1. 確保給社羣提問的機會，並讓新老領導者都參與進來

>  3.5.6.5.2. 在公開宣佈時，透明度很關鍵，你必須為社羣提供儘可能多的信息，以便使他們理解為什麼會發生這種轉變

• 3.5.7. 並不是所有的項目都有幸擁有足夠多的維護者以提前計劃領導者繼任，規模較小的項目可能只有2～3名維護者

• 3.5.7.1. 每個維護者都應該實事求是地考慮自己想在維護者崗位上投入多久，確定接替他們的最佳方式，然後找到並培養這些繼任者

• 3.5.7.2. 要有意識地思考併為未來制定計劃

• 3.5.7.3. 確保有一個計劃來維持項目的長期發展就很重要

3.6. 從容地退居幕後

• 3.6.1. 最難的部分就是讓現任領導者退居幕後

• 3.6.2. 即使制定了最佳的過渡計劃，要“一刀切”地讓現任領導者從項目中退居幕後仍然是一項挑戰

• 3.6.3. 這個過程應該是循序漸進的，新的維護者和領導者逐步接管項目活動，同時減少對原計劃中被替換的維護者的依賴

• 3.6.4. 許多維護者在逐步退出時都會採取謹慎的態度，因為他們對項目傾注了大量的精力和熱情，渴望確保項目以後能夠被妥善管理

• 3.6.5. 有些維護者可能已對項目感到精疲力盡，他們只是很高興能找到人接手

• 3.6.6. 適當地做出後援

• 3.6.6.1. 最重要的是確保前任領導者保持一定的存在感，而不是完全退出

• 3.6.6.2. 擔任開源項目領導者往往是孤獨的，因此來自曾經處於該位置的人的支持和鼓勵對新領導者來説至關重要

• 3.6.6.3. 讓前任領導者作為後援非常有益

• 3.6.6.4. 雖然前任領導者的參與很重要，但他們並不總是掌握所有答案

• 3.6.7. 為新領導者背書

• 3.6.7.1. 在實踐中，當項目轉入供應商中立的基金會後，新加入的成員通常會在關鍵決策上聽從原貢獻組織的意見

• 3.6.7.2. 意味着新領導者雖然可能擁有名義上的“立法權”​，但在實際操作中可能缺乏影響力

• 3.6.7.3. 項目分支通常會導致注意力分散，最終結果要麼是分支項目獲勝，要麼是主項目獲勝

• 3.6.7.4. 前任領導者需要謹慎行事，因為新領導者可能會做出他們不支持的決策或行動

• 3.6.8. 為新領導者建立廣泛的支持網絡

• 3.6.8.1. 接納並向同輩人學習也同樣重要

• 3.6.8.2. 參加開源會議：開源項目的領導者通常都會出席這些會議

• 3.6.8.3. 持續對話：當你遇到一些你欽佩且易於交談的項目領導者時，儘量保持溝通

>  3.6.8.3.1. 可以與他們定期會面，傾聽他們的意見，就像你希望他們傾聽你的意見一樣

• 3.6.8.4. 撰寫博客：考慮開設一個博客，分享你作為項目維護者的經驗

• 3.6.8.5. 擁有合適的支持，新領導者就可以成功起步

3.7. 制定繼任計劃對於項目來説是困難的，這不僅僅是因為需要做的工作很多，還因為我們必須面對終有一日會把這個工作和崗位交棒給下一個人繼續推進的現實

3.8. 雖然對於領導者及其開源項目來説，過渡給新的領導者是一種解決方法，但有時候，項目已經完成其使命和生命週期，是時候關閉它了