我在 GitHub 黑市買「水軍」：一萬顆 star 只要 4000 多元，人人都能「一夜爆火」

作者 | 褚杏娟、核子可樂

「說實在的，我的夢想就是擁有個幾千 star 的 GitHub 項目。」有開發者說道。

雖然 GitHub star 數現在可能跟公眾號的「閱讀量」或者微博的「轉發量」一樣，是一種虛無飄渺的虛榮心指數，但不妨礙它成為開源社區中展示普遍認同的一大重要指標。項目 star 數也會影響很多重大的高風險決策，包括選擇哪些項目、為哪些初創項目注資，甚至選擇哪家企業入職等。

但是，現在人們已經不相信 star 數這個指標了。「GitHub 項目的 star 數我倒是不在乎，因為這東西太容易造假了，也代表不了項目的品質。我就不會去跟別人說給我的項目點 star 哦，這種行為在我看來真的 low 得不能再 low 了。​​」有開發者說道。

事實上，這位開發者說得並沒有錯。我們總會在 GitHub 上發現一些迅速躥紅的開源項目，剛剛開放，每周就能拿下幾百 star。真有那麼優秀嗎？似乎好得令人難以置信了。還有一些新項目剛上架幾天就 star 數猛增，這可是知名老項目在發布新版本或者其他重大公告才能擁有的待遇。

最近，開源編排平台 Dagster 分享了在抽查一部分代碼倉庫後，發現了的幾位「嫌疑人」，而在 Dagster 披露後，一些帳戶已經被刪除。

請注意帳戶創建日期，這跟正常的 GitHub 用戶明顯有所區別

買了 star 後，項目一夜爆火

Dagster 的幾位研究人員親身體驗了購買 star 給項目帶來的優越。Dagster 建立了一個虛構的代碼倉庫（frasermarlow/tap-bls）並買了一堆 star。然後，Dagster 為該帳戶設計了個人資料文件，並使用 GitHub REST API（通過 pygithub）和 GitHub Archive 資料庫展開了一系列測試。

Dagster 的代碼倉庫一夜之間就火了……

跟它一起「躥紅」的項目還有不少。

GitHub star 在哪裡可以買到呢？用不著潛入暗網，直接在谷歌上搜就能找到幾十種服務。為了觀察這些虛假 GitHub 帳戶的個人資料，Dagster 通過以下服務買了 star：

• Baddhi Shop，低成本偽造各種線上公開影響力指標的專業「服務商」。最低 64 美元，你就能買到 1000 顆 GitHub star。
• GitHub24，由 Möller und Ringauf GbR 提供的服務，價格比 Baddhi Shop 要高得多（每 star 0.85 歐元）。

有一說一，這幫傢伙還挺講「誠信經營」：Dagster 買的 star 很快就到帳了。GitHub24 在 48 小時內就交付了 100 顆 star。在此之前，Dagster 的代碼倉庫只有 3 顆 star。由於 Baddhi Shop 的價格更便宜，所以 Dagster 在這個渠道上訂購了 500 顆 star，而一周之內對方同樣成功履約。

不過，Dagster 表示「一分錢一分貨」：一個月後 GitHub24 交付的 24 顆 star 都還在，但純偽造的 Baddhi Shopstar 只剩下四分之三，那四分之一可能是被 GitHub 的完整性團隊撤掉了。

star 數，還重要嗎

「我的前僱主在他們的工作描述和招聘推介中使用了 GitHub stars。他們定期鼓勵員工去 GitHub 上為公司的存儲庫加注星標。在全體會議上，GitHub stars 是他們報告的重點工作之一：我們在 GitHub stars 中超過了 X（鼓掌）。」網友「penguin_booze」爆料道。

當 stars 數成為企業關注的重點時，壓力就給到了員工或者求職者。「能在 GitHub 上拿到三位數的 Star 的本科生至少進 BAT 毫無壓力。」有網友稱。這也導致了國內前幾年開源項目刷 star 泛濫。

當 star 造假越來越多，有些開發者在評價開源項目的時候也會越來越少地真正在意 star 數。「就我個人而言，我從不看 star 數，因為即使這是合理的，它也沒有讓我比從 repo 中看到其它更有用的東西。」網友「ziml7」說道。

ziml7 表示，「我傾向於檢查最早和最新提交之間的時間差異，這可以讓我確定這不是一個某人花了幾周時間編寫代碼、放在 GitHub 上，然後就被遺忘了的項目。我也會檢查 issues。我會尋找比正在顯示更多的、已經解決的 issues ，但我會快速瀏覽下來大致了解有多少是真正有意義的 issues 。我還從自述文件和文檔中獲得線索。如果這些 issues 存在就容易通過（檢測），但如果它們不僅存在，並且既清晰又詳細，那肯定對我的判斷會有幫助。

