3 पॉइंट द्वारा GN⁺ 2025-08-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल की रिपोर्टों में रूसी डेवलपर द्वारा बनाए गए ओपन सोर्स सॉफ़्टवेयर के उपयोग को लेकर आलोचना उठी है
  • वास्तविकता यह है कि लगभग सभी ओपन सोर्स प्रोजेक्ट्स का बड़ा हिस्सा सिर्फ़ एक व्यक्तिगत मेंटेनर द्वारा चलाया जाता है
  • NPM ही नहीं, कई अन्य ecosystems में भी एकल मेंटेनर लोकप्रिय पैकेज संभालते हैं
  • इस संरचना की समस्या है एक मेंटेनर पर अत्यधिक बोझ और सप्लाई चेन जोखिम
  • समस्या की जड़ राष्ट्रीयता नहीं, बल्कि व्यावहारिक रूप से संसाधनों और समर्थन की कमी है

परिचय: ओपन सोर्स और हालिया विवाद

  • The Register में रूसी डेवलपर द्वारा बनाए गए ओपन source utility के उपयोग पर अमेरिकी रक्षा विभाग की निर्भरता को सवालों के घेरे में रखने वाला लेख प्रकाशित हुआ
  • संबंधित ओपन सोर्स डेवलपर अनुचित आलोचना का सामना कर रहा है
  • लेख की सामग्री ओपन सोर्स की वास्तविकता को गलत समझती है, और यह इस तरह के दृष्टिकोण की सीमाओं की ओर इशारा करती है

ओपन सोर्स की वास्तविकता: 'एक व्यक्ति' की संरचना

  • डेटा के अनुसार, लगभग अधिकांश ओपन सोर्स प्रोजेक्ट्स एक ही व्यक्ति द्वारा मेंटेन किए जाते हैं
  • ecosyste.ms प्रोजेक्ट में लगभग 1.18 करोड़ ओपन सोर्स प्रोजेक्ट्स का डेटा संकलित है
    • इनमें से लगभग 70 लाख प्रोजेक्ट्स एकल मेंटेनर वाले हैं
    • बाकी लगभग 40 लाख प्रोजेक्ट्स में मेंटेनर की संख्या अज्ञात है, लेकिन अनुमान है कि उनमें से भी काफी प्रोजेक्ट्स एक ही व्यक्ति द्वारा चलाए जाते हैं
    • बहुत कम प्रोजेक्ट्स ऐसे हैं जिनमें सैकड़ों मेंटेनर हैं

लोकप्रिय प्रोजेक्ट्स भी अपवाद नहीं हैं

  • बहुत से लोग सोचते हैं कि "महत्वपूर्ण ओपन सोर्स या लोकप्रिय प्रोजेक्ट्स कई लोग मिलकर संभालते होंगे", लेकिन वास्तव में NPM जैसे प्रमुख ecosystems भी अलग नहीं हैं
  • NPM ecosystem में 40 लाख से अधिक एकल मेंटेनर प्रोजेक्ट्स मौजूद हैं
  • NPM पैकेजों में, जिन्हें हर महीने 10 लाख से अधिक डाउनलोड मिलते हैं, उनमें भी लगभग आधे एकल मेंटेनर द्वारा चलाए जाते हैं
    • डाउनलोड संख्या को 100 करोड़ तक बढ़ाने पर कुछ अंतर दिखता है, लेकिन तब भी एक मेंटेनर वाले पैकेज मौजूद हैं
  • NPM के 40 लाख एकल मेंटेनर प्रोजेक्ट्स को चलाने वाले वास्तविक लोगों की संख्या लगभग 9 लाख है (यानी एक व्यक्ति कई प्रोजेक्ट्स की जिम्मेदारी संभालता है)

