GitHub से पहले का open source संसार
(lucumr.pocoo.org)- GitHub के open source की सामाजिक अवसंरचना के रूप में स्थापित होने से पहले, डेवलपर्स अपने ही Trac, Subversion repository, mailing list जैसी स्वयं-प्रबंधित अवसंरचना पर प्रोजेक्ट चलाते थे, और dependency जोड़ने में काफ़ी घर्षण और सावधानी शामिल होती थी
- GitHub ने प्रोजेक्ट बनाना, ढूँढना और योगदान देना क्रांतिकारी रूप से आसान बना दिया, issue tracker, pull request, CI आदि को मानकीकृत किया, और open source के archive की भूमिका भी निभाई
- npm जैसे package ecosystem के साथ जुड़ते ही micro dependency explosion हुआ, और GitHub trust system का एक मुख्य स्तंभ बन गया; लेकिन आज अस्थिरता, product direction की उलझन और AI noise जैसी वजहों से विश्वास क्षीण हो रहा है
- Ghostty भी जा रहा है, और Strudel, Tenacity आदि के Codeberg पर migrate होने की हलचल दिख रही है; decentralization स्वायत्तता बढ़ाता है, लेकिन issue, review, security advisory जैसे social context के खोने का जोखिम भी है
- हाल में GitHub की केंद्रीयता कमज़ोर पड़ने के संकेतों के बीच, यादों को सुरक्षित रखते हुए निर्भरता घटाने वाला सार्वजनिक archive और अधिक महत्वपूर्ण हो गया है। open source का अगला युग स्मृति को बचाए रखते हुए निर्भरता घटाने की दिशा में होना चाहिए
GitHub से पहले का open source माहौल
- GitHub से पहले भरोसेमंद प्रोजेक्टों की संख्या सीमित थी, और हर प्रोजेक्ट की प्रतिष्ठा और स्थायित्व dependency चुनने से सीधे जुड़ी होती थी
- Dependency सिर्फ़ एक package name नहीं होती थी, बल्कि उसके साथ प्रोजेक्ट का इतिहास, website, maintainer, release process और community context भी जुड़ा आता था
- बड़े प्रोजेक्ट अक्सर अपनी खुद की infrastructure चलाते थे, जबकि छोटे प्रोजेक्ट कभी university server या SourceForge पर hosted होते थे
- Debian packaging process की तरह license और copyright header तक की समीक्षा वाला घर्षण मौजूद था, और यह घर्षण भी trust के आकलन का हिस्सा बनता था
स्वयं की infrastructure और distributed version control का paradox
- शुरुआती open source प्रोजेक्टों का Trac, Subversion, tarball, documentation को सीधे चलाने वाले server पर होना आम बात थी
- Pocoo की तरह कई प्रोजेक्ट server cost, Subversion, Trac और mailing list संचालन का बोझ आपस में बाँटते थे
- Subversion एक centralized repository था, इसलिए server चलाना स्वाभाविक रूप से साथ आता था, और किसी प्रोजेक्ट का घर hostname, directory, Trac instance, mailing list archive जैसी चीज़ों से भौतिक रूप से साफ़ दिखाई देता था
- Mercurial और Git ऐसे distributed system थे जिनमें हर किसी के पास पूरा repository, branch और history हो सकता था, लेकिन व्यवहार में केंद्र फिर GitHub पर आकर जमा हो गया
- Distributed version control system की जीत के बाद पूरी दुनिया का एक विशाल केंद्रीकृत सेवा पर मानकीकृत हो जाना आधुनिक open source की बड़ी विडंबनाओं में से एक है
GitHub द्वारा लाया गया बदलाव
- GitHub ने प्रोजेक्ट बनाना और ढूँढना आसान किया, और developer mailing list का अनुभव न रखने वाले लोगों के लिए भी contribution flow को समझना सरल बनाया
- issue tracker, pull request, release page, wiki, organization page, API, webhook और बाद में CI तक देकर इसने public collaboration का default ही बदल दिया
- open source collaboration दिखाई देने वाली history और दिखाई देने वाली discussion के आधार पर चलने का सामान्य तरीका बन गया
- एक लंबे समय तक GitHub open source प्रोजेक्ट होस्ट करने के लिए बहुत ही तर्कसंगत default choice की तरह काम करता रहा
- अमेरिकी प्रतिबंध वाले देशों में भी GitHub की उपलब्धता बनाए रखने की नीति की तरह, centralization सिर्फ़ hosting नहीं बल्कि सुलभ सार्वजनिक आधार की भूमिका भी निभा रहा था
archive के रूप में GitHub
- GitHub की कम चर्चित भूमिकाओं में एक archive की भूमिका थी, जहाँ छोड़े गए प्रोजेक्ट भी खोजे जा सकते थे और वह software commons के index की तरह काम करता था
- fork, पुराने issue और discussion record बने रहने से centralization ने खोजी जा सकने वाली स्मृति बनाई
- इसके उलट, बड़े platform आने से पहले व्यक्तिगत domain expire हो जाना, VPS बंद हो जाना या developer के गायब हो जाने पर प्रोजेक्ट files और services का गायब हो जाना आम था
- ऐसे शुरुआती प्रोजेक्ट जिनमें PyPI पर सिर्फ़ metadata बचा रहा और असली package गायब हो गया की तरह, repository address का पुराने personal server की ओर इशारा करना और फिर टूट जाना आम स्थिति थी
- अतीत के कई प्रोजेक्ट अंततः Internet Archive जैसे बाहरी preservation साधनों पर काफ़ी निर्भर हो गए
npm और dependency विस्फोट
- micro dependency problem सिर्फ़ छोटे package बढ़ जाने तक सीमित नहीं रहा; GitHub और npm ने creation, distribution, discovery, installation और dependency cost को लगभग शून्य जैसा दिखा दिया, जिससे समस्या और बढ़ी
- GitHub से पहले trust और continuity dependency चुनने के अनिवार्य तत्व थे, और दूसरी services की उपलब्धता पर भरोसा करना कठिन होने से code को सीधे repository में शामिल करने वाली vendoring भी आम थी
- API से पहले के दौर में external code लाने वाली script बनाए रखना भी झंझटभरा था, और यही घर्षण dependency जोड़ने से पहले एक बार और सोचने पर मजबूर करता था
- npm-शैली के ecosystem में package graph इंसानी समझ की गति से कहीं तेज़ी से बढ़ सकता है
- License स्थिति के अस्पष्ट होने की समस्या से निपटने के लिए GitHub ने terms of service revision जैसी कोशिश भी की
- छोटे package पर निर्भर होने पर भी repository, maintainer की मौजूदगी, issue, हालिया बदलाव, दूसरे प्रोजेक्टों द्वारा उपयोग, और code व package description की संगति को GitHub पर जाँचने की संस्कृति विकसित हुई
- GitHub npm जैसे registry के लिए trusted publishing संभालने वाली गिनी-चुनी प्रणालियों में से एक बन गया, इसलिए GitHub पर trust कमज़ोर पड़ना सिर्फ़ source hosting नहीं बल्कि पूरे supply chain culture को प्रभावित करता है
GitHub की कमज़ोरी और migration के संकेत
- हाल में GitHub अस्थिरता, लगातार product बदलाव, Copilot AI शोर, और अस्पष्ट leadership के कारण अपनी पुरानी अनिवार्यता का कुछ हिस्सा खो रहा है
- agentic coding की लहर के ठीक बीच में होने से आंतरिक दबाव भी बढ़ा है, लेकिन अभी की स्थिति को leadership की कमी साफ़ महसूस होने वाली अवस्था के रूप में वर्णित किया गया है
- कुछ समय तक GitHub छोड़ना लगभग प्रतीकात्मक कदम जैसा था, लेकिन अब प्रभावशाली प्रोजेक्ट भी migration पर सार्वजनिक रूप से विचार कर रहे हैं या उसे लागू कर रहे हैं
- Ghostty के GitHub छोड़ने की घोषणा को, भले अंतिम गंतव्य अभी स्पष्ट न हो, एक मज़बूत संकेत माना जा रहा है
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- यह अभी शायद मुख्यधारा बदल देने लायक न हो, फिर भी GitHub के बाहर की hosting spaces को फिर से ज़्यादा बार देखने की प्रवृत्ति उभर रही है
- Git ख़ुद मूल रूप से कई घरों को ध्यान में रखकर डिज़ाइन किया गया था, इसलिए एक ही company का सब कुछ का default home बन जाना खत्म करना open source के लिए स्वस्थ हो सकता है
वितरित व्यवस्था की ओर वापसी की लागत
- कई forge, कई server और कई छोटे community की ओर लौटने पर decentralization और autonomy बढ़ सकती है, और Microsoft leadership changes पर निर्भरता घट सकती है
- इसका यह फ़ायदा भी है कि हर community अपना अलग workflow चुन सकती है
- Pi की मौजूदा issue tracker समस्या दिखाती है कि GitHub के product choices आज के open source maintenance की वास्तविकताओं से मेल न खाने वाले परिणाम दे सकते हैं
- GitHub में maintainer की mental health से अधिक engagement-केंद्रित डिज़ाइन दिखाई देता है
- दूसरी ओर self-hosted forge, अपने Mercurial server, या cgit server पर जाने से code तो वितरित हो सकता है, लेकिन social context आसानी से बिखर सकता है
- issue, review, design discussion, release note, security notice और पुराने tarball हमारी अपेक्षा से कहीं अधिक आसानी से गायब हो सकते हैं
- पहले यह context संभालने वाली mailing list आज की ज़रूरतों के साथ नहीं चल पाई, और user experience भी अच्छा नहीं है
- software के भुला दिए जाने में शायद कुछ शुद्धिकारी प्रभाव हो, लेकिन अगर loss risk बहुत बढ़ जाए तो distributed version control system का वास्तविक उपयोग कैसे किया जाए, इस पर फिर से सोचना पड़ेगा
ज़रूरत है एक सार्वजनिक archive की
- GitHub रहे या प्रोजेक्ट कहीं और चले जाएँ, open source को सार्वजनिक, नीरस लेकिन स्थिर archive की ज़रूरत है
- developer productivity market में जीतने वाली service नहीं, बल्कि महत्वपूर्ण software को गायब होने से बचाने वाली संरचना चाहिए
- इसे endowment या public funding जैसी दीर्घकालिक रूप से टिकाऊ नींव पर चलना चाहिए
- source archive, release artifacts, metadata और project context को किसी एक company के business model या leadership mood से बँधी जगह पर नहीं रखा जाना चाहिए
- GitHub open source activity का केंद्र बनते-बनते संयोग से archive की भूमिका भी निभाने लगा, लेकिन अगर उसकी केंद्रीयता कम होती है तो यह मान नहीं सकते कि वह भूमिका अपने-आप बनी रहेगी
- सिर्फ़ personal server और goodwill preservation के लिए पर्याप्त नहीं थे, और Google Code व Bitbucket में भी platform बंद होने के बाद की खाली जगह पहले ही दिख चुकी है
- आगे की प्रणालियाँ स्मृति को सुरक्षित रखें और निर्भरता घटाएँ वाली दिशा में जानी चाहिए, ताकि project migration, social context mirroring और release preservation आसान हों, और किसी एक company का भटकाव सबकी सांस्कृतिक समस्या न बन जाए
- टूटी हुई tarball links और छोड़े गए Trac instance के दौर में लौटना भी नहीं चाहते, और पिछले 20 साल की GitHub-केंद्रित संरचना को स्थायी सामान्य स्थिति मान लेना भी संभव नहीं—यह तनाव बना हुआ है
3 टिप्पणियां
यह सच है कि GitHub ने अब तक बहुत बड़ी भूमिका निभाई है, लेकिन मेरी याद में उससे पहले open source project वही लोग करते थे जो सचमुच इसमें लगे होते थे, और किसी व्यक्ति द्वारा उन्हें सार्वजनिक करना आम बात नहीं थी। यहाँ तक कि कंपनियों के अंदर भी कई बार चीजें सिर्फ़ एक ही टीम के भीतर साझा होती थीं। और open source में किसी बड़े project में योगदान देने वाले व्यक्ति के रूप में स्वीकार किया जाना बहुत बड़े सम्मान की बात मानी जाती थी; किसी व्यक्ति के छोटे-मोटे project पर तो कोई ध्यान भी नहीं देता था.
डेवलपर समुदाय का माहौल बदला, सार्वजनिक software जारी करके अपनी क्षमता को मान्यता दिलाने का एक साधन बनने लगा, और अंततः कुछ DVCS में से git ज़्यादा व्यापक रूप से इस्तेमाल होने लगा—मुझे याद है कि शुरुआत इसी तरह कई तरह की अच्छी परिस्थितियों के साथ हुई थी। प्रतिस्पर्धी भी इसी तरह की सेवाएँ दे रहे थे; मुझे नहीं लगता कि सिर्फ़ GitHub ने कोई ख़ास असाधारण काम किया था.
असल में issue, PR और discussion ही समस्या हैं; git खुद तो कभी भी किसी दूसरी service पर ले जाया जा सकता है। इन तीनों को git में शामिल करने वाले project भी थे, तो ऐसी चीज़ें इस्तेमाल करें तो कभी भी migrate किया जा सकेगा।
Hacker News की राय
अपने नाम के साथ सीधे repository जोड़कर जल्दी कुछ बना सकना, SourceForge में project का नाम तय करके उसे reserve करने और फिर CVS या SVN repository, website, mailing list, issue tracker तक सेट करने वाली भारी प्रक्रिया की तुलना में कहीं ज़्यादा मुक्त महसूस कराता था
इससे "यह तो बस थोड़ी देर के लिए बना रहा हूँ" जैसी मानसिक बाधा काफ़ी कम हो गई
GitHub ने issue tracker, PR, release page, wiki, organization page, API, webhook, CI सब कुछ एक साथ शुरू से नहीं दिया था
पहले organization feature भी नहीं था, इसलिए लोग नया user account बनाकर नकली organization जैसा सेटअप करते थे, और "GitHub कुछ महीनों में यह दे ही देगा" सोचकर अलग bug tracker अपनाने को टालते-टालते आखिर repository में text file से चीज़ें manage करने तक बात पहुँच जाती थी
Linux kernel जैसे बहुत बड़े codebase में Git की performance advantage रही होगी, लेकिन ज़्यादातर projects शायद ही कभी VCS performance की limit तक पहुँचते हैं
Fossil में wiki, forum, ticket जैसे built-in tools का code के साथ एक ही file में version-controlled होना सच में बहुत उपयोगी है
freelance काम में Fossil की वजह से project context, details, और client के साथ हुई सहमतियों को फिर से समझना बहुत आसान हो जाता है
codebase को गंदा करने या email और note tools में इधर-उधर खोजकर context वापस जोड़ने की ज़रूरत नहीं पड़ती
यह भी पसंद नहीं कि सिर्फ़ इसलिए बदलाव असंभव मान लिया जाए क्योंकि Git cultural रूप से बहुत गहराई तक जम चुका है
Fossil पर switch करना आसान है, और Git से आने पर workflow उल्टा ज़्यादा simple लगता है
बस ज़्यादातर लोग वह नहीं चाहते थे, इसलिए उन्हें momentum नहीं मिला
issue को project के साथ store करना कई मामलों में परेशानी भी बन सकता है
अगर client bug reproduce करने के लिए बहुत सारे screenshot या video files भेजे, तो repository जल्दी फूल जाती है, और अगर वे code के साथ बंधे हों तो local में ticket देखने के लिए सबको वही भारी repository डाउनलोड करनी पड़ती है, जो काफ़ी झंझट है
आखिरकार बात अक्सर "इसे मत इस्तेमाल करो, यह बहुत complex है और repository ही फुलाता है" तक पहुँच जाती है
Fossil की ज़्यादातर features Git backend के ऊपर भी implement की जा सकती हैं, और wiki या issue को अलग parallel branch layer में रखा जा सकता है
मुझे याद है कि जब Git पहले से stable और रोज़मर्रा के उपयोग लायक हो चुका था, तब भी Fossil में version update के समय कभी-कभी पूरी repository दोबारा बनानी पड़ती थी
Git का UX बदतर था, और शायद अब भी कई जगह है, लेकिन फिर भी वह चलता था और production में डालने लायक महसूस होता था
ऊपर से दुनिया के सबसे बड़े open source projects में से एक उसे इस्तेमाल कर रहा था, इसलिए perception के स्तर पर वही फ़र्क निर्णायक बन गया
हालाँकि कुछ समय तक बड़े blob handle करने में उसकी बढ़त उतनी साफ़ नज़र नहीं आती थी, ऐसा मुझे याद है
जब 99% समय एक उपयोगी centralized service मौजूद रहती है, तो पूरे समुदाय की preservation capability कमजोर हो जाती है
अगर किसी चीज़ को जीवित रखने के लिए किसी को सचमुच खुद seed करना पड़ता, तो लोग जिन चीज़ों को वास्तव में महत्वपूर्ण मानते हैं उनकी copies ज़्यादा संभालकर रखते
"बाद में फिर checkout कर लेंगे" यह मान लेना आसान हो जाना ही असली समस्या है
ऐसी कोई एक जगह नहीं होनी चाहिए जहाँ से सब कुछ नीचे उतारा जा सके
अगर किसी GitHub project पर DMCA आ जाए, तो उसके forks भी साथ गायब हो जाते हैं
जब Nintendo ने 2024 में लोकप्रिय Switch emulator को हटवाया, तब preservation और आगे का काम बस इस तरह संभव हो पाया कि किसी ने latest revision checkout करके रखी हो और उसे खोज निकाला जाए
वह भी सिर्फ़ इसलिए संभव था क्योंकि वह बहुत लोकप्रिय project था: https://news.ycombinator.com/item?id=40254602
और हाँ, इस site का Splatoon-जैसा header/footer animation वाकई बहुत अच्छा है
वह परेशान नहीं करता, माहौल भी बनाता है, और scroll करते ही रास्ते से हट जाता है, इसलिए मन करता है मैं भी इसे ज्यों का त्यों चुरा लूँ
बहुत से developers को शायद यह तक नहीं पता कि code कहीं और भी host किया जा सकता है
अगर जानकारी को सुलभ बनाने वाली रुकावटें कम हों, तो शक्ति का केंद्रीकरण भी कम होगा
GitHub ने सालों तक भरोसा इसलिए भी जीता क्योंकि उसने अब तक अपनी इस archive role को सीधे monetize नहीं किया
हाँ, Copilot से जुड़ी नई features देखकर आगे क्या होगा, यह कहना मुश्किल है
अगर विकल्प यह है कि चीज़ें कई sites में बँट जाएँ, तो बस अलग-अलग DMCA rules ही मिलेंगे
उससे बेहतर विकल्प आख़िर है क्या, यह सवाल फिर खड़ा होता है
मेरा ज़्यादातर open source काम self-hosted infrastructure पर हुआ, और उसका प्रमुख उदाहरण Xfce है
2004 में जब मैं पहली बार जुड़ा था, तब शायद वहाँ SVN server था और संभवतः CVSweb का नया SVN-support web interface भी
core team में आने के बाद शायद मैंने Bugzilla सेट किया था, हालाँकि यह किसी और ने भी किया हो सकता है
जब Git मुख्यधारा बनना शुरू हुआ, तब मैंने बड़े SVN repository को कई Git repositories में migrate करने का काम lead किया और cgit web interface भी जोड़ा
तब तक हम Bugzilla ही इस्तेमाल कर रहे थे
2009~2010 के आसपास एक छोटे startup में जाने के बाद OSS के लिए समय कम हो गया, तो project छोड़ दिया; फिर 2022 में लौटा तो इस बीच GitLab instance और CI runner खड़े किए जा चुके थे, और Bugzilla को GitLab issues में भी migrate कर दिया गया था
आज भी active लोग मुट्ठीभर हैं और infrastructure management लगभग एक ही व्यक्ति संभालता है, लेकिन छोटी team के लिए भी यह काफ़ी है
infrastructure का sponsorship से मिलना बहुत बड़ी किस्मत है, और सिर्फ़ recurring sponsorship से भी ज़रूरत पड़े तो खर्च खुद उठाया जा सकता है
सबसे अच्छी बात यह है कि GitHub/Microsoft पर निर्भर नहीं रहना पड़ता
20 साल पहले अगर कोई कहता कि Microsoft दुनिया की सबसे बड़ी OSS code forge का मालिक बनेगा, तो मुझे उल्टी आ जाती, और आज भी यह बात बहुत असहज करती है
Rust,
craterनाम के tool से पूरे Rust ecosystem के projects पर test चलाता है, और जब Cargo की internal implementation पर निर्भर projects ढूँढकर सैकड़ों issues हाथ से दर्ज करने पड़ते थे, तब कम friction वाला flow बहुत मददगार थाअगर site credentials पहले से हों और blank template भी स्वीकार हो, तो 200 issues दर्ज करना कहीं ज़्यादा आसान हो जाता है
इसके उलट, self-hosted instance देखते ही अक्सर मैं वहीं हार मान लेता हूँ
नया open source project शुरू करते समय पहले कदम के रूप में Trac set up करना अविश्वसनीय स्तर का friction पैदा करता था, फिर भी वह अच्छा लगता था
Django आज भी 20 साल से ज़्यादा समय से Trac पर चल रहा है: https://code.djangoproject.com/timeline
उसे मैंने set up नहीं किया था, लेकिन उससे पहले वाला private Trac खड़ा करने में शायद मदद की थी
हालाँकि मेरा पहला issue tracker Bugzilla था, और उसे set up करना काफ़ी पीड़ादायक था, साथ ही दूसरे tools से integration भी अच्छा नहीं था
फिर भी
Zarro Boogsदेखना अपने आप में मज़ेदार थाउसका plugin system वाकई शानदार था
वह अपना काम ठीक करता था, मेरे लिए कभी ख़ास टूटा नहीं, और Mercurial मुझे ज़्यादा पसंद था
कंपनियाँ GitHub इस्तेमाल करने लगीं तो मैं भी वहाँ चला गया, लेकिन आज भी GitHub को बस एक सुस्त Git endpoint की तरह इस्तेमाल करता हूँ और build/deploy Docker तथा shell script से करता हूँ, इसलिए migrate करने की लागत बहुत कम है
काम में अगर फ़ैसला मेरा न हो, तो मुझे लगता है SVN के ज़माने की तरह बस पैसे लेकर जो tool दिया जाए वही इस्तेमाल कर लेना चाहिए
तब लगता था कि वह बहुत कुछ करने की कोशिश में किसी एक चीज़ में उत्कृष्ट नहीं है
आज शायद वह खिताब GitLab के पास है, और बाद में शायद उसके बारे में भी ऐसी ही अच्छी यादें रहेंगी
GitHub का अपना program भी है: https://archiveprogram.github.com/
और UNESCO-supported non-profit Software Heritage भी है: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
लेकिन यह पक्ष मुख्यतः code और commit history के preservation पर केंद्रित है, issue, PR, discussion, wiki जैसे आसपास के metadata पर कम
free और आसान modern hosting रहे AppEngine का उपयोग करने के लिए मैंने Python सीखी, और उसी की वजह से जब Flask आया तो मैं उसे अपनाने की सही स्थिति में था
मैं Armin का लंबे समय से सम्मान करता आया हूँ, और link खोलने से पहले ही domain देखकर पहचान गया
उनकी यह बात भी सही लगी कि उस दौर में default choice GitHub नहीं था
यह बात भी प्रभावशाली है कि यह लेख कुछ घंटे पहले आई Mitchell की post का जवाब है, और इतनी जल्दी इतना लंबा, सधा हुआ, high-quality लेख लिख दिया गया
अब तक यक़ीन नहीं होता कि Google ने इतना बड़ा मौका यूँ ही गंवा दिया
वह service बंद होने से पहले मैं उसी team में था