GitHub डूब रहा है

• Microsoft द्वारा अधिग्रहण के बाद GitHub की उपलब्धता (uptime) में स्पष्ट गिरावट आई है, और आधिकारिक status page भी चिंताजनक आँकड़े दिखाती है, जबकि अनौपचारिक status page स्थिति को और गंभीर बताती है
• Copilot के अति-उपयोग और AI-जनित कम-गुणवत्ता वाले कोड (slop) की बाढ़ के कारण GitHub ऐसी स्थिति में पहुँच गया है जहाँ वह खुद को DDoS कर रहा है, और bots व नकली star economy प्लेटफ़ॉर्म की विश्वसनीयता को नुकसान पहुँचा रहे हैं
• Git एक open source distributed version control system है और GitHub के बिना भी काम करता है, इसलिए GitHub को Git के समान मानने वाली सोच से बाहर निकलना चाहिए
• Codeberg, Tangled, Gitea, GitLab, self-hosted Forgejo जैसे कई वैकल्पिक Git forge मौजूद हैं, और migration तुरंत शुरू कर देना चाहिए
• कई प्रसिद्ध developers लगातार ऐसे लेख प्रकाशित कर रहे हैं जिनमें GitHub छोड़ने की घोषणा की जा रही है, और GitHub पर निर्भरता से बाहर निकलना पूरे ecosystem की चुनौती बनकर उभरा है

---

GitHub छोड़ने की वजह

• Microsoft द्वारा अधिग्रहण के बाद GitHub की uptime और user experience खराब होने की आलोचना हुई है, और माना जाता है कि आधिकारिक uptime से अधिक खराब रुझान missing status page दिखाती है
• GitHub’s Historic Uptime chart को इस बात के प्रमाण के रूप में इस्तेमाल किया जाता है कि Microsoft द्वारा अधिग्रहण के बाद मासिक औसत uptime अस्थिर हो गई है
• Microsoft ने GitHub के अधिग्रहण के बाद Copilot से जुड़े products बढ़ाए, और GitHub ऐसी स्थिति में है कि उसे खुद availability problem update जारी करना पड़ा, क्योंकि वह “slop” से जूझ रहा है
• हाल में GitHub छोड़ने या GitHub से पहले के development तरीकों पर लौटकर देखने वाले लेख लगातार आ रहे हैं
  • Ditching GitHub - Lonami
  • Ghostty Is Leaving GitHub - Mitchell Hashimoto
  • Before GitHub - Armin Ronacher
  • From GitHub to Codeberg/Forgejo - Jonas Hietala
  • GitHub is dead, What’s next? - Alex Hyett

Git ≠ GitHub

• GitHub अब “source control” का पर्याय बन गया है, लेकिन बहुत से users अब भी यह नहीं जानते कि Git, GitHub नहीं है
• Git और GitHub एक ही चीज़ नहीं हैं, और Git की मूल तकनीक open source है तथा distributed है, इसलिए हर repository बराबर है और यह किसी central service के बिना भी काम कर सकती है
• Centralized services सामाजिक सुविधा का परिणाम हैं; GitHub मूल रूप से सिर्फ एक उपयोगी अतिरिक्त tool था, लेकिन Microsoft ने इसे महँगे बोझ में बदल दिया
• Network effect मज़बूत है, लेकिन GitHub की fake star economy का कोई मूल्य नहीं है, और यह bots तथा slop से भरा पड़ा है
• GitHub Actions अत्यधिक जटिल CI pipelines का हिस्सा है। दूसरा समाधान ढूँढना झंझट वाला हो सकता है, लेकिन यह पूछना ज़रूरी है कि क्या GitHub की स्थिरता पर भरोसा किया जा सकता है
  • GitHub Actions are killing your team
  • GitHub Actions is the weakest link
• जहाज़ डूब रहा है, इसलिए भले ही सब कुछ एक साथ migrate न किया जाए, migration process तुरंत शुरू कर देनी चाहिए

विकल्प और migration के तरीके

• सबसे नज़दीकी रास्ता किसी दूसरे centralized Git forge पर जाना है; sign up करने के बाद repository को नए upstream पर push कर देना होता है
• कुछ services migration को automate कर सकती हैं और issues import करने का support भी दे सकती हैं, लेकिन GitHub के issues को वैसे ही छोड़ देने का विकल्प भी है
• नीचे दिए गए सभी विकल्प परफ़ेक्ट नहीं हैं; उनमें एकमात्र समानता यह है कि वे GitHub नहीं हैं

