GitHub छोड़कर Forgejo पर जाना

 (jorijn.com)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub छोड़ने की सीधी वजह अप्रैल 2026 की आउटेज नहीं, बल्कि GitHub पर चलने वाले code और workflow की ownership का सवाल है
  • अगस्त 2025 के बाद GitHub अपने अलग CEO के बिना Microsoft की CoreAI division में शामिल हो गया, और code Microsoft की AI organization के तहत आ गया
  • Copilot Free, Pro, Pro+ अप्रैल 2026 से ऐसे opt-out ढांचे में बदल गए, जिसमें interaction data डिफ़ॉल्ट रूप से training data के रूप में इस्तेमाल होता है
  • GitHub और Microsoft अमेरिकी कंपनियां हैं, इसलिए वे FISA 702 और CLOUD Act के अधिकार-क्षेत्र में आते हैं; केवल EU data residency से यह समस्या हल नहीं होती
  • Forgejo v15 LTS, code.jorijn.com के एकल NUC पर चल रहा है, और runner को KVM, gVisor, साप्ताहिक rebuild, और egress filter से isolate किया गया है

GitHub छोड़ने की वजह आउटेज नहीं, ownership का मुद्दा है

  • अप्रैल 2026 की आउटेज डेवलपर्स के लिए काफी गंभीर थी, लेकिन GitHub छोड़ने की मुख्य वजह आउटेज खुद नहीं, बल्कि GitHub पर चलने वाले code और workflow की ownership है
  • 27 अप्रैल 2026 को नीदरलैंड्स के आंतरिक मंत्रालय ने सरकारी source code के लिए self-hosted Forgejo instance code.overheid.nl का soft launch किया
    • प्रोजेक्ट मैनेजर Boris Van Hoytema ने बताया कि यह platform इस कानूनी आवश्यकता से शुरू हुआ कि मंत्रालय source code को उस “जगह” पर प्रकाशित करें, जिसका वे कानूनी रूप से “मालिकाना हक” रखते हों
    • Forgejo को GitLab पर प्राथमिकता दी गई, क्योंकि यह पूरी तरह open source है और digital sovereignty के लिए जरूरी स्वतंत्रता देता है
  • व्यक्तिगत code के default Git host को भी code.jorijn.com पर शिफ्ट कर दिया गया है, जहां Forgejo v15 LTS एक single NUC की hardened configuration पर चल रहा है
    • कुछ repositories पहले ही migrate हो चुकी हैं और बाकी कतार में हैं
    • migration पूरा होने के बाद public GitHub repositories को archive किया जाएगा और हर archive से नए location की ओर इशारा किया जाएगा

आउटेज और AI load

  • 23 अप्रैल 2026 को merge queue के squash-merge code path ने feature flag के अधूरे rollout के बाद 658 repositories और 2,092 pull requests में पहले से merge हो चुके commits को चुपचाप revert कर दिया
    • Modal और Zipline सहित कई कंपनियों ने data को manually recover किया
    • चार दिन बाद overloaded Elasticsearch cluster की वजह से Pull Requests, Issues और Packages 6 घंटे से ज्यादा समय तक ठप रहे
  • केवल फरवरी 2026 में ही 37 incidents दर्ज किए गए, जिनमें 3 घंटे 40 मिनट की वह आउटेज भी शामिल थी, जिसमें Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot और Pages एक साथ डाउन हो गए थे
  • 1 अक्टूबर 2025 को 10 घंटे की macOS runner outage भी हुई थी
  • IncidentHub के आंकड़ों के अनुसार मई 2025 से अप्रैल 2026 तक GitHub ने 257 incidents और 48 major outages दर्ज किए, और कुल downtime लगभग 112 घंटे रहा
  • GitHub CTO Vlad Fedorov ने 28 अप्रैल को माफी मांगते हुए कहा कि 2025 के दिसंबर के बाद आई “agentic AI workflow growth” से पैदा हुए load को संभालने के लिए capacity को 30 गुना बढ़ाना होगा
    • reliability की समस्या को AI features के विस्तार का downstream नतीजा माना जा रहा है
    • GitHub, AI features को धीमा करने के बजाय उन्हें और ज्यादा push कर रहा है
  • The Pragmatic Engineer ने यह रेखांकित किया कि GitLab, Bitbucket, Vercel, Linear, Sentry ने वही साल नहीं झेला
    • ये कंपनियां भी developer demand के दबाव का सामना कर रही हैं, इसलिए GitHub की outage pattern, GitHub-विशिष्ट समस्या लगती है

GitHub में संगठनात्मक बदलाव

  • 11 अगस्त 2025 को Thomas Dohmke ने GitHub CEO पद छोड़ दिया, और Microsoft ने कोई नया CEO नियुक्त नहीं किया
  • GitHub को Microsoft की CoreAI division में समाहित कर दिया गया
  • GitHub का revenue, engineering और support, Julia Liuson के तहत Microsoft developer division को report करता है
    • GitHub CPO, Microsoft AI platform VP को report करता है
    • brand बना हुआ है, लेकिन independent leadership खत्म हो चुकी है
  • 2018 से 2024 तक यह आकलन काफी हद तक सही था कि Microsoft ने GitHub को कुछ दूरी बनाकर operate किया, लेकिन अगस्त 2025 के बाद यह धारणा बनाए रखना मुश्किल हो गया
  • अब github.com पर code push करने का मतलब Microsoft की AI organization के तहत आने वाली unit को code push करना है

