GitHub से पहले का open source संसार

 (lucumr.pocoo.org)
3 पॉइंट द्वारा GN⁺ 1 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • open source dependency चुनना सिर्फ़ एक package चुनना नहीं था, बल्कि project की साख और टिकाऊपन, और उसके maintenance के तरीके तक को साथ में परखना होता था
  • distributed version control systems आम हो गए, लेकिन वास्तविक collaboration का केंद्र फिर से GitHub पर आकर जमा हो गया, और यही आधुनिक open source की बड़ी विडंबनाओं में से एक बन गया
  • GitHub ने issue tracker, pull request, release page जैसी सुविधाओं के ज़रिए public collaboration के default को बदल दिया, और project discovery तथा contribution flow को भी काफ़ी आसान बना दिया
  • साथ ही GitHub ने छोड़े जा चुके repositories और discussion records तक को संभालकर रखने वाले archive की भूमिका निभाई, और आसानी से खो जाने वाली software commons की स्मृति को थामे रखा
  • हाल में GitHub की केंद्रीयता कमज़ोर पड़ने के संकेतों के बीच, open source में एक ही कंपनी के business model से अलग स्मृति को सुरक्षित रखने और निर्भरता को घटाने वाले public archive की अहमियत और बढ़ गई है

GitHub से पहले का open source माहौल

  • GitHub से पहले भरोसा करने लायक projects की संख्या सीमित थी, और हर project की साख और टिकाऊपन dependency चुनने से सीधे जुड़ी होती थी
  • dependency सिर्फ़ package name नहीं होती थी, उसके साथ project का इतिहास, website, maintainer, release process, और community context भी जुड़ा होता था
  • बड़े projects अक्सर अपना infrastructure खुद चलाते थे, और छोटे projects कभी university server पर तो कभी SourceForge पर होस्ट किए जाते थे
  • Debian packaging process की तरह license और copyright headers तक की समीक्षा जैसे friction मौजूद थे, और यह friction भी trust का आकलन करने का हिस्सा बनता था

अपना infrastructure चलाना और distributed version control का विरोधाभास

  • शुरुआती open source projects में Trac, Subversion, tarball, documentation को खुद चलाए गए server पर होस्ट करना आम बात थी
  • Pocoo की तरह कई projects server cost, Subversion, Trac, और mailing list चलाने का बोझ आपस में बाँटते भी थे
  • Subversion एक centralized repository थी, इसलिए server चलाना स्वाभाविक रूप से साथ आता था, और किसी project का घर hostname, directory, Trac instance, और mailing list archive जैसी चीज़ों में भौतिक रूप से साफ़ दिखता था
  • Mercurial और Git ऐसे distributed systems थे जिनमें कोई भी पूरा repository, branch, और history रख सकता था, लेकिन व्यवहार में केंद्र फिर GitHub पर जाकर जमा हो गया
  • distributed version control systems की जीत के बाद पूरी दुनिया का एक विशाल central service पर standardize हो जाना आधुनिक open source की बड़ी विडंबना बनकर रह गया

GitHub ने क्या बदला

  • GitHub ने project बनाना और उन्हें ढूँढ़ना आसान बनाया, और जिन लोगों के पास 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 project होस्ट करने के लिए बहुत ही तर्कसंगत default choice की तरह काम करता रहा
  • अमेरिकी प्रतिबंध वाले देशों में भी GitHub की पहुँच बनाए रखने की नीति दिखाती है कि centralization सिर्फ़ hosting से आगे बढ़कर एक accessible public base की भूमिका भी निभा रही थी

archive के रूप में GitHub

  • GitHub की कम ध्यान दी गई भूमिकाओं में से एक archive की थी, जहाँ छोड़े जा चुके projects भी searchable बने रहते थे और software commons के index की तरह काम करते थे
  • fork, पुराने issues, और discussion records लगातार बने रहते थे, जिससे centralization ने discoverable memory तैयार की
  • इसके उलट, बड़े platform आने से पहले personal domain expire होना, VPS बंद हो जाना, या developer के गायब हो जाने के साथ project files और services का खो जाना आम था
  • PyPI पर सिर्फ़ metadata बचा रह गया और असली package गायब हो गया ऐसे शुरुआती project की तरह, repository address का पुराने personal server की ओर इशारा करते-करते टूट जाना भी होता था
  • अतीत के बहुत से projects अंततः Internet Archive जैसे बाहरी preservation साधनों पर काफ़ी हद तक निर्भर हो गए

