4,800 GitHub stars ने भरोसा क्यों तोड़ा

📌 मुख्य बिंदु (TL;DR)

• एक चीनी GitHub repository में code, release और activity में कोई बदलाव बिना Star 4,000 → 4,800 तक अचानक बढ़ने का मामला सामने आया
• इसने “GitHub Star = लोकप्रियता/गुणवत्ता” जैसी मूल धारणा पर ही सवाल खड़े कर दिए
• निष्कर्ष: GitHub Star की संख्या किसी project की गुणवत्ता या विश्वसनीयता को परखने के लिए उपयुक्त metric नहीं है

---

📉 मुख्य दावे और व्यावहारिक insights

⭐ 1) लोकप्रियता को आसानी से ‘बनाया’ जा सकता है

• StarScout आधारित GitHub event log analysis के नतीजे:
  • लगभग 45 लाख से अधिक संदिग्ध Star patterns
  • इनमें से 31 लाख से अधिक को लगभग नकली Star के रूप में वर्गीकृत किया गया
  • कम समय में कई accounts द्वारा एक साथ Star देने वाला pattern बार-बार देखा गया
• यानी, Star में वृद्धि ≠ स्वाभाविक रुचि में वृद्धि — ऐसे कई मामले मौजूद हैं

व्यावहारिक नज़रिए से:
सिर्फ “आजकल trending है” कहकर dependency जोड़ना जोखिम भरा है

---

💰 2) ‘Star market’ पहले से मौजूद है

• GitHub Star अब सिर्फ रुचि दिखाने का साधन नहीं, बल्कि एक खरीदे-बेचे जाने वाले marketing asset की तरह काम करता है
• देखी गई संरचना:
  • सीधे Star बेचने वाले vendors
  • account pool का उपयोग करने वाले Star exchange networks
  • service promotion packages में शामिल Star boosting option
• नतीजा:
  • popularity metrics संरचनात्मक रूप से विकृत हो जाते हैं
  • नए projects और libraries का मूल्यांकन करते समय noise बहुत बढ़ जाता है

व्यावहारिक नज़रिए से:
Star की संख्या अधिक होने का मतलब यह नहीं कि वह “validated project” है

---

🛡 3) Star कोई ‘trust metric’ नहीं है

• Star की मूल प्रकृति:
  • ✔ visibility metric
  • ❌ trust metric नहीं
• सिर्फ Star count से नीचे की बातें नहीं जानी जा सकतीं:
  • security level
  • maintenance की स्थिति
  • code quality / technical debt
• इससे भी गंभीर समस्या:
  • नकली Star से लोकप्रियता का भ्रम पैदा करने के बाद supply chain attack में दुरुपयोग की आशंका

व्यावहारिक नज़रिए से:
ज़्यादा Star वाली library भी risk हो सकती है

---

🔎 काम की trust checklist (5 मिनट में)

Star की जगह यह देखें 👇

• activity rhythm
  • क्या commit, issue और PR लगातार और स्वाभाविक हैं
• documentation की स्थिति
  • क्या README वास्तव में उपयोग लायक स्तर का है
  • क्या installation / examples / constraints स्पष्ट हैं
• engineering hygiene
  • क्या test code मौजूद है
  • क्या CI/CD setup है
• वास्तविक adoption metrics
  • PyPI / npm / Docker pull count
  • क्या वास्तविक services में इस्तेमाल के संकेत हैं
• security posture
  • OpenSSF Scorecard, security policy, vulnerability response history
• Bus Factor
  • क्या project किसी एक व्यक्ति पर अत्यधिक निर्भर है

ऊपर के संकेतक Star count से कहीं अधिक विश्वसनीय हैं

---

📊 निष्कर्ष संदेश (व्यावहारिक सार)

• GitHub Star रुचि का संकेत है, भरोसे का नहीं
• Star count को पर्याप्त हद तक manipulate किया जा सकता है
• बहुत अधिक Star होना कुछ मामलों में warning signal भी हो सकता है
• असली भरोसा इन चीज़ों से आता है:
  • लगातार activity
  • security practices
  • documentation quality
  • community response
  • maintenance और operation structure

[kallare]

साल का अंत है... लगता है GitHub Star किसी का KPI रहा होगा।
यह Goodhart's law के काम करने का एक उदाहरण है, लेकिन मैनेजर के नज़रिए से देखें तो numbers के आधार पर मैनेज करने जितनी सुविधाजनक चीज़ और क्या है...

[cgl00]

GitHub जैसे प्लेटफ़ॉर्म में stars का काफ़ी महत्व होता है, लेकिन क्या GitHub को abusing detection में दिलचस्पी नहीं है? सिर्फ़ GeekNews में भी यह तुरंत flagged हो जाता है।

[bus710]

आसपास और SNS पर भी star request के बदले में star देने-लेने का चलन काफ़ी होता है।
व्यक्तिगत repo में सौ से ज़्यादा हों भी, तो मुझे नहीं लगता कि उसका कोई खास मतलब है।

[dohyeon5626]

Star रुचि का संकेत होता है, यानी उस repo में दिलचस्पी है और उसके updates पाना चाहेंगे...? डेवलपर के नज़रिए से रुचि का "ज़्यादा" होना बहुत कीमती होता है, इसलिए उसे अधिक महत्वपूर्ण मानने की प्रवृत्ति होती है।

[dohyeon5626]

मेरे जैसे डेवलपर के लिए तो एक star मिलना भी मुश्किल है T_T

[skageektp]

GeekNews में भी कुछ लोग likes का abuse करते हैं :'( यह abuse वाकई काफ़ी मुश्किल करने वाला है

[nullptr]

https://namu.wiki/w/…

[secret3056]

जब SK भी abuse करने लगे, तो...