Copilot training data की default setting में बदलाव

  • 25 मार्च 2026 को GitHub ने privacy statement में बदलाव की घोषणा की, जो 24 अप्रैल से लागू हुई
    • Copilot Free, Pro, Pro+ users का interaction data, खासकर input, output, code snippets और संबंधित context, AI model training और improvement के लिए इस्तेमाल किया जाएगा, जब तक user इसे मना न करे
  • मुख्य बदलाव यह है कि यह opt-in नहीं बल्कि opt-out है
    • Copilot Free, Pro, Pro+ users अगर Copilot settings page पर इसे बंद नहीं करते, तो वे model training में योगदान देंगे
  • repository-level blocking मौजूद नहीं है
    • admins GitHub को यह निर्दिष्ट नहीं कर सकते कि किसी खास repository के अंदर के interactions को training में इस्तेमाल न किया जाए
    • opt-out, user account के हिसाब से होने वाली setting है, इसलिए हर contributor को खुद इसे चुनना होगा
    • नतीजतन, अगर Copilot Free/Pro/Pro+ user किसी repository पर काम करता है, तो license की परवाह किए बिना वह codebase training material बन सकता है
  • private repository के लिए अपवाद भी सीमित रूप से लागू होता है
    • GitHub कहता है कि वह private repositories के “at rest” content को training में इस्तेमाल नहीं करता
    • लेकिन private repository के अंदर Copilot इस्तेमाल करते समय बनने वाले “code snippets and interaction context” को वह collect करता है
    • “स्थिर अवस्था में मौजूद code” और “editing के दौरान बने snippets” के बीच की सीमा धुंधली है
  • Copilot Business और Copilot Enterprise customers इस दायरे से बाहर हैं, क्योंकि उन पर अलग Data Protection Agreements लागू होते हैं
    • यानी अगर आप पर्याप्त भुगतान करते हैं तो interactions training data नहीं बनते, और नहीं करते तो वे training data बन जाते हैं
  • user interaction data को लेकर GitHub की strategic दिलचस्पी अब वैकल्पिक तत्व नहीं, बल्कि structural element बन चुकी है

अधिकार-क्षेत्र का जोखिम केवल डेटा लोकेशन से हल नहीं होता

  • GitHub Inc. और Microsoft Corp. अमेरिकी कंपनियाँ हैं, और इनके पास मौजूद डेटा FISA Section 702 और 2018 CLOUD Act समेत अमेरिकी क़ानूनों के दायरे में आता है
    • ये दोनों क़ानून डेटा भौतिक रूप से कहीं भी हो, लागू हो सकते हैं
  • Section 702 को 2024 के अप्रैल में 2 साल के लिए फिर से मंज़ूरी दी गई थी, और 2026 के अप्रैल के अंत में हस्ताक्षरित 45-दिन के extension के ज़रिए यह जारी है
    • यह अमेरिका में स्थित electronic communication service providers के माध्यम से गैर-अमेरिकी लोगों को लक्षित करते हुए अमेरिकी intelligence agencies को data collection की अनुमति देता है
  • CLOUD Act अमेरिका-आधारित कंपनियों को दुनिया में कहीं भी स्टोर किया गया डेटा सौंपने के लिए मजबूर कर सकता है
  • GitHub ने 2024 के अक्टूबर में Enterprise Cloud के लिए EU data residency की general availability की घोषणा की
    • यह डेटा लोकेशन की समस्या को संबोधित करता है, लेकिन अधिकार-क्षेत्र की समस्या को हल नहीं करता
    • CLOUD Act का exposure भौगोलिक स्थान नहीं, बल्कि corporate control structure का अनुसरण करता है
  • Microsoft की ओर से एक वकील ने 2025 के जून में फ़्रांसीसी सीनेट की सुनवाई में शपथ के तहत यह कहा कि वह यह गारंटी नहीं दे सकते कि यूरोपीय Microsoft datacenter में रखा गया फ़्रांसीसी डेटा चुपचाप होने वाली अमेरिकी सरकारी पहुँच से सुरक्षित है
  • जब तक कोड github.com पर है, वह कोड अमेरिकी कानूनी दायरे में है
    • EU data residency भरोसा देने वाला तत्व हो सकता है, लेकिन यह समाधान नहीं है

नीदरलैंड सरकार का code.overheid.nl चुनना

  • नीदरलैंड सरकार के इस चयन की कानूनी पृष्ठभूमि 2020 से लागू “Open, tenzij” नीति है
    • सार्वजनिक धन से विकसित software को, जब तक security या confidentiality की ज़रूरत न हो, डिफ़ॉल्ट रूप से open source होना चाहिए
    • इसका पालन करने के लिए मंत्रालयों को कोड प्रकाशित करने के लिए ऐसी जगह चाहिए थी जिस पर उनका वास्तविक नियंत्रण हो
  • European Commission 2022 के सितंबर से self-hosted GitLab-आधारित code.europa.eu चला रही है
  • जर्मनी का openCode भी GitLab-आधारित है
  • फ़्रांस का code.gouv.fr अपना forge नहीं है, बल्कि दूसरी जगह होस्ट किए गए repositories को index करने वाला aggregator है
  • नीदरलैंड सरकार ने GitLab नहीं, बल्कि जानबूझकर Forgejo चुना
    • OSOR के अनुसार, वजह यह थी कि Forgejo पूरी तरह open source है, इसमें open-core separation नहीं है, और यह digital sovereignty के लिए ज़रूरी सभी स्वतंत्रताएँ देता है
    • Van Hoytema ने यह भी जोड़ा कि Forgejo का roadmap विकल्पों की तुलना में “way more aligned” था
  • नीदरलैंड सरकार केवल sovereign forge नहीं चाहती थी, बल्कि ऐसा sovereign forge चाहती थी जो किसी commercial vendor के premium tier के पीछे बंद न हो
  • सरकार ने भी उसी समस्या-ढाँचे को देखा और वही फ़ैसला लिया, और Forgejo का चयन अब एक हाशिए का विकल्प मानना मुश्किल है

