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. 重要的是要仔細考慮項目當初結束的原因，並制定明確的計劃，以便在項目恢復時應對這些挑戰