5.4萬GitHub Star 清零：開源史上最大意外損失

經常逛 Github 的人應該知道，每個專案右上角都有一個 Star 選項。雖然它的翻譯是“星星”，但將其理解為關注或點贊或許更為合適：點選即代表你對這個專案的支援與喜愛，因此許多優質開源專案長年累月下來都能獲得諸多 Star。

然而，“十年累之，毀於一旦”的悲劇，最近發生在了 HTTPie 專案身上：昨日，HTTPie 專案開發者 Jakub Roztočil 在其官方部落格釋出了一篇文章——“我們是如何失去 54k GitHub Star 的”。

1、十年共獲 54k+ Star

HTTPie，是一個開源的命令列 HTTP 工具包，提供命令列互動方式來訪問 HTTP 服務。與其它同型別專案不同之處在於：為儘可能使終端的 API 互動人性化，HTTPie 是從頭開始構建的。

自 2012 年 2 月 25 日釋出第一個公開版本開始，HTTPie 團隊就將專案託管在 GitHub 上了。Jakub Roztočil 解釋道：“當我意識到自己的 API 測試結果可能會引起開發人員社群的廣泛興趣時，GitHub 作為程式碼託管平臺，顯然是個不錯的選擇。”

事實證明，Jakub Roztočil 的選擇沒有錯：多年來，HTTPie 開發團隊對專案不斷改進，吸引了眾多開發者的使用與好評，HTTPie 也因此逐漸成為了 GitHub 上最受歡迎的 API 工具，還是 GitHub 上最受歡迎的 80 個公共儲存庫之一，Star 數高達 54k+。

Jakub Roztočil 對這一成績表示感恩：“這個不起眼的工具居然吸引瞭如此龐大的社群，真是令人難以置信，GitHub 在這之中發揮了重要作用。”

然而，就在 HTTPie 發展一切順利、即將迎來在 GitHub 上託管十週年之際，Jakub Roztočil 的一個誤操，令 HTTPie 這十年積攢的所有 Star 都憑空消失了。

Jakub Roztočil 懊惱表示：“我不小心將 HTTPie 專案的儲存庫設為私有了。”

2、54k+ Star 瞬間消失

那天，Jakub Roztočil 先是將自己的 jakubroztocil/jakubroztocil 設定為私有，即在其個人資料中隱藏了一個空的 README。隨後，他只是想以相同的操作在組織資料中也隱去一個空 README 檔案，不料卻成為了“悲劇”的開始。

不知道是否有人注意到，在 GitHub 進行配置檔案和儲存庫時，透過使用者和透過組織的命名雖有不同，但非常相似：name/name(使用者)與 name/.github.(組織)——這也就是 Jakub Roztočil 誤認為自己在另一個零 Star 的空儲存庫中的原因：“我沒有意識到命名存在不一致，所以我錯誤地選擇了私有化 httpie/httpie 而不是 httpie/.github。”

(注：httpie/httpie 是擁有 54k+ Star 的專案儲存庫，而 Jakub Roztočil 本來想隱藏的是 httpie/.github。)

或許有人會問：那將專案再公開不就好了?不錯，可問題是 GitHub 有一個“無情”的設定：一旦將儲存庫設為私有，將永久刪除其所有 Watch 和 Star。

也就是說，HTTPie 用十年積攢下來的 54k+ Star 一瞬之間就沒了。

3、聊勝於無的“確認框”

按常理來說，手機裡刪個照片都會“溫馨提醒”一下，對於這種具有較大影響的操作，GitHub 應該也會提醒吧?

“確實有一個確認框”，Jakub Roztočil 表示：“GitHub 會提醒你一句‘你將永遠失去這個儲存庫的所有 Watch 和 Star’。”

可是，這個確認框的內容一成不變：不論是對於沒有 Star、沒有內容的儲存庫，還是面對具有十年曆史、54k+ Star 的儲存庫，這個確認框都幾乎一模一樣(只有最後一行的 httpie/httpie 和 httpie/.github 不同)——這對此前剛在其個人資料中順利隱藏了一個空 README 檔案的 Jakub Roztočil 來說，確認框的提醒作用聊勝於無。

