TODO指南：關閉開源項目

• 2019 年 12 月 5 日
• 筆記

這些開源指南是由TODO小組與Linux基金會和更大的開源社區合作開發的。他們從從事開放源碼開發的領先公司收集最佳實踐，旨在幫助你的組織成功地實現和運行開源計劃辦公室。我們期望這些指南通過社區貢獻而發展的活文檔。 對於針對個人貢獻者訂製的指南，我們推薦GitHub的社區指南（https://opensource.guide/zh-cn/）。

本開源指南旨在為貴企業或您所在的開發團隊提供建議，以便能在需要關閉或離開不再需要的開源項目的那天有準備好的計劃。這個指南通過合理地關閉項目或將項目轉交給其他可以繼續為該項目負責的工作人員，保證貴企業以負責的態度在項目的完成周期內追尋那個項目的發展狀況。通過這樣的方式，您也可以為用戶設定合理的期望值，以確保其能長期項目對項目程式碼的依賴關係保持下去，並也可以維護貴公司作為一個參與者在這個開源項目中負責的聲譽。

本指南將幫助您在確定項目不再有用的時候，了解如何離開項目，併當你確認準備進入開始一個新項目時，如何處理原有項目中的程式碼、存儲庫、網站，wikis以及其他項目資產。

目錄

• 計劃開源項目的生命周期
• 開源項目的結束是什麼樣的
• 為什麼在您尚未開始一個開源項目時， 就要為其結束做好計劃
• 決定您何時結束、轉交或退出一個開源項目
• 如何關閉一個開源項目
• 結語
• 鳴謝

計劃開源項目的生命周期

當軟體開發人員開始設想和發展對業務重要的新型所需開源項目時，他們還應該為每個項目的計劃完成周期（從項目開始到結束）都制定明確而具體的計劃。這些計劃應該同樣被作為公司整體開源戰略的一部分來執行，並納入其監管的所有項目。

這些工作意味著可能要為將來結束一個項目，或將項目的運營轉交給另一個感興趣的用戶群體， 或者讓企業主動結束對項目的控制而做出計劃。這種計劃是企業對項目、用戶以及支援這一切的開源社區所應承擔責任中的一部分。如果項目要關閉結束或轉交，這些計劃是十分必要的，以便其他用戶能順利完成項目的結束或轉交。

為什麼生命周期計劃如此重要？

為開源項目可能的結束而進行準備計劃並不是開源項目獨享。專利軟體規劃、IT系統的硬體部署和其他各種商業決策都有類似的計劃完成周期。對於開源計劃來說，項目的計劃完成周期可能包括傳統的生命周期的評估，例如項目範圍和發展願景的概述以及對項目增長的估計，也可能包括開源特定的範疇，例如社區建設的規劃、早期用戶的使用、對用戶的回饋和貢獻的納入。

任何項目的發展速度的放緩或用戶的使用達到峰值後下降都是自然的。隨著商業計劃的改變或新技術改善的取代，即使是非常成功的開源項目，最終有可能對其創建者或用戶來說都可能不再有用。因此，為了確保最終過渡時期的順利，準備計劃必不可少。

開源項目的結束是什麼樣的

如果您的開源項目的貢獻或提交的穩定流量已經減少，這並不意味著項目已經結束。這可能僅僅意味著該項目已經成熟，已經實現了其發展目標，並且在為其用戶服務的過程中不需要太多維護或更新，這樣的結束是件好事。

而另一方面，如果項目使用人數和程式碼使用人數明顯減少，這可能表明其他人對該項目的興趣正在降低，該項目即將結束。其他可能用來判斷項目是否將會結束的相關指標可能包括，項目活動的整體水平以及用戶是否有發布問題並參與關於程式碼的問題在線討論。

需要引起注意的問題跡象

