Ghostty GitHub छोड़ रहा है

 (mitchellh.com)
5 पॉइंट द्वारा GN⁺ 2026-04-29 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • बार-बार होने वाली GitHub आउटेज अब PR review और रोज़मर्रा के काम को सचमुच रोकने की स्थिति तक पहुँच गई हैं, जिससे यह साफ़ हुआ कि सिर्फ़ distributed Git repository होने से issues·PR·Actions पर निर्भरता की समस्या हल नहीं होती
  • पिछले एक महीने में लगभग हर दिन GitHub की समस्याओं ने काम को प्रभावित किया, और लेख लिखे जाने वाले दिन भी GitHub Actions आउटेज के कारण लगभग 2 घंटे तक PR review रुका रहा
  • माइग्रेशन कहाँ होगा यह अभी तय नहीं है, और commercial services तथा FOSS providers कई जगहों की समीक्षा करते हुए GitHub पर निर्भरता को धीरे-धीरे कम करने की योजना है
  • मौजूदा URL पर read-only mirror छोड़ दिया जाएगा, और यह बदलाव फिलहाल सिर्फ़ Ghostty पर लागू होगा; अन्य व्यक्तिगत प्रोजेक्ट अभी कुछ समय तक GitHub पर ही रहेंगे
  • यह फ़ैसला 27 अप्रैल 2026 की बड़ी आउटेज के जवाब में जल्दबाज़ी में नहीं लिया गया, बल्कि इस पर कई महीनों से चर्चा चल रही थी, और वापसी तभी संभव होगी जब वास्तविक सुधार दिखे, सिर्फ़ वादों पर नहीं

पृष्ठभूमि

  • Ghostty ने GitHub छोड़ने का फ़ैसला किया है, क्योंकि हाल की बार-बार की आउटेज अब वास्तविक काम को रोकने लगी हैं
  • पिछले एक महीने में किन-किन दिनों GitHub आउटेज ने काम को प्रभावित किया, इसका अलग से रिकॉर्ड रखा गया, और बताया गया कि लगभग हर दिन समस्या बनी रही
  • लेख लिखे जाने वाले दिन भी GitHub Actions आउटेज के कारण लगभग 2 घंटे तक PR review नहीं हो सका
  • issues, PRs, Actions जैसी आस-पास की infrastructure ही समस्या का केंद्र हैं, और सिर्फ़ Git के distributed होने से यह हल नहीं होता
  • जब रोज़ कई-कई घंटों तक काम रुकने लगे, तो इसे अब गंभीर कार्यस्थल मानना मुश्किल हो गया

योजना और दायरा

  • Ghostty कहाँ माइग्रेट करेगा यह अभी तय नहीं है, और commercial services तथा FOSS providers कई विकल्पों के साथ बातचीत जारी है
  • GitHub पर निर्भरता को एक बार में नहीं, बल्कि धीरे-धीरे हटाने की योजना है
  • मौजूदा URL पर GitHub में read-only mirror बनाए रखने की योजना है
  • यह बदलाव फिलहाल सिर्फ़ Ghostty पर लागू होगा, जबकि व्यक्तिगत प्रोजेक्ट और अन्य काम अभी कुछ समय तक GitHub पर ही रहेंगे
  • क्योंकि Ghostty वही प्रोजेक्ट है जिसका असर लेखक, maintainers और open source community पर सबसे अधिक पड़ता है, इसलिए बदलाव का फोकस भी इसी पर है

अतिरिक्त संदर्भ

  • 27 अप्रैल 2026 की बड़ी आउटेज के साथ समय भले मिला हो, लेकिन GitHub छोड़ने की योजना पर कई महीनों से चर्चा चल रही थी, और अंतिम फ़ैसला सिर्फ़ इसी हफ़्ते लिया गया
  • मुख्य लेख बड़े Elasticsearch आउटेज से पहले लिखा गया था, और उस दिन जिस आउटेज का ज़िक्र किया गया, वह उससे अलग आउटेज थी
  • अगर GitHub वास्तव में सुधरता है तो कभी वापसी संभव हो सकती है, लेकिन वापसी की शर्त बातें या वादे नहीं, बल्कि ठोस नतीजे और सुधार होंगे

