GitHub把下載數據藏了5年，開發者被逼自己寫了個追蹤器

GitHub上有個數字，99%的開發者從沒見過——你的二進制文件每天被下載多少次。

不是star數。不是fork數。是實實在在的下載量，有人運行過你代碼的證據。

GitHub只顯示當前累計總數，沒有歷史曲線。這意味著：你的項目可能在三個月前突然爆紅，而你永遠不會知道。開源維護者David Bernard管這叫"flying blind"——開著飛機，儀表盤是黑的。

他維護kubectl-view-allocations（一個Kubernetes資源查看工具）五年，直到去年才發現一個詭異現象：2025年12月到2026年1月，下載量毫無征兆地翻倍。沒有新版本發布，沒有官方公告，沒有任何他能追蹤到的傳播節點。"Something spread it"，他在博客里寫，"a newsletter, someone's blog post, a company's internal tooling. I have no idea what."

為什么star數是安慰劑

Bernard算過一筆賬：500個star的項目，可能只有3個真實用戶。人們收藏倉庫的理由千奇百怪——"以后可能用得上""作者名氣大""界面好看"，但收藏和運行是兩回事。

npm、crates.io、PyPI這些包管理器能告訴你庫文件（library）的下載情況，但二進制工具（binary）的發布走的是另一條通道：GitHub Releases。那里藏著大量預編譯的可執行文件，而官方不提供任何歷史趨勢。

這就導致一個荒誕的局面：你花周末寫的命令行工具被某家公司的CI系統每天調用上千次，你自己卻以為沒人用，差點放棄維護。

Bernard的另一個項目ffizer就是反面教材。新版本發布后下載量幾乎為零——這不是產品問題，是認知問題。診斷錯了，解法就全錯。

download-history：一個維護者的自救工具

解決方案簡單粗暴：每幾小時爬一次GitHub API，存成每日快照，畫成趨勢圖。Bernard把它做成在線服務download-history.cdviz.dev，輸入owner/repo就能看60天曲線。

圖表支持交互式瀏覽，也能生成靜態SVG嵌入README，每天自動更新。他放了個示例代碼：


這個工具對私有倉庫也有效，只需要提供access token。定價策略很"個人開發者"：14天免費試用，不需要信用卡，不需要注冊。之后每年5歐元，最多追蹤2個倉庫。

Bernard拿jdx/mise（一個多語言版本管理器，非他本人項目）當參考案例。這個工具發布頻率極高，每1-5天一個新版本，被CI和桌面環境持續拉取。它的下載曲線沒有明顯尖峰——因為用戶不是"升級時下載一次"，而是"每次運行都可能拉最新版"。

同樣的圖表，不同的讀法。上下文決定你怎么理解數據。

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

Bernard在文章結尾列了下一步計劃：支持GitHub Packages（容器、npm、Maven），可能拓展到GitLab。然后拋出一個開放問題："What metrics do you track for your OSS projects? I'm curious what signals actually matter to other maintainers."

這個問題背后是整個開源生態的度量困境。我們習慣了用star數證明項目健康，用貢獻者數量顯示社區活躍，但這些指標和真實采用率之間的裂縫越來越大。

一個更尖銳的版本是：當你的項目被集成進某家巨頭的內部工具鏈，卻沒有任何外部可見性時，你該怎么證明它的價值？

Bernard的工具解決的是技術層面的盲區，但更大的盲區在于——開源維護者至今沒有行業共識的"健康度指標"。下載量、活躍issue數、響應速度、依賴該項目的其他倉庫數量……每個維度都有漏洞，組合起來又過于復雜。

他的14天免費試用不需要注冊，這個設計本身就有趣。意味著你可以偷偷查任何公開項目的真實下載趨勢，包括競爭對手。開源世界的信息不對稱，正在被這種小工具一點點削平。

你在維護什么項目？如果突然能看到過去一年的下載曲線，你最想驗證哪個假設——是某個功能真的沒人用，還是某個你放棄的舊版本其實還在被大量調用？