有的問題也可以表現出項目是否已經結束或者將要結束，例如在開發方向上尚未解決的分歧，或者之前參與的貢獻者不再活躍的現象，因為他們可能已經轉向其他更能迎合引起他們興趣的項目。一個明顯跡象是，其他人與您的團隊成員的觀點缺少一致性，或社區詢問是否要繼續項目，還是要結束或徹底放棄項目。另一個跡象是您的社區不再修復或更新程式碼來解決其中的漏洞。

「如果您的項目中沒有人提問，沒有人做出貢獻，似乎沒有人再使用項目，也似乎沒有人與項目的依賴再加強，如果您沒有看到人們還在使用它的其他任何跡象，這可能就是一個巨大的警示訊號。也許項目一切正常，但是需要檢查一下，觀察項目是否將要結束。」 Dr. David A. Wheeler –博士，開源專家，Linux基金會核心基礎設施計劃的兩個項目的負責人

即使使用硬數據，這些跡象也很難衡量項目狀況，因為經常對您的程式碼的訪問數據可能是通過其他應用程式的軟體包管理器間接的訪問，而不是通過直接下載。這可能使您很難確切知道您有多少用戶，但當項目按照其計劃完成生命周期發展時，您可以進行準確追蹤。

為什麼在您尚未開始一個開源項目時，就要為其結束做好計劃？

當您對您的開源項目進行規劃時，項目計劃完成的一個關鍵組成部分就是關於將來您要如何結束或轉交項目的相關準備計劃。

這是為什麼？因為如果沒有打算保護項目社區和用戶的計劃就直接退出項目，會嚴重損害組織在項目和開源社區中的聲譽。如果您管理一個開源軟體項目，請記住，其他人對這個項目的依賴和持續使用情況將取決於您的管理和行政工作。當然，貴公司可以選擇改變一個項目的方向或狀態，但是為了您的項目的用戶能夠根據他們的需求做出規劃，您的職責之一就是要將這些改變明確、快速、公開地傳達給這些用戶。在沒有將您的打算告知用戶就結束一個項目並卸除其程式碼的行為，是不負責任的行為。

維護貴公司的聲譽

您想要做的事並不是讓其他用戶陷入困境。在開源世界中，對這個問題不能掉以輕心。這並不意味著在項目尚未開始之前，您就需要詳細制定可能的結束了計劃，但高效率、開放的溝通將有利於向用戶保證，在沒有充分告知的情況下您不會放棄項目，您將努力以避免用戶被棄之不顧。此外，如果您決定自己不再參與某一項目，您可以通過構建，開發和推廣易於分支的程式碼，使您的項目能夠靈活轉交給其他人。雖然您不需要在您的計劃完成周期中公布徹底退出的計劃，但您仍然要讓用戶了解您打算順利並負責地結束或轉交項目的計劃。

尋求建立多元化的貢獻者的基礎

通過引入有新想法的人、有解決更深層次問題的能力的人以及更多關注程式碼的開發人員，您可以擁有不同程式碼貢獻者小組，這對於幫助您的項目成長來說非常重要。而如果您之後決定結束或退出項目時，這也會有所幫助。通過項目中的多元化社區，您也許會找到可能對想要維護這一項目的感興趣的社區成員，這樣可以擴大您未來進行項目轉交人員的選擇範圍。如果您決定退出一個項目，您可能更願意把它轉交給那些在意這個項目並願意延續它的人，而不是直接宣告項目結束。

這些前期的準備工作能夠建立一定的信任度，從而能夠以項目為中心，建立一個健康的生態系統和穩定的商業依賴關係，並且能夠為項目成功奠定基礎。

「當您開始您的項目時，您試圖獲得人們的信任，消除他們對加入項目和使用您的程式碼的擔憂。如果隨後說，『您好這個項目很快就會結束』，這對建立信任很不利。相反，您應該說，如果有一天，項目可能不得不結束，您將會盡全力去解決問題， 並且應該保證您不會將用戶棄之不顧。告訴他們，您會告知他們您的每一步工作的內容。在進行項目轉交時，給他們時間去適應，您還需要努力幫助完成項目轉交時可能有所幫助。「 Dr. David A. Wheeler –博士，開源專家，Linux基金會核心基礎設施計劃的兩個項目的負責人