Forgejo चुनने के कारण

  • GitLab पर भी गंभीरता से विचार किया गया था
    • self-hosted GitLab CE एक जाना-पहचाना विकल्प है, और इसका commercial ecosystem बड़ा है तथा UI अधिक polished है

  • लाइसेंस

    • GitLab open core मॉडल पर है
      • Community Edition MIT license के तहत है, लेकिन production environment में चाही जाने वाली कई सुविधाएँ non-free license वाले Enterprise tier में हैं
    • Forgejo ने उलटी दिशा चुनी
      • 2024 अगस्त के v9.0 से इसे MIT से GPLv3+ में relicense किया गया
      • इसका स्पष्ट लक्ष्य copyleft बनाए रखना और codebase को भविष्य में commercial capture से बचाना है
    • Forgejo को 2022 के दिसंबर में Gitea से fork भी इसलिए किया गया था क्योंकि Gitea Ltd ने community की सहमति के बिना trademark और domain पर नियंत्रण कर लिया था
      • वही सबक license चयन में भी दिखता है

  • governance

    • Forgejo, Codeberg e.V. के तहत है
      • Codeberg e.V. सितंबर 2018 से बर्लिन में पंजीकृत एक non-profit संस्था है
      • इसके पास members द्वारा चुना गया board, public budget, और hosting instance पर 300,000 से अधिक repositories हैं
    • सदस्य हर साल budget पर वोट करते हैं
      • 2025 की योजना 88 पक्ष में, 0 विरोध में, और 1 abstention के साथ मंज़ूर हुई

  • release और maturity

    • Forgejo v15.0 LTS 16 अप्रैल 2026 को रिलीज़ हुआ
      • यह प्रोजेक्ट की 100वीं release है
      • long-term support 15 जुलाई 2027 तक जारी रहेगा
    • Forgejo Actions v15 में ज़रूरी स्तर तक पहुँच गया
      • इसमें ephemeral runner, OpenID Connect, और reusable workflow expansion शामिल हैं
    • fork के बाद releases लगातार आती रहीं, और monthly reports भी सक्रिय रहीं

  • commercial ecosystem की सीमाएँ

    • Forgejo का commercial ecosystem मौजूद है, लेकिन बहुत पतला है
    • अभी सबसे साफ-सुथरा commercial product Codey by VSHN है
      • यह मार्च 2025 में Servala पर लॉन्च किया गया Swiss-hosted managed Forgejo है
      • इसकी शुरुआत 19 CHF प्रति माह से होती है
    • Red Hat-स्टाइल enterprise support subscription उपलब्ध नहीं है
    • अगर 24/7 phone support और जवाबदेही लेने वाला vendor चाहिए, तो आपको खुद बनाना होगा या इंतज़ार करना होगा

code.jorijn.com का सेटअप

  • code.jorijn.com home office में एक single Intel NUC पर चलता है
    • RAM 64GB है
    • Forgejo v15 LTS, Postgres 17, और Traefik Docker के अंदर चलते हैं
    • Incus-managed KVM virtual machine बगल में Forgejo Actions runner चलाती है
  • Forgejo, Postgres, और reverse proxy की deployment से भी ज़्यादा महत्वपूर्ण फ़ैसला runner का setup है

runner सबसे जोखिमभरा हिस्सा है

  • self-hosted forge में forge खुद आसान हिस्सा है, मुश्किल हिस्सा वह environment है जहाँ CI jobs चलती हैं
  • runner को हर दिन Renovate schedule के अनुसार npm install, composer install, pip install चलाना पड़ता है
    • target वे lockfile होते हैं जो अपने repositories से बने होते हैं
    • इसका मतलब lifecycle script execution है
    • हर job संभावित रूप से अविश्वसनीय code चला सकती है
  • जोखिम वैसा ही है जैसा हाल की npm worm और axios supply-chain attack में था, जो dependency bot के ज़रिए एक घंटे के भीतर auto-merge होकर फैल गए
  • runner की भूमिका कोड चलाना नहीं, बल्कि चल रहे कोड को isolate करना है
    • यह मानकर design किया जाता है कि एक single defense layer fail हो सकती है, ताकि अगली layer उस failure को absorb कर सके

