अगर मैं अपना खुद का GitHub बनाता

 (matduggan.com)
5 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub, GitLab, Gitea जैसे आधुनिक forge GitHub-शैली के मॉडल को साझा करते हैं, लेकिन असली काम का केंद्र git से ज़्यादा PR, Actions, Issues, Releases जैसी forge सुविधाओं के भीतर होता है
  • एक नए forge को commit के बाद नहीं बल्कि push से पहले feedback देना चाहिए, इसके लिए अनिवार्य pre-commit hook को remote पर चलाया जाना चाहिए, ताकि Feature, fix, actually fix, asdfasdf जैसे दोहराए जाने वाले commit कम हों
  • PR approval को approve/reject जैसी दो-विकल्पीय सोच से आगे बढ़कर Gerrit की तरह weak approval और बाद में फिर देखने का संकेत support करना चाहिए, और अगर लेखक maintainer है तथा LLM बदलाव को low-risk मानता है तो छोटे बदलावों को अधिक लचीले तरीके से पास किया जा सके
  • Stacked PR, forge और VCS दोनों में first-class feature होने चाहिए, और local repository को सिर्फ code नहीं बल्कि PR approval और issue सहित पूरे repository state को दर्शाना चाहिए
  • मनचाहा संयोजन है VCS के रूप में JJ, छोटे यूनिट में host किया जा सकने वाला नया forge, और ऐसे Actions जो signing, SHA, और offline execution को support करें; लेकिन GitHub जैसे एकल विशाल forge के default बने रहने वाले दौर में अभी तक कोई साफ़ विकल्प नहीं है

आधुनिक forge की समस्या

  • GitHub, GitLab, Gitea में बारीक अंतर हैं, लेकिन ये लगभग एक ही design model का पालन करते हैं, और ज़्यादातर यह GitHub द्वारा बनाए गए industry pattern को दूसरे tools में ले आने जैसा है
  • मौजूदा forge की अधिकांश functionality का git से सीधे बहुत कम संबंध है, और client वास्तविक usage pattern से कटा हुआ है
  • git एक distributed version control system है जो kernel development जैसे माहौल के लिए बहुत उपयुक्त है, जहाँ patches को email से maintainer को भेजा जाता है, maintainer अपने क्षेत्र को संभालते हैं और merge करना है या नहीं यह तय करते हैं; यह high-trust workflow के लिए सही बैठता है
  • लेकिन अधिकांश workplaces में git बस central forge में रखे repository से code pull/push करने का साधन भर है, और महत्वपूर्ण काम forge के अंदर होता है
    • Pull Request, four-eyes principle लागू करने का माध्यम बन जाता है
    • GitHub Actions, Pull Request में tests और linting चलाकर functionality और organizational requirements की जाँच करता है
    • forge के भीतर user identity, user verification का आधार बनती है
    • Issues का उपयोग code समस्याओं को track करने के लिए होता है, और Releases का उपयोग users के लिए downloadable release बनाने में होता है
  • ऐसे workflow में git से ज़्यादा git के ऊपर बनी forge functionality शामिल है, इसलिए अगर नया forge बनाया जाए तो उसे git की सीमाओं से अनिवार्य रूप से बँधे रहने की ज़रूरत कम हो जाती है