決定您何時結束、轉交或退出一個開源項目

無論是出於什麼原因，可能最後都需要決定一個開源項目是否應該結束或轉交給另一個個體，或者貴公司是否應該停止參與該項目。這個原因可能是您的商業目標發生了變化，該項目與您的新的發展方向不再一致。或者，也可能是因為負責這個項目的關鍵人物或團隊離開了公司，又或者是因為在您最新收集的用戶數據中，用戶參與、用戶更新和用戶使用等項目績效指標正在大幅下降。也有可能是因為在關於項目未來發展的問題上，社區成員之間出現了分歧，這些使項目看起來需要做出一些改變。

分歧會影響新項目的方向

如果在社區內部，出現了關於項目的意見分歧——無論是項目的範圍，技術問題，或其他問題——您可能都需要考慮分割項目，讓對不同方面感興趣的各方可以追求完成對他們來說重要的事情。類似這樣的困境，在1991年幫助啟發了開發人員Linus Torvalds創建了Linux。Torvalds一直在對Minix進行試驗，Minix是一個由Andrew S. Tanenbaum開發的小型UNIX類作業系統內核，可用於教授大學生編碼課程。Torvalds在確定Minix擁有完全不同的範圍和發展前景之後創建了Linux，這也讓他創建了自己的獨立作業系統。

項目的範圍當然可以隨著時間而改變，並根據需要進行調整，但如果您不再需要某個項目，您可以考慮分割或轉交此項目。您甚至可以重新調整項目的用途，以便找到讓現有用戶滿意的方式，或者合併新功能來吸引新的用戶。但是，如果最終沒有人再需要您的軟體，那麼可能這個開源項目已經完成。即使它是世界上最好的軟體，如果沒有人需要這個軟體的功能，也就沒有人在意這個軟體的存在了。

「這種結果肯定會以不同的方式發生。我們可能是因為轉向了其他項目而停止使用某個項目及其程式碼，或者維護此項目的人現在正忙於處理其他事情，甚至已經離開了Facebook。也許已經沒有人再支援這個項目，甚至我們自己的應用程式都不再使用這個項目了。但有些項目基本上已經完成了使用，這就足夠了。「 Christine Abernathy – Facebook開源開發者倡導者

一線用戶的案例

對於企業用戶來說，開源項目是否應該結束的決策的影響因素很多。在軟體開發公司Autodesk 中，大約有190個開源項目由公司自身創建並正處於使用中，在這個公司，參與項目開發的人數的減少被視為一個明顯的跡象，表明項目中程式碼的巔峰時代已經過去，致使之前蓬勃發展的項目可能會進入「維持模式」。在這種模式下，不再主動維護程式碼，如果用戶有疑問，他們可能得不到回答。在這種情況下，項目的社區成員仍然可以使用它，但項目公司不再提供社區支援。

到目前為止，Facebook內部已經開發了大約400個開源項目，該公司也會對類似的使用指標進行監控追蹤，包括修補程式和維護請求，來定期審查正在進行的項目的狀況。而在Capital One中，大約有20個開源項目已經在內部啟動並進入使用中，根據公司的需要，這些項目可能會定期轉交給其他組織或結束。

如何結束一個開源項目

無論您將如何結束或轉交開源項目，您要做的最重要的措施就是每一步想法都與用戶坦誠相待。公開您的打算將有助於在您和將來的開發人員社區之間建立信任。

一旦您決定了要採取行動，您就必須決定是否結束這個項目，或將它轉交給另一個組織，或者只是退出項目，結束您的直接參与。

轉交如何是有用的

通過將項目轉交給其他希望繼續維護它的組織，您可以直接協助項目數據和其他資源的轉交。這種方法將有助於減少現有社區及其用戶的擔憂和風險。如果項目使用的是通用或標準的介面，可能更容易提取或移動嵌入式數據，或者在需要時用其他有類似介面的項目來替代。當然，這並不總是有效，因為很明顯，有一些開源項目是獨一無二的。但是，在項目計劃完成周期的早期階段，提供和使用標準化介面有助於簡化項目的轉交過程。