npm और dependency का विस्फोट

  • micro dependency समस्या सिर्फ़ छोटे packages की बढ़ती संख्या तक सीमित नहीं थी; GitHub और npm ने creation, distribution, search, installation, और dependency की लागत को लगभग गायब-सा दिखा दिया, जिससे यह और बढ़ी
  • GitHub से पहले trust और टिकाऊपन dependency चुनने के लिए ज़रूरी तत्व थे, और दूसरी services की availability पर भरोसा करना कठिन होने के कारण code को सीधे repository में शामिल करने वाली vendoring भी आम थी
  • API से पहले के दौर में बाहरी code लाने वाली scripts को maintain करना भी झंझट भरा था, और यही friction dependency जोड़ने से पहले एक बार और सोचने पर मजबूर करता था
  • npm-जैसे ecosystem में package graph इंसानों की समझ की रफ़्तार से भी तेज़ी से बढ़ सकता है
  • license status के धुंधला होने की समस्या से निपटने के लिए GitHub ने terms of service में बदलाव की कोशिश भी की
  • छोटे package पर depend करने के बावजूद repository, maintainer की मौजूदगी, issues, हाल के बदलाव, दूसरे projects में उपयोग, और code तथा package description के मेल को GitHub पर जाँचने की संस्कृति बनी
  • GitHub, npm जैसे registries के लिए trusted publishing संभालने वाले गिने-चुने systems में से एक बन गया, और GitHub पर trust कमज़ोर पड़ना source hosting से आगे बढ़कर पूरी supply chain culture को प्रभावित करता है

GitHub की कमज़ोरी और बदलाव के संकेत

  • हाल के समय में अस्थिरता, बार-बार product changes, Copilot AI का शोर, और अस्पष्ट leadership की वजह से GitHub ने अपनी पुरानी अनिवार्यता का कुछ हिस्सा खोना शुरू किया है
  • agentic coding की लहर के ठीक बीच में होने के कारण उस पर अंदरूनी दबाव भी बढ़ा है, लेकिन फिलहाल स्थिति ऐसी बताई जाती है जहाँ leadership की कमी साफ़ महसूस होती है
  • कुछ समय तक GitHub छोड़ना ज़्यादा प्रतीकात्मक कदम लगता था, लेकिन अब प्रभावशाली projects भी खुले तौर पर migration पर विचार कर रहे हैं या उसे लागू कर रहे हैं
  • Ghostty का GitHub छोड़ने का ऐलान इसीलिए मज़बूत संकेत माना गया, भले ही उसका अगला ठिकाना अभी पूरी तरह स्पष्ट न हो
  • Strudel moved to Codeberg
  • Tenacity moved to Codeberg
  • यह अभी इतनी बड़ी लहर न भी हो कि पूरा रुझान बदल दे, फिर भी GitHub के बाहर की hosting space को दोबारा ज़्यादा देखने वाला बदलाव दिखने लगा है
  • Git खुद मूल रूप से कई घरों को ध्यान में रखकर बनाया गया था, इसलिए एक ही कंपनी का सब कुछ का default home बन जाना खत्म होना open source के लिए स्वस्थ हो सकता है

distributed वापसी की लागत

  • कई forge, कई server, और कई छोटे communities की ओर लौटने पर decentralization और autonomy बढ़ सकती है, और Microsoft leadership changes पर निर्भरता घट सकती है
  • इसका एक फ़ायदा यह भी है कि हर community अपना अलग workflow चुन सकती है
  • Pi के मौजूदा issue tracker की समस्या दिखाती है कि GitHub के product choices आज के open source maintenance की वास्तविकताओं से मेल नहीं खाते
  • GitHub में maintainer के mental health से ज़्यादा engagement-केंद्रित design झलकता है
  • लेकिन self-hosted forge, अपने Mercurial server, या cgit server की ओर जाने पर code भले distributed हो जाए, social context आसानी से बिखर सकता है
  • issues, reviews, design discussion, release notes, security announcements, और पुराने tarball हमारी सोच से कहीं ज़्यादा आसानी से गायब हो सकते हैं
  • पहले यह context सँभालने वाली mailing lists आज की ज़रूरतों के साथ नहीं चल पाईं, और user experience भी अच्छा नहीं है
  • software के भुला दिए जाने की प्रकृति में शायद कुछ शुद्धिकरण का असर हो, लेकिन अगर loss का जोखिम बहुत बढ़ जाए तो distributed version control systems का वास्तव में उपयोग कैसे किया जाए, इसे फिर से सोचना होगा