但 ziml7 的觀點也得到了一些質疑。網友「imadj」表示，許多維護人員只是將問題隱藏起來了，並沒有真正解決。許多人以 0 個未解決的 issues 而自豪，好像這意味著什麼。但如果他們會玩這個遊戲，那麼世界上任何軟體都可以有 0 個 issues。「因此，除非您真的精通該項目並花了一些時間關注它，否則 star 數實際上可能是判斷項目質量和聲譽的更好指標。」

另外，在評估幾個不同的 repos 以選擇特定工具工作時，一些開發者會用 star 數進行判斷。「如果其中一個 repo 有更多的 star，我在選擇時會仔細權衡。提交的新鮮度絕對重要，但對我來說，有許多人加注星標這一事實表明，這個 repo 是吸引人眼球的和活躍的。」網友「cdiamand」表示。

對於 ziml7 提出的查看日期，也有開發者表示反對：「提交日期可以任意更改。」

網友「debarshri」指出，在評估 OSS 項目時，關鍵指標是社區活動。「GitHub stars 是一個很弱的社區活動指標。首先，它可以被造假。此外，Stars 的操作門檻非常低，為該項目加星的人並不真的會使用它。」

「debarshri」認為有兩個社區活動指標非常重要：GitHub issues 和 slack/discord/discourse 評論。「在我看來，GitHub issues 的一個關鍵是，如果 GitHub issues 主要由核心團隊提出，那不是一個好兆頭。您需要來自客戶或用戶而不是團隊的大量問題。如果項目正在解決實際問題，這是一個很好的指標。Stars 操作門檻極低。鬆散的評論也一樣，它應該既有分量又有新鮮感。

無論如何，可以看出，Star 數目前在一些開發者心中依然有很重的分量。我們還無法完全拋棄這個衡量指標。但現在，大多數 GitHub 的 star 分析工具和相關討論文章都沒有解決 star 數灌水的問題。那麼，還有其它辦法嗎？

如何識別假 star？

為了搞清楚 GitHub 上的 star 造假問題有多嚴重，Dagster 與垃圾郵件和濫用專家 Alana Glassco 一起深入研究了數據模式，分析了 GitHub Archive 資料庫中的公共事件數據。

機器學習可以幫忙嗎？比如買點假 star，然後訓練分類器來識別真 star 和假 star。Dagster 表示，這種方法存在幾個問題：

• GitHub star 賣家非常小心謹慎，而且會主動迴避檢測，所以很難根據名稱、個人簡介等直觀特徵對其出做分類。
• 標記及時性。為了避免被發現，賣家會不斷調整自己的行動策略。因此，標記數據不僅難以獲得，而且就在模型訓練的過程中，這些數據內容可能就已經過時。

註：檢測工作中，經常會將機器學習與啟發式方法結合使用來識別惡意行為者，本次研究最終採用了啟發式的檢測思路。

在買下假 star 之後，這些假 star 又可以分成兩類：

• 一眼為假。賣家根本就不加掩飾，只要點開個人資料，就能馬上看出這幫給 star 的用戶根本不是真人。
• 用心造假。另一個群體則複雜得多，帳戶上有很多相當真實的活動，藉此掩蓋了其屬於假帳戶的事實。

於是，團隊最終通過兩種相互獨立的啟發式方法來識別這兩類群體。

「一看就是假的」

在調查期間，Dagster 團隊發現了很多一次性的個人資料：它們的存在就是為了偽造 GitHub 帳戶並為買家的 GitHub 代碼倉庫「加 star」。

這類帳戶只有一天的活動記錄（也就是帳戶創建當天，因此可以證明它們就是為了加 star 才存在的），別無其他。於是，Dagster 團隊使用 GitHub API 收集了這類帳戶的更多信息，並發現了它們清晰的運作模式。這類帳戶的特點就是活動量極低：

• 創建時間為 2022 年或更晚
• 關注者 <=1
• 所關注者 <= 1
• 公開 gists == 0
• 公開 repos <=4
• 電子郵件、雇用信息、簡歷、博客和 Twitter 用戶名均為空
• 投 star 日期=帳戶創建日期=帳戶更新日期

通過這種簡單的「低活動」啟發式方法，Dagster 團隊檢測到了大量可疑的虛假帳戶。這些帳戶只為同一組代碼倉庫投過 star，而且都是通過 GitHub API 來操作的。

這幫 GitHub「用戶」明顯具有共性

「用心造假」

另一類假帳戶會更難發現，他們有比較真實的操作，比如個人資料照片、簡歷和貢獻提交。相較前邊一眼就能看出來的假帳戶，這類假帳戶的情況比較複雜。那麼，應該如何做有效甄別呢？

聚類直覺

Dagster 團隊最終選擇了無監督聚類技術，相當於是為每個帳戶都構建一組特徵。