「最好的做法就是對項目的狀態進行具有前瞻性的、清晰的分析。如果您不再支援某個項目，或者您正在準備結束某個項目，您需要讓那些可能會接觸您的程式碼的用戶十分明確您的計劃。可能您希望這些用戶能夠看到，這個項目將不會被繼續維護，這樣新用戶就不會開始使用它，也不會在潛意識中產生期望，認為項目已經存在，您正在贊助並會開發這個項目」 Jared Smith – Capital One開源社區經理

在轉交項目時進行必要的更新

轉交項目還有一個好處，就是在最初的開發社區首次創建並維護這個項目的之後很長一段時間內，還可以繼續向其他用戶提供程式碼。當然，不僅僅是程式碼可以繼續使用。文檔、參與者許可協議（CLA）、項目存儲庫、wikis、用於項目轉交的網站以及可能需要審查和更新的一些支援性基礎架構也都可以繼續使用。項目的轉交可以通過實際的轉交程式來完成，也可以通過將主要項目和其他資源轉交給新的用戶群來完成。

還有一種方法可以代替轉交，企業可以把項目移動到一個新的託管平台，通過讓社區成員訪問一個可繼續運行項目的中介網站然後來訪問項目，而不必完全退出項目。

「轉交不會經常發生，但在過去，我們的一個項目就轉交給了另一家公司。特別要說明的是，我們只是將該項目轉交給其他公司，但對此轉交過程沒有任何硬性規定。當該項目需要在團隊之間進行轉交時，我們先在內部進行了一些調查，確認是否還有人在使用這個項目。因為我們一直致力於讓我們的開源項目被內部使用，所以，可能會有一個和我們完全不同的團隊正在使用這個項目。如果他們願意維護這個項目，那麼我們將毫不費力地將項目轉交給這個與我們不同的團隊。但這僅僅意味著項目的所有者改變了。」 Christine Abernathy – Facebook開源開發者倡導者

徹底結束一個項目

有些組織產生單純想要結束一個過時的項目，不再為該項目付出精力的想法，可能是由於從法律問題到競爭壓力的種種原因導致的。貴公司最終的選擇由您來決定。在這種情況下，程式碼其實不必被移除，而可以被歸檔，或者被設置為「只讀」狀態，此時，即使沒有您的參與，其他人仍然可以使用程式碼來進行分支，創建新的項目。此外，程式碼也可以被移動到一個為用戶進行存儲的存檔站點。

請一定要牢記非常重要的一點，貴公司不再關心管理程式碼，並不意味著項目現有的社區不再跟進。之後在您繼續採取行動時，您應該提醒社區成員，沒有您的參與，他們也可以給程式碼創建分支並按照自己的需要來使用。同時，在這個時間點，您也應該提醒那些依賴您的項目中開源程式碼的用戶，明智的做法是告訴他們非常重要的項目中的程式碼自己複製並保存下來。隨著時間的推移程式碼可能會消失，良好的備份或複製對於用戶來說至關重要。

為了確保您的所有選擇都能夠得到有效實施，逐步的退出計劃是保證一切井然有序的良好方法。這樣的計劃意味著，您需要和可能比較關注項目的用戶進行早期明確的溝通，並規劃時間線，以便那些會受到影響的用戶有足夠的時間完成其工作，並在有需要時轉移數據到其他平台。用戶需要多少時間呢？ 這個要視情況而定。最少需要六個月，甚至可能會更長。整個過程的關鍵是要給用戶設置合理的期望時間，並且要頻繁地與用戶清楚地溝通了解您的計劃。

而如果貴公司要將項目轉交給另一個團隊，則應該讓用戶能夠及時了解您正在進行的工作，以確保他們自身的利益不受侵害。

努力實現平穩過渡