ज़रूरत है एक public archive की

  • GitHub बना रहे या projects कहीं और चले जाएँ, open source को public, उबाऊ लेकिन स्थिर archive की ज़रूरत है
  • ऐसा ढाँचा चाहिए जो developer productivity market जीतने के लिए नहीं, बल्कि महत्वपूर्ण software के गायब न होने के लिए बना हो
  • इसे endowment या public funding जैसी लंबी अवधि तक टिकने वाली बुनियाद पर चलना चाहिए
  • source archive, release artifacts, metadata, और project context को किसी एक कंपनी के business model या leadership के मूड से अलग जगह सुरक्षित रखा जाना चाहिए
  • GitHub, open source activity का केंद्र बनते-बनते संयोग से उस archive की भूमिका भी निभाने लगा था, लेकिन उसकी केंद्रीयता कम होने पर यह मान नहीं लिया जा सकता कि वह काम अपने आप चलता रहेगा
  • सिर्फ़ personal servers और लोगों की अच्छी नीयत preservation के लिए काफ़ी नहीं रही, और Google Code तथा Bitbucket में platform बंद होने के बाद बने खालीपन ने यह पहले ही दिखा दिया है
  • आगे का system स्मृति को सुरक्षित रखे और निर्भरता घटाए इस दिशा में जाना चाहिए, ताकि project migration, social context mirroring, और release preservation आसान हों, और किसी एक कंपनी का बहाव सबकी सांस्कृतिक समस्या न बन जाए
  • टूटी हुई tarball links और छोड़े जा चुके Trac instances वाले दौर में लौटना भी नहीं चाहते, और पिछले 20 साल की GitHub-केंद्रित संरचना को स्थायी सामान्य स्थिति मान लेना भी संभव नहीं है—यही तनाव अब भी बना हुआ है

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