一起來對比下面兩張圖，你能區分出哪一個是空儲存庫可以安心刪除，哪一個會重置已擁有 54k+ Star 的儲存庫嗎?

Jakub Roztočil 無奈表示：“提醒內容應更結合實際，如果確認框中說‘你將失去 54k+ Star’，那我肯定會停下來。”

4、“雙標”的 GitHub

可惜，以上分析及感想均產生於在“悲劇”發生之後。

彼時尚未意識到自己錯誤的 Jakub Roztočil，在完成操作後看到組織頁面的時候，陷入了無盡的茫然：為什麼我想要隱藏的空 README 檔案還在，最受歡迎的 HTTPie 儲存庫卻不見了?

片刻之後，Jakub Roztočil 突然意識到發生了什麼，火速回到儲存庫試圖改正，可直到半小時後 GitHub 才允許：這半小時中，GitHub 忙著級聯刪除 HTTPie 這十年來所有的 Watch 和 Star。Jakub Roztočil 沮喪道：“我沒有辦法阻止這個過程，便開始發郵件給 GitHub 尋求支援，可最後也只能在 Star 數降為 0 後，再將儲存庫公開。”

事發之後，Jakub Roztočil 希望 GitHub 能利用備份幫助其恢復 HTTPie 54k+ Star 的社群，因為 GitHub 自己也曾發生過類似意外：GitHub 團隊有次不小心將 GitHub Desktop 應用儲存庫設為私有，隨後沒幾個小時就恢復了包括 Star 在內的一切，當時 GitHub 前 CEO 還特地解釋是透過資料庫備份恢復的。

但 GitHub 拒絕了 Jakub Roztočil 的請求，理由是這會導致不良影響，甚至即便 Jakub Roztočil 表示願意為此提供經濟補償，GitHub 也還是拒絕。

對此，Jakub Roztočil 總結：“GitHub 可以透過備份恢復私有再公開的儲存庫，但前提是這得是他們自己的專案，而不是社群專案。他們最多給你發條推文呼籲一下。”

5、“GitHub 難道不該提供更好的使用者體驗嗎?”

茫然過，慌亂過，無助過，也憤怒過，但最終 Jakub Roztočil 還是平靜地接受了，畢竟一切已塵埃落定，54k+ Star 回不來了。所幸許多開發者在知情後紛紛重新點選了 Star，目前 HTTPie 的 Star 數也已達 4.5k+。(GitHub 地址：)

“雖然我們的選擇有限，但至少有一些經驗教訓想與你們分享。”Jakub Roztočil 在最後如此說道。為避免其他人也發生類似“悲劇”，Jakub Roztočil 結合 HTTPie 自身官網設計，對開發者提出了兩點建議：

最佳化 UI/UX 設計：當使用者要破壞/刪除某樣東西併產生較大影響時，提醒框應該準確反映後果嚴重性。

使用軟刪除：人無完人，難免都會犯錯。就算使用硬刪除，也儘量延遲其過程。

最後，Jakub Roztočil 所講述的這段經歷，出人意料地在 Hacker News 上引起了許多開發者的共鳴。

@vaishnavsm：“我真的很喜歡這篇文章。雖然作者顯然對他們失去了他的社群並且 GitHub 沒有恢復它感到難過(老實說，所有人在類似情況下都會難受的)，但他們也在關注未來，並用他們的個人經歷作為我們所有人都可以學習的寓言。作為設計師和開發人員，我們也將根據其建議改進我們的工具包。謝謝 HTTPie，你獲得了一顆新 Star!”

@ghoomketu：“那個確認框的對比圖真的很可怕，我看了兩遍才發現最後一行不同。希望 Github 高層管理人員能儘快注意到這一點並加以改進。”

也有許多人終於在此刻爆發了對 GitHub 的不滿。

@sefrost：“GitHub 自己犯了完全相同的錯誤，卻能透過資料庫備份修復它，這確實不公平。”

@bsuvc：“當然，作者應該對此次失誤負責，但 GitHub 難道就不該提供更好的使用者體驗嗎?難道不小心私有化然後公開的儲存庫真的有必要清空其 Star 嗎?這難道是專案作者和點選 Star 的開發者們想要看到的嗎?”

那麼在你看來，GitHub 又有哪些方面需要改進呢?