संबंधित पढ़ाई

3 टिप्पणियां

 
carnoxen 2026-04-29

जो लोग पहले ही कहीं और (जैसे Codeberg आदि) जा चुके हैं, वे शायद इस पूरे घटनाक्रम को देखकर और भी पक्का महसूस कर रहे होंगे कि वहाँ जाना सही फैसला था।
 
xguru 2026-04-29

Mitchell Hashimoto ने HN कमेंट में भी लिखा कि उनकी सच में आंखें भर आईं, तो मैंने देखा
https://x.com/mitchellh/status/2049213597419774026
वह GitHub user 1299 हैं और उन्होंने फ़रवरी 2008 में साइन अप किया था।

लगता है आजकल GitHub में सचमुच काफी समस्याएं हैं। कुछ घंटे पहले भी GitHub में इस समय outage चल रहा है पोस्ट हुआ था।
 
GN⁺ 2026-04-29
Hacker News की राय

  • mitchellh: यह लिखते हुए मैं सचमुच रो पड़ा, और यह कोई बढ़ा-चढ़ाकर कही बात नहीं है
    GitHub मेरे लिए सिर्फ एक SaaS नहीं था, उसका मतलब उससे कहीं बड़ा था, और इसी वजह से मेरा उससे रिश्ता शायद कुछ ज़्यादा ही गहरा हो गया था
    हम कई महीनों से बीच-बीच में इस बारे में बात कर रहे थे, लेकिन पिछले कुछ हफ्तों में गंभीर चर्चा हुई, कुछ दिन पहले अंतिम फैसला लिया, और अब खुद यह पोस्ट प्रकाशित करके ही यह बात सचमुच बहुत वास्तविक लग रही है
    कोई इस पर हँस सकता है, लेकिन मैं GitHub की सच में परवाह करता हूँ और चाहता हूँ कि वह फिर से सही रास्ता पाए

    • भावनाएँ महसूस करना ठीक है, और मुझे भी कुछ ऐसा ही लगता है
      मैं GitHub User 22723 हूँ, और यह सोचकर कि अब शायद करीब 18 करोड़ अकाउंट हैं, हम लगभग शुरुआत से ही इसके साथ रहे हैं
      मेरी नज़र में GitHub तभी बेहतर हो सकता है जब जो लोग इसकी परवाह करते हैं वे टिके रहें और इसे बेहतर बनाते रहें
      जब मैंने लगभग 6 साल पहले Heroku छोड़ा, तब मैं उसे करीब 10 साल तक संतोष के साथ इस्तेमाल कर चुका था और फिर कभी डैशबोर्ड नहीं खोला, क्योंकि मुझे लगा कि Salesforce ने उसे सचमुच बर्बाद कर दिया
      लेकिन GitHub को मैं उस तरह नहीं छोड़ पा रहा हूँ
      agentic coding और विस्फोटक वृद्धि, दोनों एक साथ आने से चीज़ें बिखरी हुई ज़रूर लगती हैं, लेकिन यह Heroku/Salesforce जैसी पूर्ण तबाही नहीं लगती
      इसे सिर्फ और ज़्यादा AI coding या किसी दुष्ट Microsoft से समझाने के बजाय, ज़्यादा संभव यह लगता है कि पैमाना और डेवलपर्स के पैरों के नीचे की ज़मीन ही बदल गई है
      उम्मीद है यह इतना अच्छा करेगा कि कभी वापस लौटने का मन हो, और डेवलपर जीवन के केंद्र में मौजूद किसी चीज़ के लिए गहरी भावना रखना बिल्कुल भी मूर्खता नहीं है
    • आपकी हताशा साफ महसूस होती है, और उसे व्यक्त करना बिल्कुल भी ज़्यादा नहीं है
      काम करने की कोशिश करते हुए रोके जाने का एहसास, software deploy करना चाहो और सेवा खुद जैसे उसे नहीं चाहती हो, यह बात खास तौर पर बहुत relatable लगती है
      यह भावना सिर्फ GitHub तक सीमित नहीं है; आजकल पूरा वेब ही ज़्यादा ढीला-ढाला और low-quality होता जा रहा है
      लगातार outages, bugs, UI की छोटी-छोटी चुभनें, अधूरी features इतनी ज़्यादा हैं कि समझ नहीं आता आखिर हो क्या रहा है
    • अगर कोई भावनाएँ महसूस करने पर हँसता है, तो शुरू से ही उसकी बात सुनने की ज़रूरत नहीं है
      लोगों के लिए ergonomic software बनाने के लिए धन्यवाद
    • Spool of Wire Guy meme इस भावना को बिल्कुल सही तरह समझाता है
      दूसरों को चाहे वह तुच्छ लगे, लेकिन जिस व्यक्ति का वह है उसके लिए वह लंबे समय की मोहब्बत और यादों से भरी चीज़ होती है
      https://knowyourmeme.com/memes/spool-of-wire-guy
    • यह बिल्कुल भी अतिशयोक्ति नहीं है
      जीवन में कुछ चीज़ें ऐसी होती हैं जिन्हें हम पसंद करते हैं, प्यार करते हैं, और जब वह पक्ष जिससे हम जुड़े थे बिगड़ने लगता है तो दुख होना स्वाभाविक है
      मैं भी इस वजह से कभी मज़ाक नहीं उड़ाऊँगा, और जो ऐसा करते हैं उन पर गुस्सा आता है
      बस इतना है कि GitHub अपना रास्ता ढूँढ़ लेगा, इस बारे में मैं सच कहूँ तो आशावादी नहीं हूँ

  • GitHub को संगठन के स्तर पर टूटते हुए देखना काफी चौंकाने वाला रहा है
    Microsoft में शामिल होना, Copilot की तरफ resources का जाना, organizational structure, vibe coding जैसी कई वजहें बताई जाती हैं, लेकिन वजह जो भी हो, कोई गंभीर समस्या है यह मानने से बचना मुश्किल है
    unofficial status page का इतिहास भी काफी डरावना दिखता है
    मैं अंदरूनी नज़रिया सुनना चाहूँगा, लेकिन अभी यह जड़ता के सहारे तैरता डूबता जहाज़ लग रहा है, और ऐसे समय में जब पूरा software industry हिल रहा हो, सिर्फ inertia के भरोसे टिके रहना मुश्किल लगता है

    1. https://mrshu.github.io/github-statuses/
    • अंदर की जानकारी न भी हो, तब भी मोटे तौर पर समझ आता है कि क्या हो रहा है
      इसे वैसे ही चलाया जा रहा है जैसे बड़ी कंपनी द्वारा खरीदी गई सेवाओं के साथ अक्सर होता है
      शुरुआत में सब ठीक रहता है, फिर धीरे-धीरे गिरावट आती है, आखिरकार सब टूटता है, और हर चीज़ numbers game बन जाती है
      Microsoft, Oracle, VMware, CA, Salesforce—ऐसे उदाहरण बहुत हैं, और mergers & acquisitions को अच्छे से संभालने वाली टीमें बहुत कम मिलती हैं
    • मौजूदा 87.25% uptime का मतलब है कि आप हर दिन औसतन 3 घंटे partial outage झेल रहे हैं
      https://onlineornot.com/uptime-calculator/87.25
    • मैं कई सालों से सोच रहा था कि GitHub को SourceForge जैसा बनने में कितना समय लगेगा
      बिना सही नेतृत्व के कुछ भी बहुत बड़ा हो जाए तो आखिरकार टूटता ही है
    • इससे भी बुरी बात यह है कि unofficial status page में भी कई outages पकड़े ही नहीं जाते
      वास्तविक स्थिति अनुभव के हिसाब से इससे भी बदतर लगती है
    • पूरी बात का दोष सिर्फ Microsoft पर डाल देना मुझे यादों का विकृतिकरण लगता है
      GitHub में अधिग्रहण से पहले भी ऐसे दौर रहे हैं जब हर दिन यह सवाल होता था कि साइट ठीक से चलेगी भी या नहीं
      यह सही समय पर सही जगह होने के कारण सफल हुआ; मूल रूप से यह जगह-जगह जोड़े गए ढीले-ढाले सिस्टमों का एक जुगाड़ ही था

  • Hashimoto का GitHub और open source दुनिया के लिए सच्चा लगाव समझ में आता है
    लेकिन अगर उनमें थोड़ा और Richard Stallman जैसी सोच होती—कि non-free software मूल रूप से संदिग्ध और अनैतिक है—तो शायद यह चोट कम लगती
    GitHub 2008 में भी और आज भी किसी और के server पर, किसी और के नियमों के तहत चलता रहा है, और अंततः मालिक के हित के लिए चलाया जाने वाला non-free software ही था
    मैंने भी इसे लंबे समय तक इस्तेमाल किया है और काम के कारण कई बार मजबूरी में भी करना पड़ा, लेकिन मैंने इससे भावनात्मक लगाव नहीं बनाया
    free-software git के ऊपर बना होने के बावजूद, इसकी संरचना का users को platform से बाँधे रखना मुझे हमेशा खटकता रहा
    ऐसा software जिसे email account और terms की सहमति चाहिए, और जो अमेरिकी sanctions laws की वजह से Iran में काम भी नहीं करता, उससे मैं प्यार नहीं कर सकता था
    इसलिए ghostty का GitHub छोड़ना मुझे बिना किसी हिचक के अच्छा लगता है

    • सही बात
      KDE में GitHub को हमने लगभग कभी गंभीरता से नहीं सोचा; हम अपना git infra चलाते थे, और बाद में Gnome के साथ मिलकर GitLab के साथ काम किया ताकि Enterprise Edition की कुछ ज़रूरी सुविधाएँ Community edition में लाई जा सकें
      पिछले 16 सालों में कई घंटों वाला git outage शायद ठीक एक बार हुआ होगा
    • आखिर में यह पूरा मामला value proposition का है
      बस इतना देखना है कि क्या वह मेरे समय और पैसे के लायक है
      Netflix की price hike या games जैसी चीज़ों की तरह इसमें भावनात्मक ऊर्जा खर्च हो सकती है, लेकिन अगर value नहीं है तो बस छोड़ देना चाहिए
      हाँ, शुरुआती computing दौर की यादों जैसी भावनात्मक कड़ी बन जाना समझ में आता है
    • मैं कुछ समय से इन technologies पर नज़र रख रहा हूँ
      issue tracker को git repo के अंदर ही embed करने का विचार मुझे लगातार अधिक समझदारी भरा लग रहा है
    • सहमत
      मुझे लगता है यह पीड़ा इसलिए होती है क्योंकि लोग closed source software की समस्या को अंत तक नहीं देखते
      Hashicorp बेचने के बाद से उनके लिए मेरा सम्मान काफी कम हो गया

  • पहले Mitchell के X पर GitHub की आलोचना वाले thread में मैंने जवाब देखे थे कि GitHub को उन्हें CEO बनाकर लाना चाहिए, और बात में वाकई दम लगा
    ऐसे जहाज़ को मोड़ने वाला नेता सिर्फ manager नहीं हो सकता; उसमें मजबूत conviction, execution की क्षमता और बेहतरीन लोगों को साथ लाने की ताकत सब कुछ होना चाहिए
    मुझे लगता है कि अंततः एक नया GitHub उभरेगा, और जैसे OpenClaw या पुराना GitHub SVN·SourceForge के दौर में उभरे थे, वैसे ही अगर timing सही बैठी तो वह तेज़ी से बढ़ सकता है
    ऐसा लगता है कि उस जगह को लेने की कोशिशें पहले से ही काफी हैं

    • समस्या यह है कि GitHub बहुत सारी चीज़ें करता है
      फिर भी core service के हिसाब से देखें, खासकर complex projects में, तो मुझे अभी तक अच्छा UI नहीं दिखता
      दूसरी तरफ jujutsu की basic direction काफी अच्छी लगती है, लेकिन उसके लिए अब भी कोई ढंग का forge नहीं है
    • शायद अब fossil को फिर से देखने का समय है
      code, wiki, issue—सब लगभग एक ही tool में distributed तरीके से manage होते हैं
    • users GitHub से क्या चाहते हैं और उसके मालिक Microsoft उससे क्या चाहता है, इन दोनों में मेल नहीं है
      अगर AI सचमुच software development को वैसे replace कर दे जैसा big tech executives चाहते हैं, तो शायद फिर alignment बन जाए; लेकिन अभी लोग स्थिर git remote चाहते हैं, और बदले में उन्हें अस्थिर host और आधे-अधूरे vibe coding features का मिश्रण मिल रहा है
    • GitLab सच कहूँ तो काफी अच्छा है, और कुल मिलाकर undervalued है
    • मैं अब भी distributed·federated git forge की उम्मीद कर रहा हूँ
      GitHub पर सबके इकट्ठा होने की सबसे बड़ी वजह यह है कि हर self-hosted forge को sign-up खोले बिना भी issues और PR पर सहयोग आसान हो जाता है; और यह समस्या सारी code को एक ढहती हुई infra में ठूँस दिए बिना भी हल की जा सकती है
      शायद इसे हकीकत बनाना मुश्किल हो, लेकिन अगर हो जाए तो बहुत अच्छा होगा

  • डेवलपर ecosystem 5 साल बाद कैसा दिखेगा, और GitHub तब कैसा होगा, यह जानने की मुझे काफी उत्सुकता है
    मैं GitHub web लगभग कभी नहीं खोलता, github cli का ज़्यादा उपयोग करता हूँ
    सिर्फ gh से ही मेरी ज़्यादातर ज़रूरतें पूरी हो जाती हैं, Actions GitHub पर चलते हैं, और agent परिणाम लेकर issue देखता है, code ठीक करता है—यानि पूरा workflow पहले ही बदल चुका है

  • अगर इतने लोग इस बात से सहमत हैं कि GitHub अब आनंददायक जगह नहीं रहा और काम व deploy दोनों में रुकावट जैसा लगता है, तो Redmond को कड़ा जवाब देना होगा
    अगर यह भावना वास्तव में व्यापक हो गई, तो Microsoft के लिए यह गंभीर झटका हो सकता है
    8 साल पहले उसने लगभग 8 अरब डॉलर खर्च करके developers को अपनी रणनीति का केंद्र बनाया था, और Minecraft पर 2 अरब डॉलर इसलिए लगाए थे ताकि युवा developer base तक पकड़ मजबूत हो
    वह पहले ही OS और server के कई मोर्चे हार चुका है; अगर developers भी हाथ से गए, तो शायद वह 21वीं सदी का Xerox बनने की राह पर जा सकता है

    • मुझे यह काफी HN-शैली की अतिशयोक्ति लगती है
      Microsoft gaming, mobile या AI—किसी में भी बहुत निर्णायक नहीं दिखता, और हार भी सकता है, लेकिन उसके पास अब भी सामान्य white-collar workers की विशाल संख्या बँधी हुई है जिन्हें बस Word और Excel चाहिए
      ऐसे लोग बहुत हैं जिन्हें tech में दिलचस्पी नहीं, लेकिन Office से वे बँधे हुए हैं
      यह बात भी बहुत कुछ कहती है कि Claude ने शुरुआती उपयोगी skills में से एक .docx लिखना सीखा था

  • समस्या Git खुद नहीं है, बल्कि उसके ऊपर बनी issue, PR, Actions जैसी infra है
    मेरी सलाह यह होगी कि अगर किसी दूसरे forge पर जाएँ, तो साथ में git-bug भी इस्तेमाल करें
    यह issue, PR वगैरह को branches में नहीं बल्कि special refs में रखकर सीधे git में store करता है, और कई providers के साथ bidirectional sync भी सपोर्ट करता है
    fossil जैसे दूसरे VCS भी issues को repo के साथ ही रखते हैं; issue भी docs की तरह code को अर्थ देने वाली चीज़ हैं, इसलिए मुझे वही तरीका सही लगता है

    • कुछ दिन पहले मैंने एक सहकर्मी को OpenAI Symphony से प्रेरित local kanban board के साथ पूरी तरह agentic workflow की तरफ झुकते देखा, तो मुझे फिर fossil याद आया
      जब सब कुछ repo के भीतर हो, तो सुविधा तो होती है
      बस अब फर्क यह है कि लगभग बिना रोकटोक वाले LLM coding agent भी उसी सब पर काम करेंगे, तो access scope को सीमित रखना और मुश्किल हो जाएगा
    • git-bug शानदार है, लेकिन यह PR को संभाल नहीं पाता, और जिन users के पास commit access नहीं है उनके लिए bug submit करने का रास्ता अभी भी नहीं है
      बाद वाली चीज़ पर शायद web UI जैसी दिशा में काम हो रहा है, लेकिन तब तक अगर आम users को issue दर्ज करने देना है, तो आखिरकार public infra चाहिए ही
      अपने project में मैं https://github.com/stryan/materia के साथ इसका उपयोग कर रहा हूँ, और repositories व issues को केंद्रीकृत करने के लिए यह अच्छा है
      लेकिन random user input के लिए मैं अब भी GitHub Discussions को एक तरह के pseudo bug tracker की तरह इस्तेमाल कर रहा हूँ
      अगर कोई bug है, तो मैं उसे git-bug में जोड़ता हूँ और GitHub issues के साथ sync कर देता हूँ ताकि वह सार्वजनिक रूप से दिखाई दे; लेकिन बड़े पैमाने पर user bug reports के लिए यह तरीका बहुत फिट नहीं बैठता
      मज़े की बात यह है कि यह workflow idea मुझे ghostty और mise से मिला, और दोनों ही पहले discussion के रूप में bug लेते हैं, फिर सिर्फ actionable होने पर tagged issue बनाते हैं
    • यह कल्पना भी आती है कि Mitchell हताशा में किसी weekend पर Linus की तरह खुद ही distributed issue·PR·Actions infra लिख डालें
    • यह मुझे पहली बार पता चला, और वह special ref mechanism सचमुच बहुत शानदार लगता है
      बढ़िया टिप थी

  • मुझे जिज्ञासा है कि GitHub की quality में इतनी बड़ी गिरावट का सबसे बड़ा कारण क्या है
    एक व्याख्या यह है कि AI-generated code ने codebase की quality गिरा दी; दूसरी यह कि Microsoft के अधिग्रहण के बाद खराब engineering culture फैल गई
    हो सकता है दोनों कुछ हद तक मिले-जुले हों

    • जो व्याख्या मैंने सुनी, उनमें Azure migration सबसे विश्वसनीय लगी
      https://news.ycombinator.com/item?id=45517173
    • तीसरे कारक के रूप में record स्तर की usage growth को भी जोड़ना चाहिए
      https://github.blog/news-insights/company-news/an-update-on-github-availability/
    • agentic coding के सचमुच मुख्यधारा में आने से पहले ही गिरावट शुरू हो चुकी थी
      यह Microsoft culture और infra के मिश्रण का नतीजा लगता है, और अब इसकी quality दूसरे Microsoft services जैसी महसूस होती है
      जोड़ दूँ कि dotnet CLI binaries की hosting इतनी अस्थिर है कि CI अक्सर टूट जाती है, इसलिए मुझे उन्हें खुद re-host करना पड़ता है
    • खराब होना MS अधिग्रहण के बाद शुरू हुआ था, और बहुत खराब तब हुआ जब MS ने AI को बहुत आक्रामक तरीके से push करना शुरू किया
    • मेरे हिसाब से आखिर में uptime और UX/UI ही असली मुद्दे हैं
      Pull Request pages पर results अधूरे दिखना, और Elasticsearch index दोबारा भरते समय data तो गायब न हो लेकिन reindexing पूरी होने तक list ही ठीक से न दिखे—ऐसी घटनाएँ वास्तव में हो रही हैं

  • उन्होंने कहा है कि आने वाले कुछ महीनों में Ghostty project को कहाँ ले जाया जाएगा इस पर और विस्तार से बताएँगे, लेकिन इससे ऐसा भी लगता है कि GitHub Issues या PR दिन में कभी-कभार उपलब्ध न होने की समस्या के जवाब में वे कई महीनों तक पूरी तरह अनुपलब्ध रहने की स्थिति बना देंगे
    यह फैसला थोड़ा भावनात्मक और जल्दबाज़ी में लिया गया सा लगता है, और मुझे नहीं लगता कि यह ज़रूरी तौर पर उनके लिए, Ghostty के लिए, या community के लिए सबसे अच्छा होगा
    कम से कम कोई backup path तैयार करके ही आगे बढ़ना चाहिए था