GitHub星標(biāo)500的項(xiàng)目，真實(shí)用戶只有3個(gè)

GitHub上有個(gè)項(xiàng)目攢了500顆星，實(shí)際活躍用戶3個(gè)。另一個(gè)項(xiàng)目只有50顆星，下載量卻飆到10萬。開源維護(hù)者David Bernard在2023年發(fā)現(xiàn)這個(gè)反常識(shí)現(xiàn)象時(shí)，已經(jīng) blind flying（盲目飛行）了整整兩年。

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

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

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

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

npm、crates.io、PyPI 這些包管理器有自己的數(shù)據(jù)面板，但只覆蓋源碼下載。如果你的項(xiàng)目發(fā)布的是預(yù)編譯二進(jìn)制文件（pre-built binary），這些平臺(tái)完全看不到。

Bernard的另一個(gè)項(xiàng)目 ffizer 就是典型案例。新版本發(fā)布后下載量幾乎為零——這不是產(chǎn)品問題，是認(rèn)知度問題。診斷不同，解法完全不同。沒有歷史數(shù)據(jù)，他可能會(huì)誤判為"功能不夠強(qiáng)"，然后浪費(fèi)幾個(gè)月做無用功。

對(duì)比項(xiàng)目 jdx/mise（不是Bernard的，但他每天用） release 頻率極高，1-5天一次，用于CI和桌面環(huán)境。下載曲線平滑，不隨 release spike，因?yàn)橛脩羰浅掷m(xù)拉取而非一次性安裝。

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

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

數(shù)據(jù)不給你答案，但給你更好的問題

Bernard在文末列了三個(gè)自己的項(xiàng)目案例，構(gòu)成一組完整的認(rèn)知升級(jí)路徑：

kubectl-view-allocations 的 mystery spike（神秘激增）讓他意識(shí)到：傳播渠道完全不可控，但可以被觀測。ffizer 的 flatline（ flatline）讓他區(qū)分產(chǎn)品問題和市場問題。mise 的穩(wěn)定曲線讓他理解不同使用場景的數(shù)據(jù)形態(tài)。

這三條曲線如果只看GitHub默認(rèn)的"總下載數(shù)"，會(huì)合并成三個(gè)毫無意義的數(shù)字。

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

這個(gè)問題沒有標(biāo)準(zhǔn)答案。有人看issue響應(yīng)速度，有人看企業(yè)用戶郵件，有人看誰在會(huì)議上提到自己的項(xiàng)目。Bernard的選擇是先把"有沒有人真的在跑我的代碼"這個(gè)最基礎(chǔ)的問題解決掉。

開源世界有個(gè)長期被忽視的悖論：我們用最先進(jìn)的協(xié)作工具寫代碼，卻用最原始的方式猜測用戶規(guī)模。GitHub Stars 誕生于2008年，設(shè)計(jì)理念是社交書簽，不是用戶統(tǒng)計(jì)。16年后，它仍然是大多數(shù)項(xiàng)目唯一的"成功指標(biāo)"。

5歐元/年背后的定價(jià)哲學(xué)

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

download-history 的架構(gòu)也體現(xiàn)這個(gè)思路：polling（輪詢）GitHub API 而不是等 webhook，因?yàn)閷?shí)現(xiàn)簡單；靜態(tài)SVG而不是動(dòng)態(tài)dashboard，因?yàn)镽EADME嵌入是剛需；14天試用不用注冊(cè)，因?yàn)?試試"的 friction（摩擦）越低越好。

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

他的 kubectl-view-allocations 項(xiàng)目 spike 之后，他嘗試溯源。翻遍了Hacker News、Reddit、Twitter、幾個(gè)中文技術(shù)社區(qū)，沒有找到明顯 trigger（觸發(fā)點(diǎn)）。可能是某個(gè)企業(yè)的內(nèi)部 newsletter，可能是某個(gè) YouTube 視頻，可能是某個(gè)被防火墻擋住的微信群里轉(zhuǎn)發(fā)的鏈接。

這個(gè)盲區(qū)無法消除，但可以被量化。知道"有件事發(fā)生了"比"完全不知道"前進(jìn)了一大步。

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

Bernard把 download-history 定位為診斷工具，不是 vanity metric（虛榮指標(biāo)）生成器。ffizer 的 flatline 案例最能說明這點(diǎn)：如果只看 stars，項(xiàng)目有幾百個(gè)，感覺"還行"；一看下載趨勢，發(fā)現(xiàn)新版本發(fā)布后完全沒動(dòng)靜，立刻意識(shí)到是 distribution（分發(fā)）環(huán)節(jié)斷了。

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

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

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

他的5歐元/年定價(jià)，某種程度上是在篩選用戶：愿意為真實(shí)數(shù)據(jù)付費(fèi)的人，通常是已經(jīng)經(jīng)歷過"被 stars 欺騙"階段的人。

文章最后，Bernard問讀者追蹤哪些指標(biāo)。這個(gè)問題開放，沒有標(biāo)準(zhǔn)答案，也沒有他自己預(yù)設(shè)的"正確"選項(xiàng)。他列了自己的三個(gè)案例，展示了數(shù)據(jù)如何改變決策，然后把判斷權(quán)交給讀者。

這種結(jié)尾方式很符合他的整體風(fēng)格：解決一個(gè)具體問題，展示解決過程，承認(rèn)剩余的不確定性，邀請(qǐng)對(duì)話而非輸出結(jié)論。

開源維護(hù)者長期活在一種信息 asymmetry（不對(duì)稱）中：用戶能看到代碼，維護(hù)者看不到用戶。GitHub 的設(shè)計(jì)強(qiáng)化了這種不對(duì)稱，把社交信號(hào)（stars）放在顯眼位置，把使用信號(hào)（downloads）藏在 API 深處。Bernard的工具不是顛覆，是矯正——把被平臺(tái)設(shè)計(jì)扭曲的信息結(jié)構(gòu)，拉回一個(gè)更合理的平衡。

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

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

他在文末真正想問的，或許不是"你追蹤什么指標(biāo)"，而是：當(dāng)你發(fā)現(xiàn) stars 和真實(shí)用戶之間那道鴻溝時(shí)，你會(huì)選擇繼續(xù)騙自己，還是開始找真正的信號(hào)？