नए forge से अपेक्षित सुविधाएँ

  • feedback commit के बाद नहीं, commit से पहले आना चाहिए

    • आम PR में Feature, fix, fix, actually fix, please, asdfasdf जैसे commits की श्रृंखला लग जाती है
    • अगर feedback loop commit के बाद आता है, तो users को देर रात तक fixes करते हुए परेशान होना पड़ता है
    • forge को remote पर काम चलाने वाला अनिवार्य pre-commit hook देना चाहिए, ताकि user push करने से पहले feedback पा सके

  • PR approval बहुत ज़्यादा binary है

    • अभी PR या तो approved होता है या नहीं, लेकिन वास्तविक code review में इनके बीच बहुत-सी स्थितियाँ होती हैं
    • “फिलहाल ठीक है, बाद में निपटते हैं” जैसी मानवीय प्रतिक्रिया भी किसी button से व्यक्त की जा सकनी चाहिए
    • Gerrit इस मामले में बेहतर model देता है
    • अगर maintainer weak approval देता है, तो उसे बाद में फिर देखने के लिए mark किया जा सकना चाहिए

  • PR policy अधिक लचीली होनी चाहिए

    • हर बदलाव के लिए four-eyes review ज़रूरी नहीं होता, खासकर LLM के मौजूद होने वाले माहौल में
    • चार लाइन के PR पर किसी senior engineer के सिर्फ LGTM लिखने का इंतज़ार करना बहुत महँगा पड़ता है
    • अगर लेखक maintainer है और LLM इसे low-risk या no-risk बदलाव मानता है, तो इसे तुरंत आगे बढ़ाने का नियंत्रण आसान होना चाहिए

  • Stacked PR first-class feature होने चाहिए

    • Stacked PR review और समझ, दोनों को आसान बनाते हैं
    • इन्हें VCS के बाहर किसी add-on feature की तरह नहीं, बल्कि forge और VCS दोनों में first-class citizen की तरह माना जाना चाहिए

  • forge को सब कुछ करने की कोशिश नहीं करनी चाहिए

    • issue tracking ज़रूरी है, लेकिन शायद Kanban board ज़रूरी नहीं है
    • Wiki की आवश्यकता भी संदिग्ध है
    • हर feature ठूँस देने वाले tools की quality अंततः गिरती है, और features जोड़ना आसान हो सकता है, लेकिन maintenance cost adoption rate से स्वतंत्र होकर लगातार बनी रहती है
    • कहीं कोई इसका इस्तेमाल शुरू कर दे, तो आप उस feature से बँध जाते हैं

  • hosting unit बहुत बड़ा है

    • GitHub Enterprise चलाना बड़ा काम है, और GitLab चलाना भी काफ़ी भारी पड़ता है
    • ये products बहुत-से moving parts वाले complex systems हैं
    • छोटे-छोटे individual hosting units बनाए जा सकें और उन्हें जोड़कर एक organization बनाई जा सके, ऐसा होना चाहिए
    • global federation होना ज़रूरी नहीं, और हर organization के लिए अलग account बनाना भी स्वीकार्य है, लेकिन organization इतनी flexible हो कि वह कह सके, “ये 12 Raspberry Pi ही मेरी organization हैं”

  • local repository को सिर्फ code नहीं, पूरे repository को दर्शाना चाहिए

    • local copy को सिर्फ code नहीं बल्कि PR approvals और issues सहित पूरे repository को represent करना चाहिए
    • जिस VCS से code check in होता है, उसी से PR approve भी किए जा सकें
    • issues को ऐसे देखा जा सके जैसे local files को browse करते हैं

  • हमेशा पूरी history store करने की लागत उठाना ज़रूरी नहीं

    • team के साथ ठीक से काम करने के लिए online रहना पड़ता है, इसलिए हर समय पूरा storage cost उठवाना ज़रूरी नहीं है
    • VCS और forge को साथ मिलकर काम करना चाहिए
    • repository clone करते समय सीमित history ही मिले, और जब अतीत में जाना हो तो worker उठाकर ज़रूरी सामग्री VCS से ले आए
    • सिर्फ इस संभावना के कारण कि user कभी पूरे project history से forge को फिर से rebuild कर सकता है, forge को लगातार विशाल clone requests भेजना ज़रूरी नहीं होना चाहिए

  • Actions signed होने चाहिए, SHA के साथ होने चाहिए, और offline भी चलने चाहिए

    • Actions महत्वपूर्ण हैं, इसलिए signing, SHA, और offline usability ज़रूरी है
    • अगर user चाहे, तो सभी actions के tarball डाउनलोड करके repository में रख सके, और system को यह निर्देश दे सके कि checkout action को बाहर से लाने के बजाय local repository के अंदर वाले का उपयोग करे
    • latest specify करने पर यह मौजूदा Dependabot की तरह काम करे, यानी नवीनतम tarball को repository में जोड़ने वाला PR खोले
    • Actions को चाहें तो उसी VCS के माध्यम से local machine पर भी चलाया जा सके