• Centralized Git forge के विकल्प

  • Codeberg — एक non-profit, community-led project, और सिद्ध रिकॉर्ड वाला सुरक्षित विकल्प। यह Forgejo का प्रमुख instance है
  • Tangled — alpha-stage startup, और AT protocol integration के कारण दिलचस्प विकल्प। छोटे personal projects के लिए विचार करने लायक
  • Gitea — managed cloud Git hosting देता है, और वही मूल open source project है जिससे Codeberg/Forgejo अलग हुए
  • GitLab — enterprise-grade होने के कारण भारी और उलझाऊ, लेकिन किसी organization के decision-making के लिए उपयुक्त विकल्प हो सकता है
  • Bitbucket — recommended नहीं है, लेकिन “GitHub नहीं है” वाली श्रेणी में आता है
  • Game of Trees, Radicle, Sourcehut — अतिरिक्त विकल्प हैं, जिन पर अलग से research की ज़रूरत है

• Self-hosting

  • Organizations या individuals Git forge को self-host कर सकते हैं, और actions तथा releases भी चला सकते हैं
  • recommended self-hosting विकल्प Forgejo है
    • Forgejo instances के बीच federation पर चर्चा चल रही है, और Tangled ने भी federation पर लेख प्रकाशित किया है, लेकिन निकट भविष्य में इसके साकार होने की संभावना कम लगती है
  • अगर public collaboration चाहिए, तो Codeberg पर एक copy push करने का तरीका अपनाया जा सकता है
  • Gitea और GitLab भी self-hosting options देते हैं, लेकिन GitLab तुलनात्मक रूप से काफ़ी अधिक भारी है
  • GitHub ही नहीं, दूसरे forges भी Git से अलग हैं, इसलिए यह परखा जा सकता है कि forge के अतिरिक्त features सचमुच ज़रूरी हैं या नहीं
  • Git को केवल SSH के साथ सीधे भी इस्तेमाल किया जा सकता है

    git clone user@192.168.1.67:/path/to/repo  
    

• Collaboration का तरीका अलग मुद्दा है, लेकिन अगर Linux ईमेल mailing list के ज़रिए patches का आदान-प्रदान करते हुए maintain हो सकता है, तो सिर्फ scale के आधार पर इसे असंभव मान लेना मुश्किल है
• Centralized Git forge व्यावहारिक समझौता हो सकता है, लेकिन GitHub की तरह उसके भी ढहने की संभावना ध्यान में रखते हुए हमेशा exit plan तैयार रखना चाहिए

[kimjoin2]

जो features यह दे रहा है, उन्हें देखते हुए हैरानी होती है कि यह 99% से भी ज़्यादा काम निकालकर दे रहा है।

[GN⁺]

Hacker News की राय