當您可行的合作夥伴確定下來之後，您就可以著手退出項目，就像去處理所有即將停產的產品一樣。如果您要參與到項目轉交過程中的話，請根據開發人員的時間決定您的組織將如何參與，然後與新的個體密切合作，為順利過渡做好準備工作。請做好思想準備，實際轉交可能需要幾個月才能完成，在所有必要的準備工作都完成後，就可以將項目正式轉交給新的項目所有者了。

但是，一個可能會出現的問題是，有意接管您的舊項目的團隊並不是您所贊成繼續去運營這一項目的團隊。這種情況可能發生，而且您必須想出可行的計劃來面對處理這種情況。您將如何處理這個問題？如果您非常依賴您的程式碼，以致於您正在考慮不把這個項目轉交給一個和貴公司不同的團隊， 或者價值取向不那麼契合的團隊，那麼也許現在並不是停止參與這個項目的合適時間。如果您有這麼多的顧慮，那麼只有一個解釋，就是您不應該離開這個項目。

明確溝通的重要性

即使完成了轉交，您也要將已經轉交的，或已經結束的，或已經被重塑的項目的新方向明確地傳達給用戶，這件事仍然是您的責任。請務必公開告知那些想要繼續使用項目的開發人員和社區成員， 在新的項目運營者的管理下項目現今所處的狀態，並告知他們關於運營者將如何維護該項目的詳細資訊。請不要忘記更新您的項目網站，社交媒體溝通渠道和其他相關的社區資產，以便用戶能夠知道在哪裡可以找到已經轉交的項目，可以繼續做出貢獻並使用程式碼。

請記住將上述所有資訊傳達給下游組織和用戶，包括企業、非盈利組織、其他使用您的程式碼的用戶，以及那些因為沒有直接參与到開發周期中而可能不知道項目結束或轉交的人。您應該通過您的網站、社交媒體渠道和其他渠道儘力告知這些人，尤其是在項目眾所周知並且有大量粉絲的情況下。

「最重要的是要儘快告知社區成員項目的變化和之後的計劃。不要讓用戶去猜測該項目是否仍在維護中。在我看來，在 大多數情況下，好的程式碼仍然存在。所以如果您的項目有很好的程式碼，我可能寧願設定預期說『不必積極維護』，也不願從GitHub上撤下某些項目。『」 Guy Martin – Autodesk開源主管

通過項目存儲庫提供更新

發布關於項目變化資訊的另一個重要地點是GitHub上的項目自己的存儲庫或其他相關位置。在這裡，您可以通過放置詳細的注釋來解釋發生了什麼，包括用自述文件向項目參與者發送資訊以便了解情況。

隨著項目的進行，如果必要的話，您就可以將各項資產正式轉交給新的運營者了。如果在維護現有公司實際資產的過程中，您引入了新的管理人員，那麼您將可以保留因為項目變化而受到影響的程式碼的版權，並讓他們通過開源許可證來使用其所選擇的程式碼。

為了保持項目存儲庫的井然有序，您可以考慮設置一個特定區域，在此區域中存儲並提供貴公司不再支援的所有已轉交的開源項目（例如https://github.com/twitter-archive）。通過這種方式，用戶仍然可以從項目中獲取程式碼的使用權，潛在用戶也可以找到說明項目狀態的自述文件。這個存儲庫的特定區域可以為用戶提供清晰的解釋內容，幫助他們理解活躍項目和已結束項目之間的差異，同時也可以確保企業能夠在活躍的存儲庫中適當地展示其最新的開源項目。

歸檔的技巧

在歸檔項目過程中涉及幾個步驟。例如，不需要更改任何URL，僅僅將項目變成只讀狀態將有利於清楚地說明，現在該項目已經歸檔，不再像以前那樣可以定期更新。

同樣重要的一點是，要為用戶提供他們的項目的一個明確可行的備選計劃，包括如何獲取程式碼和為程式碼創建分支以便繼續使用。作為您責任的一部分，您應該向用戶提供您的聯繫方式，以便他們能夠將其所創建的分支列出並提供給其他感興趣的用戶。一些公司會提供這種幫助，而其他公司則不會提供。