कुछ tools पहले से यह आंशिक रूप से करते हैं, लेकिन संयोजन की ज़रूरत है

  • इन आवश्यकताओं का कुछ हिस्सा पूरा करने वाले tools पहले से बहुत हैं
  • ज़रूरत इस बात की है कि इन tools को साथ लाया जाए, जोड़ा जाए, और सही तरह से फिट किया जाए
  • मनचाहा संयोजन है VCS के रूप में JJ, forge के रूप में एक नया system, और यह अपेक्षा कि user लंबे समय तक एक Raspberry Pi को forge की तरह संतोषजनक ढंग से इस्तेमाल कर सके
  • नए forge को object storage, shallow clone, और LLM bot की लगातार आने वाली requests जैसी आधुनिक अवधारणाओं को केंद्र में रखकर design किया जाना चाहिए

GitHub के default बने रहने वाले दौर में दरार

  • अगर GitHub यह काम अच्छी तरह कर रहा होता, तो ऐसी कल्पना लिखने की ज़रूरत ही नहीं पड़ती
  • GitHub default है, और default से आगे बढ़ने के लिए मनाना अक्सर लगभग समय की बर्बादी जैसा होता है
  • 2026 तक अगर कोई forge इस्तेमाल करता, तो सबके इस्तेमाल वाले tool को न चुनने के लिए बहुत मज़बूत कारण चाहिए होता
  • हाल तक दूसरे forge वास्तव में इच्छित विकल्प नहीं बल्कि substitutes जैसे लगते थे
  • लेकिन यह एकल विशाल forge अब दरक रहा है, और उसका विकल्प अभी बना नहीं है
  • जिनके पास पैसा है वे rockets में व्यस्त हैं, जिनकी अपनी पसंद है वे अपने day job में व्यस्त हैं, और बाकी लोग आधी रात को asdfasdf नाम का PR खोलकर robot checks का इंतज़ार करते हुए सोचते हैं कि जो tool वे पूरे दिन इस्तेमाल करते हैं, वह कब से users के लिए बनाया जाना बंद हो गया

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

