GitHub星標500的項目，真實用戶只有3個

GitHub上有個項目攢了500顆星，實際活躍用戶3個。另一個項目只有50顆星，下載量卻飆到10萬。開源維護者David Bernard在2023年發現這個反常識現象時，已經 blind flying（盲目飛行）了整整兩年。

他的工具kubectl-view-allocations能查看Kubernetes資源分配，在2025年12月到2026年1月突然出現一波 unexplained spike（無法解釋的激增）。沒有新版本發布，沒有公告，沒有任何他知道的推廣。某個 newsletter、某篇博客、某家公司的內部工具鏈——傳播路徑完全不可見。

GitHub只顯示當前總下載量，不提供歷史趨勢。Stars更不靠譜：人們星標倉庫的理由可能是"以后可能用"，可能是"給作者鼓勵"，甚至只是"這個README設計得好看"。

Bernard的解決方案簡單粗暴：寫了個叫 download-history 的服務，每幾小時爬一次GitHub API，存每日快照，畫出趨勢圖。輸入 owner/repo，直接出圖。瀏覽器里能交互，也生成靜態SVG供README嵌入，每天自動更新。

開源維護者的"飛行儀表"為什么集體失靈

npm、crates.io、PyPI 這些包管理器有自己的數據面板，但只覆蓋源碼下載。如果你的項目發布的是預編譯二進制文件（pre-built binary），這些平臺完全看不到。

Bernard的另一個項目 ffizer 就是典型案例。新版本發布后下載量幾乎為零——這不是產品問題，是認知度問題。診斷不同，解法完全不同。沒有歷史數據，他可能會誤判為"功能不夠強"，然后浪費幾個月做無用功。

對比項目 jdx/mise（不是Bernard的，但他每天用） release 頻率極高，1-5天一次，用于CI和桌面環境。下載曲線平滑，不隨 release spike，因為用戶是持續拉取而非一次性安裝。

同樣的圖表，上下文不同，解讀完全不同。

download-history 支持公私倉，私倉需要 access token（訪問令牌）。14天免費試用，不用綁卡，不用注冊。之后5歐元/年，最多管2個倉庫。

數據不給你答案，但給你更好的問題

Bernard在文末列了三個自己的項目案例，構成一組完整的認知升級路徑：

kubectl-view-allocations 的 mystery spike（神秘激增）讓他意識到：傳播渠道完全不可控，但可以被觀測。ffizer 的 flatline（ flatline）讓他區分產品問題和市場問題。mise 的穩定曲線讓他理解不同使用場景的數據形態。

這三條曲線如果只看GitHub默認的"總下載數"，會合并成三個毫無意義的數字。

他的下一步計劃是接入 GitHub Packages（容器、npm、Maven），可能還有GitLab。文末拋了個問題：你追蹤哪些指標？什么信號對維護者真正重要？

這個問題沒有標準答案。有人看issue響應速度，有人看企業用戶郵件，有人看誰在會議上提到自己的項目。Bernard的選擇是先把"有沒有人真的在跑我的代碼"這個最基礎的問題解決掉。

開源世界有個長期被忽視的悖論：我們用最先進的協作工具寫代碼，卻用最原始的方式猜測用戶規模。GitHub Stars 誕生于2008年，設計理念是社交書簽，不是用戶統計。16年后，它仍然是大多數項目唯一的"成功指標"。

5歐元/年背后的定價哲學

這個定價很有意思。不是免費增值的套路，不是按量計費的企業 SaaS，而是一個剛好夠付服務器成本的數字。Bernard在另一篇文章里提過，他做工具的原則是"解決自己的問題，順便看看有沒有人需要"。

download-history 的架構也體現這個思路：polling（輪詢）GitHub API 而不是等 webhook，因為實現簡單；靜態SVG而不是動態dashboard，因為README嵌入是剛需；14天試用不用注冊，因為"試試"的 friction（摩擦）越低越好。

這些選擇都有代價。輪詢有 rate limit（速率限制），數據粒度受API更新頻率約束。靜態圖不能實時交互。但Bernard的判斷是：對大多數維護者來說，"知道趨勢存在"比"知道實時數字"重要十倍。

他的 kubectl-view-allocations 項目 spike 之后，他嘗試溯源。翻遍了Hacker News、Reddit、Twitter、幾個中文技術社區，沒有找到明顯 trigger（觸發點）。可能是某個企業的內部 newsletter，可能是某個 YouTube 視頻，可能是某個被防火墻擋住的微信群里轉發的鏈接。

這個盲區無法消除，但可以被量化。知道"有件事發生了"比"完全不知道"前進了一大步。

從"飛行儀表"到"診斷工具"

Bernard把 download-history 定位為診斷工具，不是 vanity metric（虛榮指標）生成器。ffizer 的 flatline 案例最能說明這點：如果只看 stars，項目有幾百個，感覺"還行"；一看下載趨勢，發現新版本發布后完全沒動靜，立刻意識到是 distribution（分發）環節斷了。

開源項目常見的死亡模式不是"代碼爛"，是"沒人知道代碼存在"。ffizer 的代碼質量沒有變化，但Bernard的注意力從"加功能"轉向了"找渠道"。

另一個常見誤判是把 CI 系統的自動下載當成真實用戶。某些項目的下載曲線在 release 后 spike 然后歸零，可能是被某個大廠的構建系統鏡像了。download-history 的時間粒度（幾小時一次）足夠區分"人類用戶行為"和"機器行為"的模式差異。

Bernard沒有明說，但他的案例暗示了一個更深層的問題：開源可持續性（sustainability）的討論長期被 stars 和 sponsor 數量主導，但真正的健康指標可能是"有多少人依賴你的工具完成工作"。這個指標很難偽造，也很難短期刷高。

他的5歐元/年定價，某種程度上是在篩選用戶：愿意為真實數據付費的人，通常是已經經歷過"被 stars 欺騙"階段的人。

文章最后，Bernard問讀者追蹤哪些指標。這個問題開放，沒有標準答案，也沒有他自己預設的"正確"選項。他列了自己的三個案例，展示了數據如何改變決策，然后把判斷權交給讀者。

這種結尾方式很符合他的整體風格：解決一個具體問題，展示解決過程，承認剩余的不確定性，邀請對話而非輸出結論。

開源維護者長期活在一種信息 asymmetry（不對稱）中：用戶能看到代碼，維護者看不到用戶。GitHub 的設計強化了這種不對稱，把社交信號（stars）放在顯眼位置，把使用信號（downloads）藏在 API 深處。Bernard的工具不是顛覆，是矯正——把被平臺設計扭曲的信息結構，拉回一個更合理的平衡。

他的 next step（下一步）清單很短：GitHub Packages、可能 GitLab。沒有 roadmap，沒有承諾 timeline。這種克制也是風格的一部分：做出來了再說，沒做出來不畫餅。

如果你維護一個發布二進制文件的開源項目，現在可以輸入 download-history.cdviz.dev 試試。14天后，你可能會發現自己過去幾年的"用戶增長"敘事需要重寫——就像Bernard一樣。

他在文末真正想問的，或許不是"你追蹤什么指標"，而是：當你發現 stars 和真實用戶之間那道鴻溝時，你會選擇繼續騙自己，還是開始找真正的信號？