1. 開源項目的落幕

1.1. 開源項目都始于良好的意愿：有一個需要解決的問題，有一位熱情積極的維護者，以及眾多涌入該項目并提供反饋的用戶和貢獻者

1.2. 用開源許可證發布代碼是永久不可逆的操作，但擁有開源項目則并非如此

1.3. 開源項目生命周期的末端是持續

• 1.3.1. 代表項目接下來進入了長期維護狀態

• 1.3.2. 雖然項目仍有用戶，但它在整體上已經是個功能完整的成熟項目了，后續任何的變更和增加都只是聚焦于修復漏洞和解決安全問題

1.4. “持續”階段項目的社群開始衰退，并轉向其他正在積極開發或更適合他們需求的解決方案

• 1.4.1. 這會產生連鎖反應，隨著用戶離開，貢獻者也會離開，最后維護者也離開了項目，久而久之就沒有人主動維護了

• 1.4.2. 項目生命周期的下一步—落幕

1.5. 項目落幕也不見得是一件壞事

• 1.5.1. 開源社群往往資源有限，因此讓項目社群聚集到一起有助于發展一個更強健的項目，并避免冗余

1.6. 開源項目的落幕意味著減少或終止該項目的開發和維護工作

• 1.6.1. 原因可能很多，包括缺乏資金、開發者不再感興趣，或是項目目標已經實現

1.7. 結束一個開源項目可能是一個艱難的決定，項目維護者必須清楚地傳達這一決定，并指導用戶遷移到其他解決方案

• 1.7.1. 為了確保資源的有效利用和項目的傳承，結束項目也可能是必要的

1.8. 結束一個開源項目并不等同于開源項目的失敗

• 1.8.1. 即使項目被結束，也不意味著它對未來沒有影響

2. 如何判斷一個項目正在放緩

2.1. 一個開源項目是進入維護狀態，還是真的要走向落幕，這當中的區別往往很微妙，并且通常與項目投入的支持直接相關

2.2. 開源項目具有多重維度，不僅需要強大的社群支持，還需要明確的使用案例和對項目的持續投資

2.3. 在這個可持續性循環中，每個環節都必須正常運作，以維持整個循環的運轉

2.4. 項目—當代碼速度和社群參與度下降

• 2.4.1. 項目衰落的顯著跡象之一是代碼速度（代碼貢獻的數量和頻率）和社群參與度的顯著下降

• 2.4.2. 如果項目的用戶和貢獻者社群衰落到活躍參與者所剩無幾的地步，那么維持項目的開發和維護可能會變得困難

• 2.4.3. 如果項目創始開發者失去興趣或轉向其他項目，尋找愿意且有能力接手的新維護者會變得更加困難

• 2.4.4. 一旦項目已經實現了既定目標或完成了預定的任務，繼續開發的需求可能就不存在了

• 2.4.5. OpenOffice是一個因社群衰落而走向落幕的經典案例

• 2.4.5.1. 當項目發生分支而未能合并回原項目時，通常會有一個分支因為資源不足而無法繼續

• 2.4.5.2. 隨著社群的精力有效轉移至LibreOffice上，OpenOffice就變成了落幕的首選項目

2.5. 產品—處于正在衰落的技術領域

• 2.5.1. Palm Pilot這個個人數字助理(Personal Digital Assistant，PDA)

• 2.5.2. 當一個項目依賴于過時技術或與新的平臺或系統不再兼容時，結束該項目并啟動一個新項目可能是更合理的選擇

• 2.5.3. Camino Web瀏覽器就是這樣的一個例子，盡管它采用了與Mozilla Firefox相同的Gecko渲染引擎，但它在用戶界面上使用了Mac原生的Cocoa API，實現了與Mac OS X早期版本的Aqua桌面環境的無縫融合

• 2.5.4. MeeGo：一個由諾基亞和英特爾共同開發的開源操作系統，面向移動設備和平板電腦，但隨著iOS和安卓操作系統在移動市場主導地位的確立，MeeGo的關注度逐漸下降，最終在2011年落幕

• 2.5.5. Google Wave：一個旨在將電子郵件、即時消息和文檔協作合并為一體的開源協作平臺，盡管起初備受歡迎，但隨著時間的推移，人們對Google Wave的興趣逐漸下降，項目于2012年落幕

2.6. 利潤—資金和投資枯竭