1 टिप्पणियां

 
GN⁺ 1 일 전
Hacker News की राय
  • मेरे हिसाब से GitHub ने जो सबसे बड़ा बदलाव दिया, उनमें से एक यह था कि उसका ढांचा project-centric नहीं बल्कि people-centric था
    अपने नाम के साथ सीधे 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 करने तक बात पहुँच जाती थी
  • आम तौर पर projects में Git का Fossil पर जीत जाना मुझे आज भी थोड़ा अफ़सोस देता है
    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 लगता है
    • Git protocol और repository के आधार पर भी ऐसे tools बनाए जा सकते थे, और वास्तव में distributed code review जैसी चीज़ें थीं भी
      बस ज़्यादातर लोग वह नहीं चाहते थे, इसलिए उन्हें 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 में रखा जा सकता है
    • शायद timing का भी असर था
      मुझे याद है कि जब Git पहले से stable और रोज़मर्रा के उपयोग लायक हो चुका था, तब भी Fossil में version update के समय कभी-कभी पूरी repository दोबारा बनानी पड़ती थी
      Git का UX बदतर था, और शायद अब भी कई जगह है, लेकिन फिर भी वह चलता था और production में डालने लायक महसूस होता था
      ऊपर से दुनिया के सबसे बड़े open source projects में से एक उसे इस्तेमाल कर रहा था, इसलिए perception के स्तर पर वही फ़र्क निर्णायक बन गया
    • मुझे लगता है अभी सही समय है कि कोई fossilhub.com खरीदकर नई community बनाए
    • मुझे जिज्ञासा है कि बड़ी repositories में Git आख़िर तेज़ क्यों होता है
      हालाँकि कुछ समय तक बड़े blob handle करने में उसकी बढ़त उतनी साफ़ नज़र नहीं आती थी, ऐसा मुझे याद है
  • मुझे लगता है GitHub का archive की भूमिका निभाना उल्टा बुरा रहा है
    जब 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 करते ही रास्ते से हट जाता है, इसलिए मन करता है मैं भी इसे ज्यों का त्यों चुरा लूँ
    • इससे ऐसा माहौल भी बन गया है कि अगर वह GitHub पर नहीं है, तो जैसे उसका अस्तित्व ही नहीं है
      बहुत से developers को शायद यह तक नहीं पता कि code कहीं और भी host किया जा सकता है
    • archiving अपने आप में आसान है, लेकिन copyright और intellectual property law बाधा बनते हैं
      अगर जानकारी को सुलभ बनाने वाली रुकावटें कम हों, तो शक्ति का केंद्रीकरण भी कम होगा
    • मैं इससे सहमत नहीं हूँ
      GitHub ने सालों तक भरोसा इसलिए भी जीता क्योंकि उसने अब तक अपनी इस archive role को सीधे monetize नहीं किया
      हाँ, Copilot से जुड़ी नई features देखकर आगे क्या होगा, यह कहना मुश्किल है
      अगर विकल्प यह है कि चीज़ें कई sites में बँट जाएँ, तो बस अलग-अलग DMCA rules ही मिलेंगे
      उससे बेहतर विकल्प आख़िर है क्या, यह सवाल फिर खड़ा होता है
  • ऐसे लेख पढ़कर मैं जिन projects में शामिल रहा हूँ, उनकी यात्रा याद करने लगता हूँ
    मेरा ज़्यादातर 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 का मालिक बनेगा, तो मुझे उल्टी आ जाती, और आज भी यह बात बहुत असहज करती है
  • अक्सर नज़रअंदाज़ कर दिया जाता है, लेकिन shared login भी सच में बहुत महत्वपूर्ण था
    Rust, crater नाम के tool से पूरे Rust ecosystem के projects पर test चलाता है, और जब Cargo की internal implementation पर निर्भर projects ढूँढकर सैकड़ों issues हाथ से दर्ज करने पड़ते थे, तब कम friction वाला flow बहुत मददगार था
    अगर site credentials पहले से हों और blank template भी स्वीकार हो, तो 200 issues दर्ज करना कहीं ज़्यादा आसान हो जाता है
    इसके उलट, self-hosted instance देखते ही अक्सर मैं वहीं हार मान लेता हूँ
  • मैं SourceForge आने से पहले भी Planet Source Code पर पोस्ट किया करता था
  • मुझे Trac वाकई बहुत पसंद था
    नया open source project शुरू करते समय पहले कदम के रूप में Trac set up करना अविश्वसनीय स्तर का friction पैदा करता था, फिर भी वह अच्छा लगता था
    Django आज भी 20 साल से ज़्यादा समय से Trac पर चल रहा है: https://code.djangoproject.com/timeline
    उसे मैंने set up नहीं किया था, लेकिन उससे पहले वाला private Trac खड़ा करने में शायद मदद की थी
    • Trac सच में अच्छा था
      हालाँकि मेरा पहला issue tracker Bugzilla था, और उसे set up करना काफ़ी पीड़ादायक था, साथ ही दूसरे tools से integration भी अच्छा नहीं था
      फिर भी Zarro Boogs देखना अपने आप में मज़ेदार था
    • कई मायनों में Trac ही वह वजह था कि मैंने deploy होने वाले apps PHP के बजाय Python में बनाना शुरू किया
      उसका plugin system वाकई शानदार था
    • मुझे Bitbucket पसंद था
      वह अपना काम ठीक करता था, मेरे लिए कभी ख़ास टूटा नहीं, और Mercurial मुझे ज़्यादा पसंद था
      कंपनियाँ GitHub इस्तेमाल करने लगीं तो मैं भी वहाँ चला गया, लेकिन आज भी GitHub को बस एक सुस्त Git endpoint की तरह इस्तेमाल करता हूँ और build/deploy Docker तथा shell script से करता हूँ, इसलिए migrate करने की लागत बहुत कम है
      काम में अगर फ़ैसला मेरा न हो, तो मुझे लगता है SVN के ज़माने की तरह बस पैसे लेकर जो tool दिया जाए वही इस्तेमाल कर लेना चाहिए
    • अजीब बात है कि उस समय मैं Trac से बहुत नफ़रत करता था, लेकिन अब वही अच्छी याद बनकर रह गया है
      तब लगता था कि वह बहुत कुछ करने की कोशिश में किसी एक चीज़ में उत्कृष्ट नहीं है
      आज शायद वह खिताब GitLab के पास है, और बाद में शायद उसके बारे में भी ऐसी ही अच्छी यादें रहेंगी
  • code archive services को जिज्ञासा में खोजा तो कुछ विकल्प दिखे
    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 पर कम
  • मुझे लगता है मैं Flask को लगभग उसके शुरुआती दिनों से इस्तेमाल करने वालों में था
    free और आसान modern hosting रहे AppEngine का उपयोग करने के लिए मैंने Python सीखी, और उसी की वजह से जब Flask आया तो मैं उसे अपनाने की सही स्थिति में था
    मैं Armin का लंबे समय से सम्मान करता आया हूँ, और link खोलने से पहले ही domain देखकर पहचान गया
    उनकी यह बात भी सही लगी कि उस दौर में default choice GitHub नहीं था
    यह बात भी प्रभावशाली है कि यह लेख कुछ घंटे पहले आई Mitchell की post का जवाब है, और इतनी जल्दी इतना लंबा, सधा हुआ, high-quality लेख लिख दिया गया
  • यह code.google.com की याद दिलाता है
    अब तक यक़ीन नहीं होता कि Google ने इतना बड़ा मौका यूँ ही गंवा दिया
    • सच में पुरानी यादें ताज़ा हो गईं
      वह service बंद होने से पहले मैं उसी team में था