1 टिप्पणियां

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

  • PR approval को बहुत ज़्यादा द्विआधारी मानकर की गई आलोचना विरोधाभासी लगती है। PR approval असल में permission देना है, इसलिए अंततः यह boolean ही होगा; या तो आप code merge कर सकते हैं या नहीं
    यहाँ असल बात शायद उस मानसिक सहारे की है जिसमें आप नापसंद code को approve करते हुए “इसे बाद में फिर देखना होगा...” जैसा कुछ कहकर खुद को थोड़ा सहज कर लेते हैं। बस एक नया ticket खोल देना चाहिए

    • Gerrit में -2 से +2 तक होता है
      -2: बुरा विचार है, मत करो
      -1: अच्छा विचार है, लेकिन सुधार चाहिए
      +1: ठीक लग रहा है, लेकिन approve करने का ज्ञान या अधिकार नहीं है
      +2: approval
    • काश ऐसा कोई button होता जिससे कहा जा सके, “इन 3 commits को अभी approve और merge करो, और इन 2 को दोबारा काम चाहिए”
    • कभी-कभी code approve हो जाता है लेकिन merge नहीं होता। ऐसे में कोई maintainer बदलाव जोड़कर उसे manually apply कर सकता है, और उस change commit में PR लिखने वाले को co-author भी बना सकता है
    • इससे भी बड़ी समस्या शायद यह है कि GitHub issue tracking system से बहुत अलग-थलग है। बार-बार manually sync करना भारी पड़ता है, और Linear कुछ हद तक मदद करता है, लेकिन वह आदर्श नहीं है
    • “या तो code merge हो सकता है या नहीं” — लगता है कोई intuitionist नहीं है

  • “Y भी इसका कुछ हिस्सा करता है” यह बात सही है, लेकिन tangled.org वास्तव में इसका अधिकांश करता है

    1. version control system के रूप में JJ का उपयोग: tangled, jj change-id के साथ stacked PR को support करता है. https://blog.tangled.org/stacking tangled खुद भी इसी तरीके से काफी बनाया गया है: https://tangled.org/tangled.org/core/pulls
    2. ऐसा forge जो Raspberry Pi पर लंबे समय तक चल सके: यह भी संभव है। git server shim बहुत हल्का है; यह बस git repository के ऊपर XRPC layer और sqlite3 database है। कुछ लोग इसे 512MB RAM वाले RISC-V board पर भी चला रहे हैं
    3. Actions महत्वपूर्ण हैं और local machine पर चलने चाहिए: मुझे लगता है यह माँग थोड़ी गलत दिशा में है। hermetic, हर जगह चल सकने वाले, और cross-build संभालने वाले सिस्टम आम तौर पर build system का काम हैं। अगर उन build results को forge में ही “promote” किया जा सके, तो वह वाकई अच्छा होगा
    • यह थोड़ा चौंकाने वाला है कि workflow के लिए महत्वपूर्ण data host करने में Raspberry Pi का ज़िक्र आया। पहले SD card corruption ने बहुत परेशान किया था; सोच रहा हूँ क्या अब लोग NVME drive इस्तेमाल करते हैं
    • हाँ, यह build system का ही काम है। लेकिन लोग local में चलने वाले Actions से जो समस्या हल करना चाहते हैं, वह अक्सर build failure नहीं बल्कि पूरी integration होती है
      जैसे YAML definitions, secrets, ठीक कौन-से commands चल रहे हैं, tools और cache कैसे restore हो रहे हैं। build system इसका कुछ हिस्सा संभाल सकता है, लेकिन GHA की raw functionality बहुत कमजोर है। आखिरकार बात फिर पूरी system को कहीं और चलाने की समस्या पर ही आ जाती है, इसलिए ऐसे systems अक्सर trial-and-error वाले बन जाते हैं
    • सही, और उससे भी आगे, hermetic build की अवधारणा को बढ़ाकर ऐसा बनाना अच्छा होगा कि उसे local में या जहाँ भी compute resources हों, आसानी से चलाया जा सके
      असली समस्या यह है कि changes, commits, और network calls वाले चक्र में CI के green होने तक बार-बार घूमना बहुत दर्दनाक है। इस iteration से बचने का सबसे अच्छा तरीका है कि कभी bug लिखो ही मत! मज़ाक कर रहा हूँ
    • Radicle और Tangled दोनों ही मूल बात चूक जाते हैं। ये public collaboration work के लिए हैं, लेकिन private repositories का क्या? बहुत से लोग side projects करते हैं और उसके लिए GitHub private का उपयोग करते हैं
      अगर लोग GitHub सीखते हैं, तो public projects भी वहीं शुरू करते हैं। जब तक side projects के लिए private repositories बनाने की सुविधा नहीं होगी, इसे व्यापक रूप से अपनाना मुश्किल रहेगा। लोग चाहते हैं कि वे private repo बनाएँ, कुछ महीनों के लिए दूर हो जाएँ, और लौटने पर वह वैसे ही उनका इंतज़ार करता मिले
    • वाह, Tangled का jujutsu support वही है जिसकी मैं तलाश कर रहा था। लगता है यह weekend self-hosting setup में निकल जाएगा

  • अगर आप सीमित history ही clone करना चाहते हैं और ज़रूरत पड़ने पर पुराना data लाना चाहते हैं, तो blobless clone इस्तेमाल कर सकते हैं
    git clone --filter=blob:none
    इससे history आ जाती है, और blobs सिर्फ ज़रूरत पड़ने पर आते हैं। GitHub पर इस पर एक अच्छा लेख है: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • जब समाधान ही समस्या बनने लगे, तो disruptive innovation का मौका खुलता है। आजकल यह बात काफी हो रही है, और सोचता हूँ कि GitHub दिशा बदलने से पहले उभरते हुए कई विकल्पों में से कोई एक momentum पकड़ पाएगा या नहीं

    • मुझे लगता है समस्या यह है कि Microsoft ने AI पर पूरी तरह दाँव लगा दिया है। अब वापसी का रास्ता नहीं है, और GitHub भी उससे प्रभावित हुए बिना नहीं रह सकता
      Microsoft की PR मशीन भले कहे कि AI हर चीज़ का हल है, लेकिन वास्तविकता में वही समस्याएँ बार-बार लौटेंगी। GitHub outages का AI से सीधा संबंध न भी हो, तब भी Microsoft की strategy पहले ही बदल चुकी है, इसलिए ज़्यादातर फैसले AI-केंद्रित top-down control के हिसाब से होंगे। GitHub इस्तेमाल करने वालों का workflow टूटता है या नहीं, Microsoft के लिए वह ज़्यादा से ज़्यादा एक गौण चिंता है, और यह समस्या बार-बार लौटती रहेगी। शायद 3 महीने तक शांति रहे, लेकिन जल्द ही GitHub के पतन पर नया drama 100% फिर आएगा। Ghostty आख़िरी नहीं होगा। विकल्प आएँगे या नहीं यह दिलचस्प है, लेकिन वे घटिया नहीं होने चाहिए, जबकि बहुत-सी websites काफ़ी खराब हैं
    • मैं अपने tools खुद बना रहा हूँ। मुझे लगता है लोगों को भी अपने tools खुद बनाने चाहिए
      शायद भविष्य में paid software या open source software की जगह code forge के लिए requirements documents का कोई bundle मिलेगा, एक तरह की recipe। हर कोई उसे खुद bake करेगा और अपनी ज़रूरत व पसंद के हिसाब से बदलेगा

  • मुझे लगता है कि कहीं न कहीं एक बहुत सरल git service के लिए बाज़ार में जगह है। ज़रूरत बस इतनी है कि कोई remote host हो जहाँ project push किया जा सके ताकि दूसरे लोग उसे देख सकें; PR या Actions जैसी चीज़ें विशेष रूप से नहीं चाहिए
    local में बने binary assets अपलोड करने के लिए “releases” feature जैसा कुछ हो तो अच्छा रहेगा। forks को लोग repository clone करके और उसे नए project के रूप में push करके संभाल सकते हैं

    • क्या अनावश्यक features बंद कर देने से इनमें से बहुत-सी समस्याएँ हल नहीं हो जातीं? मैंने अभी अपनी Forgejo instance देखी; उसमें repository के हिसाब से Code, Projects, Releases, Packages, Actions, Issues, PRs, Wikis बंद करने के options हैं
    • https://sr.ht/
    • तो क्या फिर हम वापस cgit पर लौट रहे हैं?

  • यह दलील काफ़ी प्रभावशाली है कि review data को भी source की तरह git repository में रखा जा सकता है
    किसी ज्ञात prefix के साथ हर review के लिए branch रखकर इसे बहुत आसानी से implement किया जा सकता है, लेकिन default branch namespace जल्दी गंदा हो जाएगा। इसे git namespaces के ज़रिए main namespace से अलग किया जा सकता है, या .reviews जैसी किसी विशेष branch में हर review branch के अंतिम commit ID ही रखे जा सकते हैं। अगर कोई व्यक्ति इसमें पर्याप्त रुचि लेकर specification और वास्तव में उपयोगी implementation बनाए, तो शायद लोग अपनाना शुरू कर दें। GitHub और कई forges ने यह रास्ता शायद इसलिए नहीं चुना क्योंकि review metadata को अपने ecosystem में बाँधकर रखना platform value का हिस्सा है। अगर कोई भी अपने पसंदीदा local tool से किसी और के code का review कर सके, तो vendor lock-in कम हो जाएगा। हालाँकि access control या cross-repository reviews जैसी वजहों से review metadata को किसी दूसरी repository में रखने के और कारण भी हो सकते हैं

    • पहले भी ऐसे कुछ प्रयास हुए थे। उस दौर में जब लोग अभी भी offline और store-and-forward workflows की परवाह करते थे[1], Bugs Everywhere[3], Git के कम-ज्ञात “notes” namespace[5] में data रखने वाला git-appraise[4], और git-bug[6] जैसी चीज़ें थीं, जो आजकल ऐसे threads में दूसरी चीज़ों से कहीं ज़्यादा दिखती हैं
      सिर्फ read-only access की बात करें तो Gerrit review data वास्तव में Git से उपलब्ध है[7]। अगर review ABCDE है, तो उस prefix के नीचे सामान्य numbered ref की जगह refs/changes/DE/ABCDE/meta pull करना होता है। और किसी ने इसे Git notes के ज़रिए भी उपलब्ध कराने का काम किया था[8]। SQLite के लिए मशहूर Fossil SCM भी built-in bug tracker में ऐसा करता है[9]। लेकिन Git के जीत जाने वाली ऐतिहासिक दुर्घटना, और Git में आम रही history rewriting के प्रति इसकी बहुत शत्रुतापूर्ण प्रकृति के कारण यह कम जाना गया। Git के ऊपर फिर से build करने की बात करें, तो जब आप कोई शानदार data type बनाना चाहते हैं, तो आपको असल में custom merge strategies चाहिए होती हैं, और Git का support इसे सहज बनाने के लिए काफी wrapping माँगता है। मेरी जानकारी में एक सफल उदाहरण git-annex[10] की location tracking है, और वह भी एक काफ़ी बड़ा Haskell project है। मौजूदा porcelain बहुत rigid है
      [1] क्या हमें उस उपयोग के लिए कोई PGP replacement नहीं मिल सकता? कृपया मुझे यह कहना बंद करें कि वह मौजूद नहीं है या मैं चला जाऊँ[2]
      [2] https://news.ycombinator.com/item?id=44239804
      [3] https://github.com/aaiyer/bugseverywhere
      [4] https://github.com/google/git-appraise
      [5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments)
      [6] https://github.com/git-bug/git-bug
      [7] https://gerrit-review.googlesource.com/Documentation/note-db...
      [8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h...
      [9] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki
      [10] https://git-annex.branchable.com/

  • मुझे PR नहीं बल्कि differences को review करने वाला Gerrit workflow बहुत पसंद है। लेकिन gitea जैसी चीज़ों से तुलना करें तो issues, project planning आदि जैसी वे बाकी सुविधाएँ इसमें कम हैं, जिनकी लोग git hosting से उम्मीद करने लगे हैं, इसलिए बहुत लोगों को मनाना मुश्किल लगता है
    काश Phabricator जैसा कोई अच्छा diff review platform होता

    • लेकिन फिर Gitea इसे जोड़ता क्यों नहीं? बाकी सब तो पहले से है; समझ नहीं आता कि ये forges हमेशा GitHub की नकल बनकर ही क्यों रह जाते हैं और उससे आगे क्यों नहीं बढ़ते

  • मेरे हिसाब से PRs, review comments, issues जैसी सभी messages को store करने के लिए मूल format RFC2822 होना चाहिए, और messages दिखाते समय CommonMark से rendering की जा सकती है
    सारा metadata headers में रखा जा सकता है, और Message-ID/In-Reply-To/References headers से उन्हें जोड़ा जा सकता है। इतने अच्छी तरह परिभाषित format के साथ आप चुन सकते हैं कि messages को कैसे store और transport करना है। उन्हें git repository में रख सकते हैं, email इस्तेमाल कर सकते हैं, या कोई और उपयुक्त तरीका अपना सकते हैं। code review के लिए मुझे व्यक्तिगत रूप से Gerrit, GitHub वगैरह से बहुत बेहतर लगता है। CI को जहाँ तक हो सके बाहर रखना चाहिए, और बस ऐसे hooks होने चाहिए जो pipeline शुरू करें, results दिखाएँ, और तय करें कि merge की अनुमति है या नहीं

    • मुझे लगता है GitHub का एक बड़ा आकर्षण यह है कि वह code review, source exploration, ticket tracking, और CI — इन चारों को साथ लाता है
      वह इन चारों में से किसी में भी असाधारण नहीं है, लेकिन इन्हें एक साथ बाँधने का काम अच्छी तरह करता है। मैं सहमत हूँ कि Gerrit का code review model बेहतर है, लेकिन बाकी तीन हिस्सों के बिना वह पूरा product नहीं बनता। Google में रोज़ Gerrit इस्तेमाल करते समय भी code search, code review, और CI के बीच कमजोर integration से झुंझलाहट होती थी। Google3/Critique/Forge जैसे Google के internal tools यह सब कहीं बेहतर तरीके से जोड़ते थे

  • email-based workflow का एक फ़ायदा याद आता है। अगर आप email देखने बैठे हैं, तो आम तौर पर आप उसी mindset में होते हैं, और उस स्थिति में आप मानते हैं कि दूसरी रुकावटें नहीं होंगी, इसलिए ज़्यादा ध्यान लगा पाते हैं
    notifications की समस्या यह है कि उनमें आते ही उन्हें साफ़ कर देने की ताकत होती है। लेकिन उस क्षण आपके पास उसे संभालने की ऊर्जा हो, यह ज़रूरी नहीं। वेब की ज़्यादातर notification systems, email clients ने दशकों पहले जो हासिल कर लिया था, उसकी एक भद्दी नकल जैसी लगती हैं। शायद पुराने लोग email इस्तेमाल करके सच में सही थे

    • email भी तो notification ही है; यह कैसे मान लिया जाए कि उसके आते ही आप उसे लेने के mood में होंगे, क्या इसे थोड़ा और स्पष्ट कर सकते हैं

  • जब Microsoft ने GitHub को absorb किया था, तब भी बहुत लोग नाराज़ थे। लेकिन व्यावहारिक रूप से alternatives अक्सर कमजोर रहे। Sourceforge में issue बनाना अंतहीन झुंझलाहट है, GitLab Sourceforge से बेहतर है, लेकिन वहाँ भी issue बनाना पसंद नहीं। Codeberg का UI हाल में बदला हुआ लगता है, फिर भी वह काफ़ी असुविधाजनक है
    GitHub ने शुरू में जो अच्छा किया, वह था UI पर ध्यान देना और GitHub इस्तेमाल करने वालों के लिए चीज़ों को आसान या और आसान बनाना। हालाँकि उसने सब कुछ अच्छा नहीं किया; wiki support मुझे भयानक लगता है। इतना खराब कि मैं wiki का लगभग उपयोग ही नहीं करता। असली बड़ी समस्या मुझे commercial interests, यानी निजी हित, लगती है। Microsoft सिर्फ एक उदाहरण है; लगभग हर ऐसी site में यह समस्या दिखती है। पहले xz backdoor utility से जुड़े issue discussion का उदाहरण दिया गया था, और मैं भी उस चर्चा में शामिल था, लेकिन अगले दिन Microsoft ने सब हटा दिया। यह Microsoft था या repository owner, इससे ज़्यादा फ़र्क नहीं पड़ता। समस्या यह है कि कोई व्यक्ति संभावित रूप से उपयोगी जानकारी को बहुत आसानी से censor कर सकता है। वह issue discussion उपयोगी था और censor कर दिया गया। जहाँ तक याद है, उस समय सारी जानकारी बहाल भी नहीं हुई थी। शायद किसी ने mirror किया हो, लेकिन मैंने कोई link नहीं देखा। इससे पता चलता है कि top-down control सचमुच हानिकारक हो सकता है। सच कहें तो Microsoft पर कितना भरोसा किया जा सकता है? ज़रूरत ऐसी चीज़ की है जो decentralized हो, स्थिर रूप से अच्छी चले, जिसका default UI अच्छा हो, और जो simple या कम-से-कम अच्छे workflow दे। और ऐसी स्थिति से भी बचना होगा जहाँ private actors सबको बंधक बना लें। इसे कैसे हल करें, इसका मुझे बिल्कुल पता नहीं; शायद कई approaches एक साथ चाहिए हों। वेब बदल चुका है, और खासकर mega-corporations के निजी हितों ने पिछले 10–15 साल में हालात को बहुत बदतर बनाया है। इसे बदलना होगा

    • समस्या यह है कि SaaS product चलाना बहुत महँगा पड़ता है
      बड़ी कंपनियाँ यह खर्च उठा सकती हैं, लेकिन छोटे बजट वाले बहुत सारे developers मिलकर भी वही काम करने के लिए उतना पैसा नहीं जुटा पाते। इसलिए कोई भी commercial project आखिरकार औसत व्यक्ति की तुलना में बड़ी कंपनियों के हितों को ज़्यादा support करने की दिशा में झुक ही जाता है