समस्या की जड़: देश नहीं, संसाधनों की कमी

  • ओपन सोर्स का आर्थिक पैमाना कई ट्रिलियन डॉलर के आधार पर टिका है (Harvard शोध के अनुसार, 8.8 ट्रिलियन डॉलर)
  • अधिकांश एकल मेंटेनर प्रोजेक्ट्स में संसाधनों की कमी है, और सप्लाई चेन जोखिम मौजूद है
  • सबसे बड़ा जोखिम कोई देश नहीं, बल्कि वह 'एक मेंटेनर' है जो अत्यधिक काम कर रहा है और जिसे उचित प्रतिफल नहीं मिल रहा
  • मीडिया आदि द्वारा व्यक्तिगत मेंटेनरों को निशाना बनाना समाधान नहीं है

निष्कर्ष और एक्शन पॉइंट

  • मौजूदा समस्या की वजह एकल मेंटेनर वाली संरचना है; देश पर फोकस करना बेअर्थ है
  • व्यक्तिगत मेंटेनरों को राक्षसी रूप देना या उन्हें खोजकर निशाना बनाना समाधान नहीं है
  • यह समस्या जटिल है और इसका कोई तत्काल समाधान मौजूद नहीं है
  • एकल मेंटेनरों को चिन्हित कर दोष देने के बजाय, संरचनात्मक समस्या और समर्थन के उपायों पर विचार करना ज़रूरी है