• 2.6.1. 開源項目通常依賴于捐款或資助來支持其開發和維護

• 2.6.2. 資金可能是直接的現金支持，也可能包括提供開發者和工程資源、市場支持，以及硬件和合作基礎設施等

• 2.6.3. 一旦資金來源枯竭，維持項目的難度將大大增加，有時甚至寸步難行

• 2.6.4. OpenSolaris

• 2.6.4.1. 停止開發OpenSolaris的決定引發了爭議，并因此形成了幾個由社群驅動的項目，以繼續開發代碼倉庫，如Illumos和OpenIndiana項目

• 2.6.4.2. 盡管做出了這些努力，但OpenSolaris項目還是走到了終點

• 2.6.5. 項目資金和投資的枯竭通常是市場環境變化的結果

• 2.6.6. CyanogenMod是一個例子，這款流行的開源操作系統為安卓智能手機和平板電腦提供了標準安卓操作系統所不具備的額外特性和定制化選項

• 2.6.6.1. 隨著CyanogenMod的關閉，曾支持該項目的開發者和用戶社群轉而開發名為LineageOS的新的開源安卓操作系統

• 2.6.6.2. LineageOS繼承了CyanogenMod的核心理念，旨在提供類似的功能和定制選項，同時堅持完全開源和社群驅動的原則

• 2.6.6.3. 今天，LineageOS已廣泛受到安卓愛好者和開發者的歡迎，并持續從其貢獻者社群獲得更新和改進

3. 結束項目的流程

3.1. 對于社群來說，結束一個開源項目是一個艱難的決定，需要社群中所有活躍的參與者共同參與，從維護者到最終用戶

3.2. 確保每個人都同意這是一個正確的決定

3.3. 在社群中就項目落幕達成一致

• 3.3.1. 當項目有一個開發者社群時，將這些開發者納入決策過程，并鼓勵他們承擔維護現有項目或創建新的分支項目的責任變得至關重要

• 3.3.2. 有助于確保投入項目中的知識和專業技術不會流失

• 3.3.3. 有時候，社群規模縮小到一定程度，反而能讓項目落幕共識的達成變得簡單

• 3.3.4. 落幕的過程并非總是順暢的，特別是當存在利益沖突或開發者對其工作或項目本身有強烈個人情感時

• 3.3.5. 在結束一個開源項目時，如果不全面考慮商業利益、社群利益及其對周圍社群的廣泛影響，就會面臨各種挑戰

3.4. 宣布項目落幕的意向

• 3.4.1. 當項目即將結束時，項目維護者必須向社群傳達這個決定

• 3.4.2. 盡早通知：一旦決定結束項目，就應立即向最終用戶發送通知

• 3.4.2.1. 將給他們充足的時間來計劃過渡和尋找替代方案

• 3.4.3. 清晰地溝通：在與最終用戶溝通時，重要的是要清楚透明地說明項目結束的原因以及他們對未來幾個月的預期

• 3.4.3.1. 定期提供最新信息并回答最終用戶提出的任何問題或疑慮也是很好的做法

• 3.4.3.2. 項目可能無法考慮到項目結束對社群產生的所有影響，而能夠解決這些問題將有助于使整個過程順利進行

• 3.4.4. Firebug在宣布結束項目的意向時就做得很好

3.5. 幫助最終用戶過渡

• 3.5.1. 以Firebug項目為例，通知社群落幕意向的一部分工作是提供指導，告訴他們如何繼續使用該項目或遷移到替代解決方案

• 3.5.2. 一旦代碼以開源許可證發布，那就是一個永久不可逆的行為

• 3.5.2.1. 通常最終用戶會希望轉移到另一種解決方案

• 3.5.3. 提供替代方案：隨著落幕過程的推進，應該與最終用戶一起確定他們有哪些可用的其他替代方案

• 3.5.4. 提供遷移支持：根據項目的復雜程度，最終用戶將其數據和工作流程遷移到新解決方案的過程中可能需要一定支持

• 3.5.4.1. 可以與他們合作，提供文檔、工具和資源來幫助他們順利完成這個過程

4. 項目結束后的步驟

4.1. 一旦項目決定落幕，就需要在停運項目時做一些工作

4.2. 項目結束后，必須明確地表明該項目不再進行維護，并確保項目資產有一個長期的歸宿

4.3. 將代碼倉庫和問題跟蹤器標記為歸檔狀態