• हर कोई इसका दोष Microsoft अधिग्रहण या अक्षमता पर डालना चाहता है, लेकिन GitHub द्वारा साझा किए गए आंकड़ों को देखें तो AI की वजह से GitHub पर कमिट होने वाले कोड की मात्रा 10 गुना बढ़ गई है, और उसका असर CI, Actions, code ingestion आदि पूरे सिस्टम में फैला है — यह काफी साफ दिखता है
  मूल लेखक MS Copilot जैसी अजीब चीज़ों को कारण मानता है, लेकिन यह वजह से ज़्यादा उन चीज़ों की सूची जैसा लगता है जिन्हें वह नापसंद करता है
  जबकि कमरे का असली हाथी, यानी AI से पैदा हुआ code explosion, पूरी तरह नज़रअंदाज़ किया जा रहा है

  • लेख के ग्राफ़ को देखें तो downtime का पैटर्न जनवरी 2020 से शुरू होता है
    OpenAI ने GPT-3.5 नवंबर 2022 में जारी किया था, व्यवहार में दिसंबर में, और जिस तरह के बड़े language model/agent coding की बात की जा रही है वह 2024 में जाकर सच में तेज़ हुआ, बल्कि 2025 के ज़्यादा करीब है
    तो फिर AI चर्चा शुरू होने से पहले, अधिग्रहण के बाद लगभग 4 साल की खराब availability को कैसे समझाया जाए?
  • लेख पढ़कर मेरी भी बिल्कुल यही प्रतिक्रिया थी
    Microsoft की आलोचना करना ठीक है, लेकिन कमरे के हाथी को नज़रअंदाज़ नहीं करना चाहिए
    अगर कल GitHub का एक परफेक्ट विकल्प आ भी जाए, तो वहां लाखों लाइनों का AI-generated code उसकी इंफ्रास्ट्रक्चर को बर्बाद करने से क्या रोकेगा?
    AI की वजह से centralized code hosting लगभग मरती हुई लगती है। कुछ-कुछ वैसा ही जैसा social media में हो रहा है
  • अधिग्रहण के बाद GitHub में कोई सकारात्मक बदलाव नहीं आया
    10 साल लंबा समय होता है, और अब उसका नतीजा दिख रहा है
    GitHub Actions, Copilot, और वह बदसूरत AI search जिसे बंद भी नहीं किया जा सकता। Azure पर माइग्रेशन तक
    Microsoft ने network effect को बिगाड़ने में सफलता पाई, और outages वह आख़िरी तिनका हैं जिसने ऊंट की कमर तोड़ दी
  • चाहे यह सच भी हो, Microsoft के पास पूरा cloud platform है
    उसका अपना बहुत बड़ा codebase है और लगभग 2 लाख कर्मचारी हैं
    खासकर जब उसने private repositories को free करने जैसे फैसले जानबूझकर लिए हों, तो इसे बहाना मानना मुश्किल है
  • मैं कभी-कभी कल्पना करता हूँ कि Microsoft GitHub को Azure cloud में Windows पर चला रहा है
    जब भी GitHub डाउन होता है, मैं सोचता हूँ, “शायद किसी ने वह Windows Server अपडेट कर दिया होगा जिस पर GH चल रहा है और सब कुछ reboot करना पड़ा होगा”
    मुझे 99% यकीन है कि यह सच नहीं है, लेकिन ऐसा सोचने से मन हल्का होता है और हर outage थोड़ा मज़ेदार भी लगने लगता है

• आज मैं GitHub पर एक repository देखना चाहता था
  मैंने commit history देखने के लिए “xxx commits” लिंक पर क्लिक किया, तो संदेश आया कि मैं secondary rate limit से टकरा गया हूँ और इंतज़ार करूँ
  इस नेटवर्क पर GitHub देखने वाला शायद सिर्फ़ मैं ही हूँ, और कनेक्शन भी CGN नहीं बल्कि dedicated IP है

  • साइट को ठीक से ब्राउज़ करने का एकमात्र तरीका है logged in रहकर देखना
  • मेरे साथ भी बिल्कुल यही होता है, और काफी बार होता है
  • अक्सर ऐसा होता है कि Slack में कोई वैध लिंक क्लिक करूँ तो मुझे 404 मिलता है, जबकि दूसरों के लिए वह ठीक खुलता है
  • अगर डेस्कटॉप पर हैं तो Ctrl + Shift + R से page cache refresh कर लें
    फिर पेज सामान्य रूप से लोड हो जाता है
  • यह क्लासिक tech-bro gaslighting है
    असल में यह कई सालों से rate limit नहीं बल्कि लगभग default deny जैसा है, लेकिन वे wording को वास्तविकता के मुताबिक बदलने से इनकार करते हैं

• “GitLab - enterprise-grade का मतलब है भारी-भरकम और उलझाऊ, लेकिन बॉस को प्रभावशाली दिखने वाला। अगर इसे चुनने के लिए कई मीटिंग चाहिएँ, तो यही लेना चाहिए।”
  मज़ेदार

  • हमारी कंपनी GitLab इस्तेमाल करती है और सच कहूँ तो मैं निराश हूँ
    सबसे साधारण काम करने के लिए भी UI बहुत जटिल है। उदाहरण के लिए MR approve करने के लिए एक ऐसा बटन दबाना पड़ता है जो असल में मेन्यू है, diff पढ़ना मुश्किल है, और ‘To-do list’ में पहले से merged MR भी शामिल रहते हैं। वह actionable to-do कैसे हुआ?
    merged MR के ‘To-do list’ में बने रहने की समस्या कई साल पहले रिपोर्ट हुई थी, लेकिन सुधार की रफ़्तार धीमी लगती है
    दूसरी तरफ़ Bitbucket के ख़िलाफ़ प्रतिक्रिया कुछ चौंकाती है। उसका UI बहुत सरल और स्पष्ट है, और नए लोग भी ऐसा ही महसूस करते हैं। Script Runner इस्तेमाल करें तो काफ़ी कमाल की चीज़ें की जा सकती हैं, और यह विशाल repositories को भी अच्छे से संभालता है
  • मज़ेदार तो है, लेकिन सच नहीं
    GitLab, GitHub से खास तौर पर ज़्यादा भारी या उलझाऊ नहीं है
    उसे सचमुच का enterprise-grade software भी नहीं कहूँगा। अगर वह देखना हो तो Jira या Microsoft की बनाई कोई भी चीज़ देख लें
  • मुझे भी हँसी आई
    हम self-hosted GitLab इस्तेमाल करते हैं, और मैंने उसे git तथा container registry की वजह से चुना था
    अगर आप web UI का बहुत इस्तेमाल नहीं करते, तो इंटरफ़ेस सच में उलझाऊ लग सकता है