一旦項目存儲庫被歸檔，您將無法添加或刪除您的合作者或團隊成員，並且其中的問題會變成只讀狀態。如果想要在已經歸檔的存儲庫中進行更改，首先您必須對存儲庫進行解檔。如果您想了解更多相關的詳細資訊，請參閱GitHub中的相關文檔：https://help.github.com/articles/about-ar- chiving-repositories/。

在結束項目時更新基礎架構

結束項目也會影響您的項目的基礎架構和支援，這種影響取決於項目是如何設置的，並且必須根據具體情況進行判斷。有些項目只使用和維護一小部分程式碼，所以結束這些項目可能不需要做太多的工作。如果項目包含了全部程式碼，並且已經被發布在您的存儲庫中，那麼您可能已經完成了所有工作，而不需要再採取其他行動再來轉交或維護項目。

但是，對其他項目來說，可能需要使用各種後台工具來完成工作，所以結束這些項目需要付出相當大的努力。這些後台工具可能包括那些基於各種不同動機而被共享的服務，例如用於測試的基礎架構。雖然之前這一測試基礎架構已用於某個項目中，但您可能希望在轉移程式碼之前將這一基礎架構解離出來，以便您可以將此工具用在之後其他程式碼的測試中。這一工具可能很難從項目中解離出來，但如果您十分需求的話，這個想法是可以實現的。

「公司的確需要在開放源程式碼方面做出更好的準備計劃。如果沒有適當的計劃就把項目扔在那裡，讓公司以外的人成為貢獻者，然後就期待項目可以按照這樣的方式永遠運作下去，這將會是一個巨大的挑戰。您需要做好準備，無論社區成員是來自公司還是來自其他地方，他們會進入項目並會遵循計劃完成周期，最終，他們會成為資深成員或退出社區，所以您需要為此做好準備計劃。「 Guy Martin – Autodesk開源主管

要有強韌的承受能力

對您的行為，公眾可能會產生一些負面的評論和反應，包括不滿的用戶或那些會抨擊說您的離開是拋棄用戶的行為的「魔鬼」。然而請記住，大多數用戶都會意識到，事情的優先順序會隨著時間而變化，企業可能最終都不得不關閉一些開源項目，因為這些項目成果已經成熟。有時每個公司都必須這樣做，所以不要太在意這些評論。

結語

結束，轉交或退出一個開源項目是貴公司在某個時間點應該要採取並且不可避免的一步，但這並不一定會減少項目的影響力。對於所有相關人員來說，通過正確的計劃、明確和廣泛的溝通以及法律和程式性任務的逐步完成，開源項目的過渡目標是可以圓滿完成的。

即使您剛剛開始為一個新項目規劃第一步，但現在就提出並準備結束一個開源項目的簡單計劃， 也能確保您可以制定出一個合理的任務完成周期管理計劃。這些計劃將有助於讓您的開源項目從目標高遠的開始到最終平穩結束的整個過程中，高效並成功地運作。

鳴謝

貢獻者：

• Chris Aniszczyk，雲原生計算基金會首席運營官
• Christine Abernathy，Facebook開源開發者倡導者
• Guy Martin，Autodesk開源負責人
• Jared Smith，Capital One開源社區經理
• Dr. David A. Wheeler，開源專家，Linux基金會核心基礎設施計劃的兩個項目的負責人

這些資源是與TODO（公開對話，開放式開發）小組 – Linux基金會的專業開源程式網路小組合作創建的。 特別感謝那些貢獻自己的時間和知識來製作這些綜合指南的開源項目經理。 參與的公司包括Autodesk，Comcast，Dropbox，Facebook，Google，Intel，Microsoft，Netflix，Oath（Yahoo + AOL），Red Hat，Salesforce和Samsung。 要了解更多資訊，請訪問：todogroup.org。 我們邀請您在GitHub上下載或參與這些指南。所有內容使用CC-BY-SA 4.0授權。