runner सुरक्षा परतें

  • persistent KVM virtual machine

    • runner होस्ट के कंटेनर में नहीं, बल्कि अलग KVM VM के अंदर है
    • जॉब एनवायरनमेंट होस्ट kernel को साझा नहीं करता
    • runner के अंदर Linux kernel CVE को NUC तक पहुंचने के लिए पहले KVM boundary तोड़नी होगी

  • VM के अंदर default Docker runtime के रूप में gVisor का उपयोग

    • जॉब कंटेनर runsc के तहत चलते हैं
    • runsc system call को सीधे host kernel तक पास नहीं करता, बल्कि उन्हें user space में intercept करता है
    • कंटेनर escape के लिए gVisor और उसके बाहर की KVM layer दोनों को तोड़ना होगा

  • साप्ताहिक destructive rebuild

    • हर सोमवार 02:00 UTC पर पूरे VM को delete करके नई Ubuntu base image से फिर बनाया जाता है
    • Forgejo के लिए नया persistent runner registration भी फिर से जारी किया जाता है
    • base image रविवार को rebuild होती है, इसलिए नया VM उस हफ्ते के apt और kernel patch को reflect करता है
    • persistent state 7 दिनों से ज़्यादा नहीं रह सकती

  • runner bridge का nftables egress filter

    • runner सार्वजनिक destination के :443, :80, :22, :53 तक पहुंच सकता है
      • npm, pypi, ghcr, और hairpin NAT के ज़रिए public hostname से एक्सेस किया गया उसका अपना Forgejo इसमें शामिल है
    • 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 तक पहुंच नहीं है
    • compromise हुआ जॉब LAN को scan नहीं कर सकता और न ही router admin interface या host की दूसरी services तक पहुंच सकता है

  • scope-limited runner token

    • दो persistent runner registration क्रमशः single-user scope और single-organization scope से बंधे हैं
    • management के लिए write:user,write:organization PAT scope का उपयोग होता है
    • लीक हुआ token अपने scope के बाहर runner register नहीं कर सकता, और admin scope वाले काम भी नहीं कर सकता
    • परतों को जानबूझकर एक-दूसरे पर overlap करने के लिए बनाया गया है
    • हर परत एक बाड़ है, और मिलकर वे defense in depth boundary बनाती हैं
    • KVM isolation, gVisor, साप्ताहिक rebuild, और scope-bound runner registration, ये सब Forgejo और Incus द्वारा डिफॉल्ट रूप से समर्थित तत्व हैं

जिन चीज़ों को छोड़ा गया

  • discoverability और social graph

    • GitHub वह जगह है जहां contributors repositories ढूंढते हैं
    • जो लोग public repository में छोटा बदलाव भेजना चाहते हैं, वे किसी अनजान domain के बजाय github.com पर काम करने की उम्मीद करते हैं
    • migration पूरा होने पर हर public GitHub repository को archive करके README को code.jorijn.com की ओर point करने की योजना है
    • discoverability path बना रहेगा
      • लोग अब भी GitHub पर repository पाएंगे, archive notice देखेंगे, और फिर canonical home पर चले जाएंगे
    • यह अभी पूरा नहीं हुआ है; सिर्फ कुछ repositories ही code.jorijn.com पर हैं, बाकी अभी लंबित हैं

  • GitHub Actions ecosystem की नाज़ुक compatibility

    • Forgejo Actions का लक्ष्य compatibility नहीं, familiarity है
    • ज़्यादातर चीज़ें काम करती हैं, लेकिन कुछ नहीं करतीं
    • workflow-level permissions: block को चुपचाप ignore कर दिया जाता है
    • actions/checkout@v6 2026 की शुरुआत में non-GitHub runner पर authenticated checkout को तोड़ देता है, इसलिए इसे v5 पर pin किया गया है
    • actions/upload-artifact@v4 के लिए Forgejo-hosted fork चाहिए
    • OIDC काम करता है, लेकिन GitHub के permissions: id-token: write की जगह enable-openid-connect: true नाम की अलग workflow key इस्तेमाल होती है
    • अगर workflow GitHub-विशेष features पर बहुत निर्भर है, तो migration एक शाम में खत्म होने वाली चीज़ नहीं बल्कि एक project बन जाता है

  • Dependabot की अनुपस्थिति

    • Forgejo में Dependabot नहीं है
    • Renovate को उसी self-hosted runner पर हर 3 घंटे में चलाया जाता है
    • यह वही काम करता है, लेकिन configuration ज़्यादा मांगता है, और setup में एक दिन लगा

  • 24/7 vendor support

    • GitHub Enterprise फोन नंबर और SLA देता है
    • Forgejo issue tracker और chat room देता है
    • एक व्यक्ति द्वारा चलाए जा रहे setup के लिए यह काफ़ी है, लेकिन 200 engineers वाली organization के लिए शायद काफ़ी न हो