1 टिप्पणियां

 
GN⁺ 2025-08-29
Hacker News राय
  • ऐसा लगता है कि software community में इस मुद्दे को लेकर काफी गलतफ़हमियाँ हैं; मुझे वास्तव में लगता है कि supply chain risk software या engineering की समस्या कम और governance की समस्या ज़्यादा है
    किसी की बुरी मंशा न भी हो, तब भी किसी project में supply chain risk पैदा हो सकता है, और supply chain risk का आकलन करने वाले हर व्यक्ति का security नज़रिया और मानदंड अलग होता है
    DoD(अमेरिकी रक्षा विभाग) आम developers से बिल्कुल अलग नज़रिये से risk को देखता है, और कई one-person projects सिर्फ इसलिए risk बन जाते हैं क्योंकि उन्हें संभालने वाला व्यक्ति केवल एक होता है
    अगर ‘bus factor’ 1 है, तो वही अपने आप में supply chain risk है
    ज़्यादातर लोग package चुनते समय युद्ध की स्थिति तक नहीं सोचते, लेकिन सेना युद्ध को ध्यान में रख सकती है
    अगर युद्ध छिड़ जाए, तो सामान्य समय में स्वायत्त रूप से चलने वाले open source projects की स्थिति भी तेज़ी से बदल सकती है
    वास्तव में कई देश युद्धकाल में क़ानून के ज़रिए निजी कंपनियों या व्यक्तिगत projects से सहयोग की मांग करते हैं, इसलिए कुछ जगहें (जैसे DoD) इस तरह की बातों को भी security risk में गिनती हैं

    • दोस्तों, सब मिलकर बोलें: packages को ज़रूर vendor करें! Vendor करें!
    • फिर भी यह देख कर कड़वाहट होती है कि "एक solo developer भी जल्द ही अरबों डॉलर की software company बना सकता है" जैसी overhype अब भी चलती रहती है
    • मुझे लगता है कि DoD तो उस package का सारा code पंक्ति-दर-पंक्ति पढ़े बिना, updates को lock किए बिना, और ज़रूरत पड़ने पर खुद patch करने की तैयारी किए बिना उसका इस्तेमाल ही नहीं करता
      युद्ध जैसी स्थिति में वे इस अंदाज़ में काम नहीं करेंगे कि "काश हमारे पास कोई एक और व्यक्ति होता जिस पर हम बिल्कुल भी भरोसा नहीं करते"
  • NPM में 40 लाख one-person projects हैं और लगभग 9 लाख लोग उन projects को maintain करते हैं—ऐसा कुछ data था; मुझे जिज्ञासा हुई कि क्या यह वास्तव में इतना अहम point था

    • इसे साफ़ तौर पर नहीं कहा गया, लेकिन शायद मतलब यह था
      यानी open source की आर्थिक value (Harvard के अनुमान के अनुसार 8.8 ट्रिलियन डॉलर) का बड़ा हिस्सा "one-person projects" से बनता है, और उनमें से किसी को भी ठीक-ठाक resources नहीं मिलते
      supply chain risk की चर्चा में असली ख़तरा वह कम वेतन वाला, ज़रूरत से ज़्यादा काम में डूबा one-person maintainer है
      वह किस देश से है, यह सच कहूँ तो इतना महत्वपूर्ण नहीं है
  • अगर कोई one-person maintainer अचानक दुर्घटना का शिकार हो जाए या project छोड़ दे, तो फिर क्या होता है—क्या इस बारे में कोई आँकड़े हैं, यह जानना चाहूँगा
    इतना data है तो इस पर research की जा सकती है
    मैं जानना चाहूँगा कि क्या कोई नया developer project संभाल लेता है, क्या उसकी जगह कोई समान project ले लेता है, या वह पूरी तरह गायब हो जाता है

    • यह स्थिति पर निर्भर करता है
      व्यवहार में bus accident से ज़्यादा आम मामला यह होता है कि ‘maintainer की रुचि ख़त्म हो जाती है या उसके पास समय नहीं बचता, इसलिए वह हट जाता है’
      ऐसे में अक्सर ये scenarios देखने को मिलते हैं
      1. कोई fork बना देता है और अंततः वही fork original की जगह ले लेता है
      2. उसी काम का कोई नया project लोकप्रिय हो जाता है और पुराने project को replace कर देता है
      3. मूल maintainer project का प्रबंधन किसी और को सौंप देता है
      4. कोई maintenance न होने पर भी project इस्तेमाल होता रहता है, और समस्या आने पर लोग अपने-अपने forks से उसे ठीक करते हैं, लेकिन वे forks main trend नहीं बनते
        open source की ताकत यह है कि creator गायब हो जाए, अजीब बर्ताव करने लगे, या license बदल दे, तब भी कोई न कोई fork करके उसे बचा सकता है
        इसके उलट commercial software में, बनाने वाला चाहे company हो या व्यक्ति, अगर वह गायब हो जाए या चीज़ें बदल दे तो खेल वहीं ख़त्म हो जाता है
        फिर बस किसी alternative product की तलाश करनी पड़ती है
    • अगर ऐसे लोकप्रिय open source libraries/tools/apps/sites के एक maintainer से दूसरे maintainer तक जाने की प्रक्रिया पर कोई episode series हो, तो मैं उसे ज़रूर देखना चाहूँगा
      शायद यही वजह है कि मैं Netflix नहीं चलाता
    • मेरे अनुभव में मैंने ये तीनों तरह की स्थितियाँ सचमुच देखी हैं
      आख़िरकार यह users की संख्या, codebase की complexity, और alternatives की उपलब्धता पर निर्भर करता है
    • सबसे मिलती-जुलती मिसाल के तौर पर Hans Reiser/Reiserfs याद आता है
      यह सिर्फ "bus से टकरा जाने" से कहीं ज़्यादा अजीब कहानी है, और अंत में वह project समाप्त हो गया
    • लोग अक्सर यह नज़रअंदाज़ कर देते हैं कि अगर code open source है, तो समय भले लगे, worst case में उसे कभी भी fork किया जा सकता है
  • दो या उससे अधिक maintainers वाले projects में भी, अक्सर असल commits का ज़्यादातर हिस्सा अंततः एक ही व्यक्ति करता है

  • अगर सिर्फ activity check ही किया होता, तो तुरंत पता चल जाता कि पूरे projects में से आधे के maintainers 0 हैं—यह न देखना अफ़सोसजनक है

    • कभी-कभी software एक बार "perfect" लगने लगे, तो उसके बाद उसे maintenance की ज़रूरत नहीं रहती
      मतलब उसे साफ़-सफ़ाई, tuning, या calibration की भी ज़रूरत नहीं होती; बस वैसे ही छोड़ सकते हैं
      कई बार समस्या project में नहीं, बल्कि update/refresh में होती है
  • यह बात ज़्यादा चिंताजनक लगती है कि DoD node का इस्तेमाल करता है
    npm जैसी platform का attack surface बहुत बड़ा है, यह असहज करता है

    • तब यह सवाल उठता है कि क्यों
      DoD दुनिया की सबसे बड़ी संस्थाओं में से एक है, इसलिए उसके पास newsletter भेजने या Boy Scouts base tour booking webpage जैसे काम भी बहुत होंगे
      ऐसी जगहों पर node का इस्तेमाल करने में मुझे कोई समस्या नहीं दिखती
      ऐसे systems missile launch जैसे mission-critical systems से अलग चलाए जाते हैं, और अगर कोई event signup page बिगड़ भी जाए तो उससे बहुत बड़ी समस्या नहीं होगी
    • DoD का scale इतना बड़ा है कि वह शायद लगभग हर major platform का इस्तेमाल करता होगा
  • मुझे लगता है कि GitHub पर बहुत से one-person projects वास्तव में सिर्फ "hello world" जैसे personal experiments या मज़ाक भर होते हैं
    npm का तो नहीं पता, लेकिन PyPI में भी ऐसे उदाहरण भरे पड़े हैं
    मैंने खुद ‘browse projects’ दबाया तो यह दिखा: https://pypi.org/project/helloworld-eduardo/
    चाहे कोई कितना भी नशे में हो, इसे product में इस्तेमाल करने का नहीं सोचेगा

  • DoD इस बात में बहुत माहिर है कि अगर उसे कुछ मुफ़्त में मिल सकता है, तो वह सबको यह समझा देता है कि "इससे सबका फ़ायदा है", और आख़िर में काम पैसे देकर किसी contractor को दे देता है

    • Trojan horse की घटना याद करें, तो समझ आता है कि मुफ़्त चीज़ हमेशा अच्छी नहीं होती
  • कहा गया कि "एक single maintainer वाला package 1 अरब से ज़्यादा बार download किया गया", तो मेरा सवाल है कि उससे कहना क्या चाह रहे थे

  • मैंने Linus नाम के व्यक्ति के काम के बारे में बहुत अच्छी बातें सुनी हैं, और शायद उसका काफ़ी इस्तेमाल भी किया है
    वह ऐसे देश से है जिसकी सीमा रूस से लगती है, तो क्या इस बात की भी चिंता करनी चाहिए—ऐसा सवाल मन में आता है
    मैंने दशकों तक open source development किया है, ज़्यादातर लगभग अकेले, या कभी-कभी volunteer team बनाकर
    जिसने भी volunteer team के साथ काम किया है, वह जानता होगा कि यह बिल्कुल आसान नहीं है
    यह बिल्कुल असंभव तो नहीं, लेकिन जितना हम सोचते हैं उतनी बार अच्छी तरह काम नहीं करता
    जब यह सफल होता है, तो आमतौर पर या तो कोई "BDFL(उदार तानाशाह)" होता है, या फिर सब एक ही लक्ष्य के तहत काम कर रहे होते हैं
    मेरे मामले में यह ज़्यादातर दूसरा रूप था

    • (off-topic) कहा जाता है कि Linus के माता-पिता भी राजनीतिक रूप से सक्रिय थे, और Linus खुद बचपन में communist youth group (scouts जैसी संस्था) में भी रहा था
      उसके पिता ने मॉस्को में कुछ साल बिताए थे
    • Linux एक ऐसा project है जिसके पास बड़े पैमाने पर maintainers और support है, इसलिए यह Linus के अकेले बनाए जाने वाले one-person project जैसा बिल्कुल नहीं है