• महीने के 5 डॉलर में एक सर्वर होस्ट किया जा सकता है और उस पर कई प्रोजेक्ट रखे जा सकते हैं
  repositories पर लाखों stars नहीं मिलेंगे, लेकिन मेरी ज़रूरतों के लिए यह पर्याप्त है और जिसे चाहूँ उसे access भी दे सकता हूँ

• मुझे समझ नहीं आ रहा कि इस ग्राफ़ को कैसे पढ़ा जाए
  एक तरफ़ यह हो सकता है कि GitHub के अधिग्रहण के कारण availability खराब हुई हो
  दूसरी तरफ़, अधिग्रहण से पहले availability का 100.00% दिखना संदिग्ध लगता है; शायद सिर्फ़ status page ज़्यादा अच्छे से अपडेट होना शुरू हुआ हो
  मुझे पता है कि हाल में GitHub availability की समस्याएँ रही हैं, लेकिन ग्राफ़ में समस्या 2020 से शुरू होती दिखती है और बहुत तेज़ी से बदतर होती नहीं लगती

• ऐसा लगता है कि बड़े open source repositories को आखिरकार चैन से छोड़ना असंभव है
  मुझे याद है कैसे SourceForge बिगड़ता गया था, और GitHub के साथ वही होता देखना सच में दुखद है
  और हाँ, मैंने URL को “dBus hell” पढ़ लिया। ऐसा सबके साथ कभी न कभी हुआ है

  • नहीं, वह dBu units पर आधारित nushell है, इसलिए dBu Shell है

• मैं अक्सर सोचता हूँ कि अगर मैं कोई कंपनी चलाता तो क्या करता
  मैं सच में देखना चाहूँगा कि अगर सारी code review email से की जाए तो कैसा रहे
  repository के लिए बस एक साधारण VPS-जैसा सर्वर काफी होगा जिसमें git-only SSH access हो, review के लिए for-review/ branch namespace हो, और CI एक ऐसा bot हो जो branch आने का इंतज़ार करे और pass/fail दिखाने के लिए ref पर comment या tag लगा दे। नतीजे email thread में reply करके भी भेजे जा सकते हैं
  mailing list के साथ web archive viewer जोड़ दिया जाए तो पुरानी reviews भी देखी जा सकती हैं। ऐसे समाधान पहले से बहुत हैं, और यह बस HTML है
  chat के लिए IRC और channel archive करने वाला bot काफी है। बहुत आसान
  पूरा सिस्टम, सिर्फ़ ज़्यादा ताकतवर hardware चाहने वाले CI runners को छोड़कर, बहुत सस्ते सर्वरों पर चल सकता है
  GitHub को software projects चलाने के लिए जितना चाहिए उससे कहीं ज़्यादा overengineer किया गया है। Linux kernel को देखें, जो साधारण mailing list इस्तेमाल करता है, और फिर भी उसे अब तक का सबसे सफल software project मानने पर बहुत कम विवाद होगा
  हालांकि issue/bug tracking थोड़ा डरावना है। क्योंकि अगर मैं उसका समाधान खुद बनाने निकलूँ, तो शायद कंपनी के असल काम से ज़्यादा उसी में फँस जाऊँ। शायद फिर bug tracking software कंपनी ही बन जाऊँ?

  • आदर्श रूप में, code review भी version controlled हो और उसका आसानी से उपलब्ध इतिहास हो
    यानी मैं देख सकूँ कि comment ठीक किस line पर जुड़ा था, वह line कब बदली, और आगे-पीछे नेविगेट कर सकूँ
    email इस डेटा के आदान-प्रदान के लिए प्रोटोकॉल के रूप में काफी हो सकता है, लेकिन email client उसे अच्छे ढंग से देखने का तरीका नहीं है
    शायद distributed code review system की भी ज़रूरत हो सकती है