जब स्थानांतरण करना उचित नहीं है

  • अगर टीम में infra चलाने की इच्छा या क्षमता बिल्कुल नहीं है, तो self-hosted Forgejo पर जाना बेहतर विकल्प नहीं है
    • managed Forgejo जैसे Codey या FOSS के लिए Codeberg इस अंतर को काफी हद तक कम कर देते हैं, लेकिन migration cost फिर भी बनी रहती है
  • अगर आपने GitHub-विशेष features जैसे GitHub Apps marketplace, Codespaces, Copilot Workspace, Advanced Security में गहरा निवेश किया है, तो यह सही विकल्प नहीं है
    • Forgejo एक forge है, developer-platform-as-a-service नहीं
  • अगर contributor base GitHub social graph पर निर्भर है, तो discoverability ownership से ज़्यादा महत्वपूर्ण हो सकती है
    • आप वहीं रह सकते हैं जहां contributors हैं, या friction स्वीकार करके migration पूरा होने के बाद public GitHub repository को archive कर नई location की ओर point कर सकते हैं और बाद में फिर से आकलन कर सकते हैं
  • अगर runner के लिए आपके पास भरोसेमंद operational answer नहीं है, तो migration मुश्किल है
    • यही वह हिस्सा है जिसे सबसे गंभीरता से लेना चाहिए
    • अगर आप KVM isolation, gVisor, nftables, और साप्ताहिक rebuild पर गंभीरता से सोचने के लिए तैयार नहीं हैं, तो CI job को managed runner host पर चलाना या GitHub पर बने रहना बेहतर है
  • नीदरलैंड सरकार ने भी सब कुछ एक साथ migrate नहीं किया
    • code.overheid.nl ministries के लिए open source code साझा करने का एक soft-launch platform है, न कि उनके इस्तेमाल की हर चीज़ का पूर्ण प्रतिस्थापन
    • code.jorijn.com का setup भी इसी तरह का है
      • Forgejo canonical host है और GitHub mirror है; mirror के बारे में बाद में फिर से निर्णय लिया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • ऐसा लगता है कि GitHub को छोड़ते हुए सब लोग git की मूल भावना भूल रहे हैं
    git को मूल रूप से विकेंद्रीकृत होने के लिए बनाया गया था, और समस्या यह है कि GitHub ज़्यादा साफ-सुथरा, बेहतर स्केलेबल और बेहतर तरीके से मैनेज्ड था, इसलिए git के आसपास के सारे टूल GitHub पर केंद्रीकृत हो गए
    फिर भी अच्छा होगा अगर GitHub पर ऑटो-सिंक होने वाला एक मिरर बना रहे। मैंने वर्षों में कई प्रोजेक्ट्स को self-hosting या niche hosting पर जाते, फिर उनका GitHub मिरर बंद या हटते, और अंततः प्रोजेक्ट को समय के साथ गायब होते देखा है
    git विकेंद्रीकृत है और GitHub बस उन जगहों में से एक है जहाँ कोड अपलोड किया जा सकता है; आप कई remote servers पर push कर सकते हैं

    • git की भावना नहीं भूला हूँ, लेकिन मुझे यह भी याद है कि GitHub ने बिना किसी को बताए सभी public repositories पर पहला Copilot train किया था
      इसलिए मैं अब वहाँ अपना निजी कोड commit नहीं करूँगा
      मुझे discoverability, stars, या AI bots द्वारा भरे गए issues जैसी social features में दिलचस्पी नहीं है। अभी जैसा है, मेरे लिए काफ़ी है
      और यह भी याद रखना चाहिए कि “Open Source is not about You”
    • सही है, लेकिन GitHub git से बढ़कर है
      जिस बात को सब भूल जाते हैं, वह platform का सबसे महत्वपूर्ण पहलू है: उसका social component, और यह कि उसने स्थायी बाहरी repositories बनाना और repositories के बीच collaboration को बहुत आसान बना दिया
    • Forgejo टूल्स को भी विकेंद्रीकृत करने के लिए बहुत काम कर रहा है
      self-hosted forge instances को एक-दूसरे से जोड़ने के लिए public protocols और standards का इस्तेमाल करता है
    • हर कोई “git की भावना” से मोहित होकर git का इस्तेमाल नहीं करता
      जिस email patch model के लिए इसे मूल रूप से बनाया गया था, उसे बहुत कम लोगों ने इस्तेमाल किया है, और बाकी अधिकांश शायद उसे सीखने का इरादा भी नहीं रखते
      लोग मूल रूप से GitHub इस्तेमाल होने के कारण git इस्तेमाल करते हैं, या थोड़ा उदार होकर कहें तो इसलिए कि यह GitHub जैसे centralized host के साथ जुड़ने पर अच्छी तरह काम करता है
      लोग local में code develop करने और web portal पर issues और patches पर चर्चा करने वाले model की ओर आकर्षित होते हैं, और उसमें git खुद बहुत छोटा हिस्सा देता है
    • सहमत। git repository को ले जाना आसान है, लेकिन पूरे project surface area को ले जाना मुश्किल है
      issues, releases, CI, docs, security advisories, search और discoverability समय के साथ सब GitHub से बँधते जाते हैं
      अगर यह open source project है, तो बेहतर है कि self-hosting को source of truth रखा जाए, लेकिन एक read-only GitHub mirror भी बनाए रखा जाए ताकि लोग उसे वास्तव में ढूँढ सकें

  • सच में खेल बदलने वाली चीज़ पूरी तरह तैयार federation support होगी
    इसी वजह से मैं Forgejo और Codeberg को donate कर रहा हूँ, और सबको प्रोत्साहित करता हूँ कि Forgejo team इसे सही से implement कर सके, इसके लिए और समय व संसाधन दें
    एक और अच्छा उम्मीदवार है Radicle, जो Git के ऊपर पूरी तरह विकेंद्रीकृत है
    https://codeberg.org/forgejo-contrib/federation/src/branch/m...
    https://liberapay.com/forgejo
    https://donate.codeberg.org/
    https://radicle.dev/
    https://radicle.network/nodes/seed.radicle.dev

    • Federation विकेंद्रीकरण का सबसे खराब मॉडल है। सहयोग बहुत ढीला-ढाला हो जाता है

  • मैंने अपनी git repository भी self-hosted NUC पर शिफ्ट कर दी है
    अभी तक मैंने उसे दुनिया के लिए साझा करने वाला HTTP frontend नहीं जोड़ा है, क्योंकि मैं AI scrapers को content देना नहीं चाहता और न ही उन्हें block करने का काम करना चाहता हूँ
    open source से फायदा उठाने वाली कंपनियों ने industry को इस तरह प्रदूषित किया है, यह शर्मनाक है

    • मैं NUC पर Gitea चला रहा हूँ, और सेकंड-हैंड hardware होने की वजह से इसकी लागत लगभग 50 पाउंड आई
      यह 3 साल से चल रहा है। अगर आप इसे सिर्फ LAN access तक सीमित रखें और internet पर expose न करें, तो यह काफ़ी मज़बूत और लंबे समय तक चलने वाला setup है
    • मैं Pi पर self-hosted Forgejo को GitHub mirror की तरह चला रहा हूँ, लेकिन शायद ज़्यादा समय तक नहीं
      repository कुछ हफ्तों तक ठीक से mirror होती है, फिर रुक जाती है। मैंने non-expiring PAT token डाला है, फिर भी यह कहता है कि token expire हो गया, जबकि दूसरी जगह test करने पर token सही काम करता है
      कभी logs में कुछ नहीं होता, और कभी database locked होता है। database का इस्तेमाल सिर्फ Forgejo ही कर रहा है
      अब तक मैं यह नहीं समझ पाया कि यह Forgejo की समस्या है, Pi के खराब SD card I/O की वजह से database lock हो रहा है, या Forgejo बस mirror की भूमिका ठीक से निभा नहीं पा रहा
    • open source और OSI industry द्वारा लगाए गए जाल हैं। बस देख लो कि इन्हें sponsor कौन करता है
      proprietary hyperscale cloud कंपनियाँ मुफ्त श्रम लेती हैं, और उसी से वह दुनिया बनाती हैं जिसे हम नापसंद करते हैं: tracking-surveillance web, ऐसे फ़ोन जिन पर आप मनमाना install नहीं कर सकते, device attestation, ad blocking के बिना browser monoculture
      Google ने लोगों को BSD/MIT से प्यार करना सिखाया, और नतीजा सामने है
      एक आम चाल है, “अब यह हमारा है।” अगर Elasticsearch या Redis जैसी चीज़ कोई vendor बनाता है, तो hyperscale cloud उसे अपने proprietary product के रूप में ले जाकर सारा मुनाफ़ा खा जाता है, और मूल लेखक व कंपनी भूखे रह जाते हैं
      दूसरी चाल है “embrace, extend, extinguish.” वे KHTML या Linux जैसे open source projects लेते हैं, अपना version बनाते हैं, उसे market में फैलाकर competitors को बाहर करते हैं, anti-competitive तरीकों से अपना product सबकी आँखों के सामने रखते हैं, और market share मिलते ही tracking जोड़ते हैं और आज़ादी हटा देते हैं
      open source की जगह “लोगों के लिए आज़ादी, कंपनियों के लिए भुगतान” वाला मॉडल आना चाहिए। हमें hyperscale cloud के ख़िलाफ़ दाँत वाला source-available shareware चाहिए
      Richard Stallman का license भी काफ़ी मज़बूत नहीं है; मुझे CC BY-NC-SA बेहतर लगता है
      “शुद्ध” open source corporate welfare था और एक गलती थी। हमने दिग्गजों को हमारी ही रस्सी से हमें लटकाने दिया
    • अगर कोई अपना काम खुशी-खुशी open source में देता है, तो AI उसका कोड पढ़े और उससे ज्ञान ले ताकि बाद में और programmers की मदद हो, इसके ख़िलाफ़ रेखा कहाँ खींचनी चाहिए, मैं नहीं समझता
      मैं तो चाहूँगा कि AI मेरा code उत्साह से पढ़े

  • लेख के “What I gave up” सेक्शन में लेखक ने अपने social graph का ज़िक्र किया था, लेकिन GitSocial इस्तेमाल करने पर आप social graph और collaboration history साथ ले जा सकते हैं
    यह किसी भी git host के बीच forge-to-forge pull requests संभव बनाता है, और पूरी तरह बिना third-party dependencies के काम करता है

    • GitHub एक social network है, और git hosting उसका बस एक छोटा feature है
      इसलिए ऐसे alternatives मुश्किल से पकड़ बना पाते हैं

  • लेख में “CTO ने public apology दी और कहा कि AI-आधारित load संभालने के लिए capacity को 30 गुना बढ़ाना पड़ेगा” पढ़कर उम्मीद है कि GitHub सामान्य usage पर billing शुरू न करे
    लेकिन जब कुछ vibe coders को रोज़ हज़ारों commits बनाते देखता हूँ, तो मैं धीरे-धीरे और संशय में पड़ता जा रहा हूँ
    अगर हम code को मुफ्त में share और collaborate नहीं कर पाए, तो यह सच में दुखद होगा

    • एक तय सीमा के बाद daily commit count पर शुल्क लगा दो। समस्या हल
    • सच कहूँ तो लगता है LLM इस समस्या को, जो उन्होंने खुद बनाई है, हल करने में भी मदद करेंगे
      कोई अनुभवी व्यक्ति repository में ऐसी समस्या हो तो उसे कुछ ही सेकंड में पहचान सकता है, तो tuned system भी संभव होना चाहिए
      मुश्किल हिस्सा है ऐसे legal terms लिखना जो vibe quotas लागू करने दें
      Anthropic पहले से CC में ऐसा करता है, और शायद GitHub व GitLab भी कुछ ऐसा ही करेंगे। इसकी कीमत होगी Twitter developers और कुछ छोटे subreddits की नफ़रत, लेकिन शायद यह काफ़ी उचित सौदा है
      दूसरी तरफ, /r/vibecoding जैसी जगहों पर लोगों को महीने के 200 डॉलर subscription देकर hobby projects या toy sites जैसी चीज़ें बनाते देखना काफ़ी चौंकाने वाला है
      मैंने भी कभी-कभी वहन कर सकने पर मूर्खतापूर्ण ख़र्च किया है, लेकिन यह कुछ अलग लगता है
      शायद यह अर्थ और उद्देश्य देने वाली किसी सेवा के लिए सालाना 2400 डॉलर चुकाने जैसा है। अगर आप 40 की उम्र के आसपास समझते हैं कि आप न अमीर होंगे न मशहूर, तो बाकी विकल्पों की तुलना में यह क़ीमत काफ़ी वहनीय लग सकती है

  • मैंने Tangled नाम की एक विकेंद्रीकृत सेवा के बारे में भी सुना है, जो Bluesky की तरह AT Protocol पर बनी है
    इसमें stacked pull requests जैसी वास्तव में उपयोगी features भी हैं, जिन्हें GitHub ने implement करने में इतना देर लगाई कि इस functionality को GitHub में जोड़ने वाली कंपनियाँ तक बन गईं
    जानना चाहता हूँ कि किसी ने इसे इस्तेमाल किया है या नहीं
    https://tangled.org/

    • मैंने हाल ही में self-hosted Knot सेट किया है, लेकिन दूसरी features अभी ज़्यादा इस्तेमाल नहीं की हैं
      https://tangled.org/h14h.com/knot
      कुल मिलाकर platform काफ़ी promising लगता है। AtProto जिस तरह personal data servers, relays और AppView को अलग करता है, वह एक सही समझौता लगता है
      आप git repository को headless, data-only server की तरह host कर सकते हैं, इसलिए self-hosting के हिसाब से इसमें लगभग कोई दर्द नहीं है
      Forgejo जैसी ActivityPub approach की तुलना में, मैं data control की ही परवाह करता हूँ, इसलिए पूरा webapp host और scale करने की झंझट से बचना अच्छा लगता है
      शुरुआती setup के बाद maintenance बस knot-server version bump करके फिर deploy करने तक सीमित रही है। अगर tangled.org पुराना version चला रहा हो, तो वह warning banner दिखा देता है
      मैं दूसरे projects में Tangled को और इस्तेमाल करके इसकी features test करना चाहता हूँ। खासकर jj और stacked PR के native support में दिलचस्पी है
    • यह निश्चित रूप से alpha software है, लेकिन open source उपयोग के लिए काम चलाऊ है
      tack जैसे custom CI जोड़ने वाले दिलचस्प प्रयोग भी हैं
      अगर ATProto कभी private data support करने लगे, तो शायद भविष्य में private repositories भी संभव हों, लेकिन इसमें समय लग सकता है
      https://tangled.org/mitchellh.com/tack
    • इसे अभी-अभी बड़ी venture investment मिली है
      अभी तक business model का कोई ज़िक्र नहीं हुआ, इसलिए सच में जिज्ञासा है कि यह क्या बनेगा
    • मैं इसे jj compatibility और साफ-सुथरे CI implementation की वजह से इस्तेमाल करना चाहता हूँ, लेकिन मुझे private repositories चाहिए, इसलिए अभी यह मेरे लिए सही नहीं है
    • मेरी पसंद के लिए यह कुछ ज़्यादा ही विकेंद्रीकृत है
      इसकी जगह radicle.xyz इस्तेमाल करना बेहतर है

  • Fossil पर भी विचार किया जा सकता है
    यह code history, wiki, tickets और forum सहित repository की पूरी state को एक single file में बाँध देता है, और वही state replicate होती है
    अगर आपको hosting provider बदलना पड़े, तो Fossil में उस वजह से कोई data loss नहीं होता
    https://fossil-scm.org/

    • मुझे Fossil पसंद है। उसके opinionated workflow में कुछ ऐसा है जो मेरी सोच से मेल खाता है
      लेकिन network effects समस्या हैं। मैं team को Fossil पर नहीं ला सकता
      team को दूसरे लोगों और दूसरे departments के साथ code share करना होता है, और लगभग सब, सच कहें तो 99% से ज़्यादा, git इस्तेमाल करते हैं
      Fossil इस्तेमाल करने के लिए मजबूर करना उल्टा नुकसानदायक लगता है, और यही दुविधा है
      यह tech की कई दूसरी चीज़ों जैसा है। जैसे सहकर्मी developers को functional-style idioms इस्तेमाल करने या immutability थोपने की कोशिश करना
      लगता है जैसे Facebook या Google project जैसी किसी बहुत बड़ी चीज़ को community को जबरन हिलाना पड़ेगा
    • मैंने कुछ साल पहले Fossil को देखा था और यह सच में शानदार लगा था। सब कुछ integrated होना बहुत अच्छा है
      लेकिन दार्शनिक रूप से मुझे Fossil पसंद नहीं है। history को साफ़-सुथरा करने का कोई तरीका नहीं है; यह सब कुछ जस का तस रखता है
      अगर आपको वही चाहिए तो ठीक है, लेकिन अपने git workflow में मुझे push करने से पहले तरह-तरह के experiments के बाद commits को साफ़ और organize करना पसंद है

  • लोग लगातार विकेंद्रीकरण की बात करते रहते हैं
    लेकिन व्यवहार में ज़्यादातर systems अंत में centralized हो जाते हैं
    शायद जब लोग विकेंद्रीकरण माँगते हैं, तो वे असल में एक नया केंद्र ढूँढ रहे होते हैं जहाँ वे खुद नए pioneers बन सकें
    जब उन्हें लगता है कि मौजूदा नियमों के तहत उनके जीतने की संभावना नहीं है, तो वे विकेंद्रीकरण को बहाना बनाकर खेल का मैदान बदलना चाहते हैं

    • काश मैंने title के ठीक नीचे पहली पंक्ति ही पढ़ ली होती: “I moved my code from GitHub to a self-hosted Forgejo”
    • विकेंद्रीकरण का मतलब है कि कोई एकल केंद्र न हो
      लोग इसे इसलिए चाहते हैं क्योंकि वह एकल केंद्रीय प्रशासन किसी न किसी वजह से पर्याप्त नहीं होता
      लोग इसकी बात करते हैं और लोग इसे वास्तव में चाहते हैं — इन दोनों में कोई फ़र्क नहीं है
    • लोग विकेंद्रीकरण के फ़ायदे चाहते हैं, लेकिन उसकी कीमत नहीं चुकाना चाहते
      इससे भी बुरी बात यह है कि centralized systems अधिकांश समय शानदार होते हैं, और दर्द merger या अचानक price hike जैसी चीज़ों में बहुत कम समय के लिए बहुत तीखा आता है
      विकेंद्रीकरण हमेशा थोड़ा-थोड़ा दर्द देता है, लेकिन उन दुर्लभ क्षणों में बहुत बड़ी राहत देता है जब centralized alternative टूट जाता है
    • यह बस developers वाला “विकेंद्रीकरण” शब्द है
      आम भाषा में इसे बहिष्कार कहते हैं। कोई यह नहीं कहता कि “snacks Nestlé में बहुत centralized हो गए हैं, इसलिए snacks को decentralize करना चाहिए”
    • मुझे लगता है कि लोगों को असल में जिस चीज़ की ज़रूरत है, उसका जवाब विकेंद्रीकरण नहीं बल्कि portability है

  • मैं Tangled की ओर migrate कर रहा हूँ, और क्योंकि यह AT Protocol पर बना है, इसलिए Bluesky वगैरह जैसा वही account इस्तेमाल करता है
    इस्तेमाल करके अच्छा लगा
    https://vale.rocks/micros/20260511-0440

  • एक साल पहले मैं अपने homelab में self-hosted Gitea पर चला गया और public access बंद कर दिया
    HTTPS भी नहीं है, sign-up disabled है, और repositories भी public नहीं हैं
    मैं सोच रहा हूँ कि क्या public instance बनाऊँ और HTTPS इस्तेमाल करूँ, लेकिन attack surface न्यूनतम रखूँ; खासकर Gitea/Forgejo के लिए सुझाव जानना चाहूँगा

    • मैंने ऐसा किया है। fly.io proxy पर nginx और fail2ban चलाता हूँ, फिर उसे अपने tailnet की ओर forward करता हूँ, जहाँ Caddy असली instance resolve करता है
      local sign-up disable करना महत्वपूर्ण है। मेरे मामले में मैं authentik को IdP की तरह इस्तेमाल करता हूँ, जो सिर्फ tailnet से accessible है। या फिर आप पहले अपना account बना सकते हैं और उसके बाद sign-up बंद कर सकते हैं
      मैंने robots.txt से कुछ चीज़ें block की हैं, जैसे individual rendered git commit views। नहीं तो scrapers कभी ख़त्म न होने वाले loop में फँस जाते हैं
      Forgejo package repository access को भी मैंने सख़्ती से रोका हुआ है, क्योंकि मेरे पास private packages हैं और वहाँ permission granularity अभी मेरी ज़रूरत के मुताबिक नहीं है
      मैं इस पर नज़र रखे हुए हूँ और अब तक कोई बड़ी समस्या नहीं आई। और जानकारी docs.eblu.me पर है, और चाहो तो मैं सीधे infra code भी शेयर कर सकता हूँ
    • मैंने पहले ऐसा किया था, और अब भी internal/LAN Forgejo instance चला रहा हूँ, लेकिन public instance इस समय नहीं है
      पहले मैंने internal instance को mirror करने वाला एक public read-only instance लगाया था, और internal से public instance तक एक reverse proxy connection रखा था ताकि public side git data pull कर सके
      उसके बाद यह ज़्यादातर अपने आप ठीक से चलता रहा, और internal Forgejo में कुछ बदलने पर public side भी update हो जाती थी
      issues, CI वगैरह पूरी तरह private रह सकते थे और LAN के भीतर ही रखे जा सकते थे
    • मैंने Forgejo इसलिए अपनाया क्योंकि Forgejo ने Gitea के बारे में जो security issues उठाए थे और जिन्हें Gitea ने नज़रअंदाज़ किया, उनके इर्द-गिर्द की राजनीतिक बहस मुझे पसंद नहीं आई
      इसलिए मैं जानना चाहता हूँ कि आप अभी भी Gitea क्यों इस्तेमाल कर रहे हैं। सोच रहा हूँ कि क्या अब Forgejo की जगह Gitea को फिर से आज़माना चाहिए