• 4.3.1. 項目一旦結束，明確項目的狀態至關重要

• 4.3.2. 涉及將項目的代碼和文檔存放在公共倉庫中，以便用戶和開發者未來仍能訪問

• 4.3.2.1. 如果該項目對開源社群有重大影響，這點尤其重要

• 4.3.3. 在倉庫的README文件中添加通知：README文件通常是用戶和貢獻者訪問項目代碼倉庫時首先看到的內容

• 4.3.3.1. 可以在README文件中添加一則通知，說明該項目不再處于積極開發或維護狀態，有助于防止混淆

• 4.3.4. 使用“已棄用”或“已歸檔”標簽：許多代碼托管平臺（如GitHub）允許項目使用標簽標記倉庫，使用“已棄用”或“已歸檔”等標簽可以清晰地表明項目不再處于積極維護狀態

• 4.3.5. 在倉庫描述中添加說明：在倉庫的描述中添加說明，表示該項目已不再處于積極開發或維護狀態，有助于幫助防止混淆

• 4.3.6. 考慮將用戶重定向到替代方案：如果用戶可以使用其他開源項目來代替你的項目，可以考慮在倉庫的README文件或其他文檔中添加指向那些項目的鏈接

• 4.3.6.1. 可以幫助用戶找到滿足其需求的替代解決方案

4.4. 項目應確保任何相關的工具或服務都要關閉

• 4.4.1. 如果項目有關聯的服務，如網站、社交媒體賬號或論壇，確保將它們停用或重定向到替代方案

• 4.4.2. 如果項目獲得了資金支持，請關閉與資助相關的賬戶和渠道

• 4.4.2.1. 如果還有剩余資金，可考慮將其捐贈給推薦最終用戶遷移的某個項目

4.5. 為資產所有權找到歸宿

• 4.5.1. 開源項目通常有兩類資產：代碼和文檔，以及項目名稱和標志（統稱為標記）?

• 4.5.2. 對于代碼和文檔，許多開源代碼托管平臺都有針對開源項目的歸檔程序和政策，GitHub的歸檔程序就是一個很好的例子

• 4.5.3. 要想獲得更全面的解決方案，有一些組織可以作為中立的第三方來保護開源項目的商標，包括軟件自由保護協會(Software Freedom Conservancy)、自由軟件基金會(Free Software Foundation)、Linux基金會(Linux Foundation)和開放源代碼促進會(Open Source Initiative)

• 4.5.4. 當一個開源項目結束時，關鍵是要確保該項目相關的商標能按照項目目標和價值進行管理，上述組織都是行業公認的開源項目管理機構

• 4.5.5. 它們還可以管理網站的托管和代碼倉庫的憑證，防止無法聯系到最后的維護者

• 4.5.6. 將商標轉讓給中立的第三方，可以確保商標的使用不會違背項目的開源原則，也不會損害項目的聲譽或遺產

• 4.5.7. 開源項目結束后，處理資產的目標應該是確保該作品得以長期保留，以供未來使用，并確保用戶和貢獻者了解項目的狀況以及可能存在的任何替代解決方案

• 4.5.8. 盡管落幕是開源項目生命周期的最后階段，但這并不必然代表它已走到盡頭

5. 開源項目在結束之后仍可恢復

5.1. 取決于項目最初被終止的原因

• 5.1.1. 如果該項目是由于缺乏資金或開發者失去興趣而結束，那么可能會有新的資金或開發者出現并恢復該項目

• 5.1.2. 項目可能會被其他開發者或組織分支，希望使用新的名稱或添加新功能以繼續開發

• 5.1.2.1. 這可能會促成一個新的社群，并吸引新的貢獻者和用戶加入

5.2. 兩條路徑

• 5.2.1. 將項目移交給新的維護者，由其繼續開發和維護

• 5.2.2. 對項目進行分支，創建一個可以繼續發展并滿足用戶需求的新項目

5.3. 恢復一個已結束的項目可能很有挑戰，特別是在原項目擁有龐大而活躍的用戶群并已轉向其他解決方案的情況下

• 5.3.1. 新項目必須向社群展示其價值和相關性，而且可能需要時間來重建勢頭和吸引新的貢獻者

5.4. 重要的是要仔細考慮項目當初結束的原因，并制定明確的計劃，以便在項目恢復時應對這些挑戰