GitHub 並非我開源軟體的最初歸宿。SourceForge 才是。
在 GitHub 出現之前，我曾自行架設 Trac 系統。我擁有自己的 Subversion 儲存庫、票證系統、tarball 壓縮檔以及由我掌控的基礎設施上的文件。後來我將專案轉移到 Bitbucket，那時 Bitbucket 對於開源專案來說，仍是一個嚴肅的替代選項，特別是對於那些尚未完全投入 Git 的人。
最終，GitHub 成就了主流，我將所有專案都遷了過去。
我難以言喻 GitHub 在我生命中變得有多重要。我的開源身份很大一部分在那裡形成。我參與的專案在那裡找到了使用者。人們在那裡找到了我，我也在那裡找到了其他人。許多專業關係和友誼的開端，都源於某個儲存庫、某個 issue、某個 pull request 或某個討論串，讓兩個人互相認識。
這就是為什麼我對 GitHub 今日的遭遇感到如此悲傷和失望。我並不只是將其視為微軟的員工做出了我不喜歡的產品決策。GitHub 在很長一段時間裡，一直是開源社群的社會基礎設施的一部分。對我們許多人來說，它不僅僅是程式碼的存放地；它也是社群很大一部分的家。
因此，當我思考 GitHub 的衰落時，我也會想到它之前的時代，以及它之後可能出現的時代。多年來，我曾多次談論過依賴性，特別是微依賴的問題。在我看來，GitHub 催生了這種現象。這是我絕對不完全支持的，但它也讓開源變得更具包容性。GitHub 改變了開源的感覺，而後來的 npm 和其他系統改變了依賴性的感覺。將它們結合起來，我們得到了一個發布程式碼幾乎毫無阻礙、消耗程式碼幾乎毫無阻礙的世界，全球專案數量爆炸式增長。
這有許多好處。但值得記住的是，開源並非總是如此運作。
在 GitHub 之前，開源世界要小得多。並非人們關心它的數量，而是大多數人實際能依賴的專案數量。一個依賴項不僅僅是一個套件名稱。它是一個有歷史、有網站、有維護者、有發布流程、有大量摩擦，並且經常在更大社群中有一個位置的專案。你不會隨意添加依賴項，因為依賴某件事的行為通常意味著你必須了解它的來源。
這其中並非所有都是有意為之，但由於這些專案相對較大，它們也需要自帶基礎設施。小型專案可能運行在大學伺服器上，許多專案在 SourceForge 上，但較大的專案則自行運作。它們聚集在一起形成更大的集體來維持運作。
我最早的開源專案運行在我自己管理的基礎設施上。有一個 Trac 安裝、Subversion 儲存庫、tarball、文件和發布檔案，都從我自己的機器或我控制的伺服器提供。那很正常。如果你想發布軟體，你通常也會成為一個小型系統管理員。Georg 和我為我們的開源專案 Pocoo 經營了自己的集體。我們分攤伺服器成本，並共同承擔維護 Subversion 和 Trac、郵件列表等的負擔。
特別是 Subversion，讓「經營自己的開發平台」變得自然。它是中心化的：你需要一個伺服器，而且必須有人來操作它。專案有一個家，而且這個家通常是字面意義上的：一個主機名稱、一個目錄、一個 Trac 實例、一個郵件列表存檔。
當 Mercurial 和 Git 出現時，它們在哲學上是相反的。兩者都是分散式的。每個人都可以擁有完整的儲存庫。每個人都可以擁有自己的副本、自己的分支、自己的歷史。理論上，這些分散式的版本控制系統應該減少對單一中心的需要。但儘管如此，GitHub 卻成了中心。
這是現代開源的一大諷刺。分散式的版本控制系統獲勝了，然後世界標準化了一個巨大的中心化服務來託管它。
現在很容易只談論 GitHub 的失敗，目前有很多失敗，但這是不公平的：GitHub 曾是，並且將繼續是，對開源的巨大貢獻。但或許 GitHub 最被低估的貢獻是其檔案館工作：GitHub 成了一個圖書館。它成為了龐大軟體共享資產的索引，因為即使是廢棄的專案仍然可以被找到。你可以找到分支，舊的 issue 和討論都還在線上。儘管對中心化有很多抱怨，但這種中心化也創造了可發現的記憶。那裡的領導者曾非常關心讓 GitHub 即使在受到美國制裁的國家也能保持可用。
我知道替代方案是什麼樣子，因為我曾親身經歷過。我最早的一些開源專案技術上仍在 PyPI 上，但實際的套件已經消失了。元數據指向我的舊伺服器，而該伺服器早已停止提供這些文件。
這在大型平台出現之前是很正常的。個人網域過期、VPS 被關閉、開發者去世，隨之而去的還有他們付費的服務。網路曾經充滿了小型的軟體家園，其中許多已經消失了。
微依賴問題不僅僅是人們發布了非常小的套件。GitHub 和 npm 的託管基礎設施讓人感覺創建、發布、發現、安裝和依賴它們幾乎沒有成本。
在 GitHub 之前的世界裡，聲譽和長壽幾乎是必然的依賴項選擇過程的一部分，而且通常需要進行打包。我們早期有許多依賴項預設就被打包到我們自己的 Subversion 樹中，部分原因是我們甚至無法確定在我們需要時其他服務是否在線，而且在 API 時代之前，維護獲取它們的腳本非常痛苦。隱含的摩擦迫使人們進行反思，並導致了不同的開發者行為。在 npm 風格的生態系統中，套件圖譜的增長速度可能超過任何人推理它的能力。
這種思維模式產生的問題也意味著必須找到解決方案。GitHub 幫助彌補了問責制問題，並幫助解決了授權問題。一度，新湧入的開發者和合併的 pull request 留下了許多關於授權狀態的未解問題。GitHub 甚至試圖通過其服務條款來糾正這一點。
多年來的想法是，如果我要依賴某個微小套件，我至少想看到它的儲存庫。我想看看維護者是否存在，是否有 issue，是否有近期變更，是否有其他專案使用它，程式碼是否與套件聲稱的一致。GitHub 成為了提供信任的系統的一部分，最近它甚至成為了少數幾個能夠通過受信任的發布將套件發布到 npm 和其他註冊表的系統之一。
這意味著當對 GitHub 的信任受到侵蝕時，問題就不僅僅局限於原始碼託管。它影響了圍繞它形成的整個供應鏈文化。
GitHub 目前正在失去一些使其感覺不可避免的東西。也許這就是大型中心化平台的生與死：它們總會讓人失望。現在人們厭倦了不穩定、產品的頻繁變動、Copilot AI 的噪音、不明確的領導層，以及感覺該平台不再主要為使其有價值的社群設計。
顯然，GitHub 也發現自己身處代理編碼革命的中心，這給那裡的人們帶來了巨大的壓力。但該網站沒有領導層！事情能像現在這樣順利進行已經是個奇蹟。
有一段時間，離開 GitHub 感覺像是一種象徵性的舉動，主要由小型專案或對軟體自由有強烈觀點的人做出。當 Zig 轉移到 Codeberg 時，我確實皺了皺眉！但現在我看到一些真正有影響力的人正在談論離開 GitHub。最明顯的一個是 Mitchell Hashimoto，他宣布 Ghostty 將會轉移。轉移到哪裡尚不清楚，但這是一個強烈的信號。但也有其他人。Strudel 轉移到了 Codeberg，Tenacity 也是如此。他們會引起足夠的轉變嗎？可能不會，但我發現自己比一年前更頻繁地出現在非 GitHub 的屬性上。
有人可能會爭辯說這是好事：開源停止假裝一家公司應該是萬物的預設家園，這是健康的。Git 本身就是為一個擁有眾多家園的世界而設計的。
回到多個開發平台、多個伺服器、多個小型家園和多個獨立社群，將會增加去中心化，並在許多方面迫使系統適應。這可以恢復自主性，並使專案減少對微軟領導層意願的依賴。它還可以讓不同的社群選擇不同的工作流程。Pi 的 issue tracker 目前發生的情況，很大程度上是 GitHub 的產品選擇在當今的開源世界中不再適用的結果。它是為參與度而建，而不是為維護者的理智而建。
它也可以讓網路再次遺忘。我相當喜歡會遺忘的軟體，因為它有一種淨化的元素。也許實際損失的風險會讓我們更多地反思如何真正利用分散式的版本控制系統。
但如果專案轉移到更類似於自託管開發平台、自託管 Mercurial 或 cgit 伺服器的東西，我們就有失去我們不想失去的東西的風險。程式碼理論上可能是分散的，但社會背景通常不是。Issue、評論、設計討論、發布說明、安全公告和舊的 tarball 都很脆弱。它們比我們願意承認的更容易消失。郵件列表，在早年承載了其中很多內容，已經跟不上今天的需求，並且在很大程度上是一個用戶體驗的災難。
儘管我喜歡事物逐漸消失的想法，但我們絕對需要圖書館和檔案館。
無論 GitHub 是否會留存下來，或者專案是否會找到新的家園，我希望看到一個公開的、樸實的、資金充足的開源軟體檔案館。一個擁有捐贈或公共資金的力量來維持運作的機構。一個其工作不是贏得開發者生產力市場，而是確保我們創造的最重要的東西不會消失。
花哨的功能可以由別人負責，但原始碼檔案館、發布工件、元數據以及足夠的專案上下文來理解發生了什麼，應該被保存在一個不與單一公司的商業模式或領導層情緒掛鉤的地方。
GitHub 偶然成為了那個檔案館，因為它成為了開源活動的中心。一旦這不再成立，我們就不應該假設會出現某種神奇的檔案館功能，或者 GitHub 會繼續這樣運作。我們已經看到了當專案家園只是個人伺服器和良好意願時會發生什麼，我們也看到了 Google Code 和 Bitbucket 的遭遇。
我希望 GitHub 能恢復，我真的希望如此，部分原因是許多歷史記錄在那裡，而且仍在為它工作的人們繼承了真正重要的東西。但我不再認為將開源的持續記憶寄託在 GitHub 保持一個健康的產品是負責任的。
GitHub 之前的世界擁有更多的自主性和更多的損失，在某些方面，我們可能會至少暫時回到那裡。無論人們接下來想建立什麼，都應該努力保留記憶並擺脫依賴。應該更容易轉移專案，更容易鏡像它們的社會背景，更容易保存發布，並且更難讓一家公司的漂移成為所有人的文化危機。
我不想回到那個充斥著損壞的 tarball 連結和廢棄 Trac 實例的舊網路。我也不希望開源假裝過去二十年是正常或永久的。GitHub 書寫了開源史上一個了不起的篇章，如果那個篇章正在結束，下一個篇章應該從中學習，也從它之前的時代學習。
這也是一個很好的提醒，我們在那個時代對 Internet Archive 依賴了多少專案。↩