• पूर्वी यूरोप में रहने के भी फायदे हैं
  time zone की वजह से बड़े GitHub outages का मुझे लगभग पता ही नहीं चलता
  free hosting और Actions को वे काफी उदारता से देते हैं, इससे भी मैं संतुष्ट हूँ

• घर के सर्वर पर Forgejo इंस्टॉल करने के बाद मैंने पीछे मुड़कर नहीं देखा
  एकमात्र समस्या तब होती है जब DigitalOcean App Platform या Vercel जैसी जगहों पर app host करनी हो, क्योंकि वे सिर्फ़ GitHub से कनेक्ट होते हैं

  • DigitalOcean App Platform सिर्फ़ GitHub नहीं बल्कि GitLab से भी deployment सपोर्ट करता है
    बस self-hosted GitLab instance नहीं, बल्कि gitlab.com hosted instance इस्तेमाल करना पड़ता है
    अगर आपने पहले ही self-hosted forge deploy कर रखा है, तो gitlab.com को पुल की तरह इस्तेमाल करके DigitalOcean App Platform से जोड़ा जा सकता है। बस एक बार gitlab.com account बना लें और अपने self-hosted forge से gitlab.com पर mirror भेजें। वास्तव में GitLab का इस्तेमाल करने की खास ज़रूरत नहीं होती
    फिर भी यह अजीब है कि DigitalOcean, जो IaaS/PaaS बेचता है, अपने ही इंफ्रास्ट्रक्चर पर चल रही self-hosted Forgejo जैसी चीज़ों से कनेक्ट होने नहीं देता
    सच तो यह है कि self-hosted forge होस्ट करना चाहने वाले लोग बहुत हैं, लेकिन उसे खुद सेटअप और ऑपरेट करना चाहने वाले कम। इसे देखते हुए यह भी अजीब है कि DigitalOcean ने Forgejo या उसके विकल्प को उठाकर सालाना 20 डॉलर जैसी भारी छूट पर semi-managed one-click deployment option नहीं दिया और App Platform integration को first-class support नहीं बनाया
  • GitHub से बचने के जितने कारण हैं, वही DigitalOcean App Platform और Vercel से बचने के कारण भी हैं
    मैं DigitalOcean इस्तेमाल करता हूँ, लेकिन सिर्फ़ VPS
    इन middle layers में vendor lock-in से बचना चाहिए, नियंत्रण अपने हाथ में रखना चाहिए, और जितना हो सके उतनी universal stack layers को लक्ष्य बनाना चाहिए
  • मेरी भी कुछ ऐसी ही स्थिति है
    मैं Forgejo fork से पहले, कई साल पहले ही Gitea पर चला गया था और कोई पछतावा नहीं है
    जब GitHub की ज़रूरत पड़ी, तो repository को वहाँ mirror करके काम चला लिया। बस code sync करना झंझट है
  • Apple का Xcode Cloud भी ऐसी ही स्थिति में है

• GitHub मुश्किल में है क्योंकि AI-assisted coding की वजह से पिछले 1 साल में commits की संख्या 14 गुना बढ़ गई है, और यह रफ़्तार अभी भी तेज़ हो रही है
  साइट के लिए इसकी बराबरी करना मुश्किल हो रहा है
  GitHub COO ने यहाँ इसकी पुष्टि की है: https://x.com/kdaigle/status/2040164759836778878
  platform activity तेज़ी से बढ़ रही है। 2025 में commits 1 अरब थे, और अब यह प्रति सप्ताह 27.5 करोड़ हैं, इसलिए अगर growth सिर्फ़ linear भी रहे तो इस साल की रफ़्तार 14 अरब तक जाती है। बेशक यह linear पर रुकने वाली नहीं है
  GitHub Actions 2023 में प्रति सप्ताह 50 करोड़ मिनट से बढ़कर 2025 में 1 अरब मिनट हो गया, और इस हफ़्ते अब तक ही 2.1 अरब मिनट हो चुके हैं
  इसलिए वे और ज़्यादा CPU, service scaling, और GitHub के core features को मज़बूत करने पर बहुत आक्रामक तरीके से काम कर रहे हैं