照理來說，正常用戶的特徵應該比較分散，就是說其每項特徵都比較獨特，不會遵循某個大聚類的整體趨勢。但虛假用戶的特徵則有相似性，所以在可視化之後會聚集在一起。通過這種辦法，應該能檢測出目標帳戶是否屬於可疑聚類。

舉個更容易理解的例子：假定我們關注「活動日期」，GitHub 上的大多數用戶並不會每天都有公開活動。如果某個帳戶每月有幾天會使用 GitHub，而且具體日期跟另一個帳戶完全相同，甚至連分享的活動內容都差不多，那就表明這兩個帳戶很可能是由相同的底層腳本在控制。根據這類帳戶的活動分享日期數（x 軸）和所交互的代碼倉庫總數（y 軸）可得出下圖：

這裡列出的就是 Dagster 那個「釣魚」代碼倉庫的統計結果，項目得到的 star 幾乎 100%是假的：

Dagster 針對一組已知假 star 得到的啟發圖——幾乎 100%匹配

據實驗團隊所知，Dagster 項目應該沒買過 star，所以他們用 Dagster 代碼倉庫做了對比。請注意左下角的小黃點，代表了少量誤報帳戶（誤報率=0.17%）：

針對 dagster-io 代碼倉庫的啟發圖——匹配接近 0%

最後，我們再來看看純假和純真之間的情況。這個開原始碼倉庫既有真 star，也包含大量疑似假 star，黃色部分標出了可疑的投 star 群體。

針對我們懷疑作弊的代碼倉庫製作的啟發圖——高亮顯示部分為假 star

改進聚類

雖然這項技術挺有意思，但實際表現還不足以對假帳戶做高置信度判斷，還需要再做改進。

初步通過直覺完成數據挖掘之後，Dagster 團隊又發現了另一種模式。雖然這些複雜的假帳戶都會以逼真的方式做交互，但這類假帳戶往往只跟少部分代碼倉庫互動。從本質上講，各個假帳戶似乎都屬於整體「可疑代碼倉庫」的一個子集。

遺憾的是，Dagster 團隊沒辦法直接匯總出可疑代碼倉庫的列表，因為賣家會不斷輪換新的代碼倉庫來迴避跟蹤。但 Dagster 可以使用無監督聚類技術自動識別出新的可疑代碼倉庫，再根據其是否存在、存在多少可疑交互來判斷哪些帳戶確係偽造。下面來看實驗團隊對可疑用戶判定方法：

• 首先，列出所有曾給可疑代碼倉庫投過 star 的用戶。
• 之後，根據與該組內其他用戶的高度重疊性，確定出一組潛在的可疑代碼倉庫。注意，因為這些用戶初步入選的理由是給同一個代碼倉庫投過 star，所以如果它們同樣也為另一代碼倉庫投過 star，則代表值得懷疑。（但僅僅是值得懷疑，正常情況下也存在這種廣泛的投 star 重疊，所以下面的附加步驟才格外重要！）
• 最後，要找出活動水平相對較低的帳戶，挑出其中絕大多數活動都僅僅指向之前確定的可疑代碼倉庫、且缺乏其他合法活動的帳戶，這些就是認定的假帳戶。

在對已知假 star 做這一啟發測試時，雖然計算量很大，但假帳戶的檢測效果確實很好，準確率高達 98%、召回率為 85%。那麼，這種方法在真實代碼倉庫中表現如何？

將這兩種方法結合起來，實驗團隊能夠更全面地了解給定 GitHub 代碼倉庫中的可疑投 star 和相應召回率：

腳註：受計算成本的限制，實驗團隊在 BigQuery 上進行的 GitHub Archive 分析僅限從 2022 年 1 月 1 日起的得 star。對於 GitHub Archive 分析，團隊使用了另一種略有不同的方法來識別 GitHub API 分析中的「低活動」可疑帳戶。這些帳戶與通過聚類方法識別出的其他可疑帳戶相加，就得到了疑似假 star 的總數。

如果大家也想用這樣的邏輯分析其他 GitHub 代碼倉庫，可點擊下面連結：

https://github.com/dagster-io/fake-star-detector

其中，簡單啟發式算法是用 Python 實現的，只需要一個 GitHub 帳戶加訪問令牌即可使用；無監督聚類方法則是用 dbt 項目實現的，需要 Google Cloud BigQuery 帳戶才能運行。請注意，用後者方式檢測大型代碼倉庫可能會帶來高昂的成本。

幸運的是，根據 Dagster 團隊的研究，從投入產出的情況來看，買 star 行為在 GitHub 上還不是那麼普遍，這也體現出開源社區積極向上的整體價值觀。開源社區的長期發展還需要每個開發者的努力。

參考連結：

https://dagster.io/blog/fake-stars

https://news.ycombinator.com/item?id=35207020

本文轉載來源：

https://www.infoq.cn/article/DVZzvDdxcElCRuLXTTk2