1 पॉइंट द्वारा GN⁺ 2026-01-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • open source पर निर्भरता कंपनियों के संचालन का केंद्रीय हिस्सा बन चुकी है, फिर भी इसे मुफ्त मान लेना एक गलत प्रथा है
  • दान या sponsorship पर निर्भर मौजूदा संरचना टिकाऊ नहीं है, और फंडिंग के नए तरीके की जरूरत है
  • प्रस्तावित तरीका यह है कि GitHub हर उपयोगकर्ता से हर महीने 1 डॉलर अतिरिक्त ले और इसे Open Source Fund में जमा करे, फिर उपयोग के आधार पर बांटे
  • वितरण का आधार package.json या requirements.txt में उल्लिखित प्रोजेक्ट हों, और इसे Spotify के revenue-sharing model जैसी संरचना के रूप में पेश किया गया है
  • यह जोर दिया गया है कि जब open source पूरी दुनिया के infrastructure को संभाल रहा है, तब टिकाऊ compensation system बनाने की जरूरत है

open source को मुफ्त मानकर निर्भर रहने पर सवाल

  • यह कहा गया है कि open source को ‘free beer’ की तरह मुफ्त समझना असामान्य है
    • code के पीछे वास्तविक मेहनत होती है, और इसे सिर्फ hobby या voluntary contribution मानना गलत धारणा है
  • मौजूदा open source ecosystem दान और sponsorship पर निर्भर है, और यह एक अस्थिर ढांचा है
    • visibility पाने के लिए developers को लगभग भीख मांगने की तरह sponsorship मांगनी पड़ती है
    • कुछ projects जीविका चलाने के लिए ‘lifeline’ खोजने की स्थिति में पहुंच जाते हैं

GitHub के जरिए नई फंडिंग का प्रस्ताव

  • GitHub सभी organizations से प्रति उपयोगकर्ता हर महीने 1 डॉलर अतिरिक्त ले और इसे Open Source Fund में जमा करे, ऐसा प्रस्ताव रखा गया है
    • fund को escrow के रूप में रखा जाएगा ताकि उसका पारदर्शी प्रबंधन हो सके
  • जमा राशि usage-based distribution के आधार पर बांटी जाए, यानी किसी project का package.json या requirements.txt में कितनी बार उल्लेख है, उसके अनुसार
    • इसमें Dockerfile की FROM command जैसी चीजें भी शामिल की जा सकती हैं
  • कहा गया है कि यह मॉडल Spotify के artist revenue-sharing system जैसा है
    • Spotify का मॉडल पूरी तरह आदर्श नहीं है, लेकिन कम से कम यह एक बुनियादी संरचित वितरण प्रणाली का उदाहरण है

लागू करने का तरीका और भागीदारी की संरचना

  • fund को default participation (opt-out) के रूप में चलाया जाए
    • यानी organizations चाहें तो इससे बाहर निकल सकती हैं
  • भाग लेने वाली organizations को ‘जादुई badge’ या profile background CSS सेट करने की permission जैसी प्रतीकात्मक सुविधाएं दी जा सकती हैं
  • प्रस्ताव रखने वाले का कहना है, “यह विचार अधूरा और ढीला-ढाला है, लेकिन मौजूदा स्थिति को अच्छा नहीं कहा जा सकता”

open source की sustainability को लेकर चिंता

  • मौजूदा संरचना में दुनिया के महत्वपूर्ण infrastructure को संभालने वाला code और मेहनत बिना किसी compensation के इस्तेमाल हो रहा है
  • open source maintenance के लिए फंड के नए circulation structure की जरूरत पर जोर दिया गया है
  • यह भी कहा गया है, “Linux जैसे बड़े projects को इसमें कैसे शामिल किया जाए, यह स्पष्ट नहीं है, लेकिन कहीं न कहीं से शुरुआत करनी होगी”

निष्कर्ष

  • प्रस्ताव रखने वाला उम्मीद करता है कि उससे अधिक समझदार लोग इस विचार को आगे बढ़ाकर ठोस रूप दे सकेंगे
  • मूल संदेश यह है कि “open source की मौजूदा फंडिंग संरचना टिकाऊ नहीं है, और बदलाव जरूरी है”

1 टिप्पणियां

 
GN⁺ 2026-01-16
Hacker News की राय
  • मैं बिना पैसे वाले open source योगदान का आनंद लेने वाला व्यक्ति हूँ
    अगर दूसरे लोग मेरे काम का आनंद लें तो और भी अच्छा लगता है
    मुझे नहीं लगता कि हर कोड के लिए इनाम की उम्मीद करना कोई सार्वभौमिक रवैया है
    अगर आप open source बनाते समय इनाम की उम्मीद कर रहे हैं, तो आपका नज़रिया गलत है
    लेकिन, अगर आप किसी और के काम पर निर्भर हैं, तो समुदाय के प्रति संवेदनशीलता ज़रूरी है

    • मुझे लगता है कि जो लोग इस नज़रिए को चूक जाते हैं, वही UBI(बेसिक इनकम) या social safety net को “प्रेरणा घटाने वाला” कहकर खारिज कर देते हैं
      कई रचनात्मक और संवेदनशील लोग पैसे से नहीं, बल्कि शुद्ध सृजन के आनंद से प्रेरित होते हैं
      अगर बुनियादी जीवनयापन सुनिश्चित हो, तो दुनिया में कहीं ज़्यादा कला, समुदाय, और open source पैदा होगा
    • मैं मानता हूँ कि तुम सही कह रहे हो
      मैं बस यह कहना चाहता था कि इस तरह के श्रम को आसमान से गिरे उपहार की तरह नहीं माना जाना चाहिए
      प्रोजेक्ट जितना बड़ा होता है, ज़िम्मेदारी उतनी बढ़ती है, और उसका बोझ एक ही व्यक्ति पर केंद्रित होना अन्यायपूर्ण है
      xz backdoor घटना या PocketBase FAQ की तरह, इसके लिए सिस्टम स्तर पर समर्थन चाहिए
    • मैं भी open source का आनंद लेता हूँ, लेकिन कभी-कभी मेरा कोड critical infrastructure बन जाता है
      ऐसी स्थिति में “मज़े के लिए किया गया काम” “नौकरी-स्तर की ज़िम्मेदारी” में बदल जाता है, और इस बदलाव के लिए कोई मॉडल पर्याप्त नहीं है
      इसी वजह से कई maintainers burnout का शिकार होते हैं
    • मैं सीखने और सृजन के आनंद की वजह से open source बनाता हूँ
      मेरा GitHub project मेरे अपने द्वीप जैसा है
      PR आना अच्छा भी लगता है, लेकिन कभी-कभी ऐसा भी महसूस होता है जैसे कोई और मेरी पेंटिंग पर रंग चढ़ा रहा हो
      मुझे इनाम नहीं चाहिए, बस मेरे license के अनुसार आज़ादी से fork कर लो
      हमारे जैसे रचनाकारों के लिए दखल न देना और आज़ादी देना ही सबसे बड़ा सम्मान है
    • मैं भी इसी वजह से open source बनाता हूँ
      वह दुनिया के लिए मेरा उपहार है
      हाँ, थोड़ा-बहुत इनाम अच्छा लगेगा, लेकिन अगर उसके साथ कोई बाध्यता या शर्त जुड़ जाए, तो अभी वाला आज़ाद तरीका बेहतर है
  • open source मूल रूप से स्वैच्छिक उपहार है
    उसके बदले बस थोड़ी पहचान या संतोष मिलता है

    • असली समस्या maintenance का बोझ है
      कई कंपनियाँ bug fix या security issues का बोझ maintainers पर डाल रही हैं
      यह ढाँचा टिकाऊ नहीं है, और आखिरकार burnout तथा छोड़ी हुई libraries तक ले जाता है
      अगर कंपनियों के पास संसाधन या विशेषज्ञता की कमी है, तो उन्हें sponsorship के ज़रिए उसका प्रतिदान करना चाहिए
    • license की शर्तों के अनुसार इस्तेमाल करने वालों को दोष देना अब उबाऊ लगने लगा है
    • जो चीज़ मुफ्त में दी गई हो, उसके लिए बाद में पैसे माँगना मुझे तर्कसंगत नहीं लगता
    • इस समस्या का स्वाभाविक समाधान सरकारी या निजी grant system है
      ऐसी संरचना चाहिए जो critical infrastructure संभालने वालों को उचित भुगतान दे
  • open source funding की समस्या का हल जबरन भुगतान नहीं है
    ऐसा ढाँचा open source की भावना के खिलाफ है
    maintainers और users, दोनों की एक-दूसरे के प्रति कोई बाध्यता नहीं है
    अगर पसंद नहीं है तो PR submit करो या fork कर लो
    open source commercial software नहीं, बल्कि मुक्त साझेदारी का मंच है

    • लेकिन “पैसा किसे मिलेगा” यह तय करना भी एक समस्या है
      अगर लोकप्रियता को आधार बनाया जाए, तो ज़्यादातर पैसा JavaScript की ओर बह जाएगा
    • असल में open source का मूल अर्थ “मुफ्त” नहीं, बल्कि संशोधन और पहुँच की आज़ादी था
      यानी यह “free beer” से ज़्यादा “free speech” के करीब का विचार है
  • इस तरह के प्रस्ताव में जो मान्यता छिपी है कि “FOSS ज़्यादातर volunteers का काम है”, वह गलत है
    मैं जो बहुत-सा open source इस्तेमाल करता हूँ, वह बड़ी कंपनियों ने बनाया है
    उदाहरण के लिए React को Meta ने, TypeScript को Microsoft ने, और Chrome को Google ने बनाया

    • लेकिन Chrome भी पूरी तरह FOSS नहीं है
      Google Chrome, Chromium पर आधारित एक commercial browser है
      Chromium, WebKit(Apple) से fork हुआ था, और WebKit, KDE के KHTML से fork हुआ था
    • इसके अलावा Chrome, libxml2 जैसे Google से बाहर के code पर भी निर्भर करता है
      हाल ही में libxml2 maintainer के इस्तीफा देने के बाद इस तरह की dependency structure फिर चर्चा में आई
  • अगर आपने open source license के तहत कुछ जारी किया है, तो लोगों के उसे मुफ्त में इस्तेमाल करने पर हैरान होने की ज़रूरत नहीं है
    अगर आप कमाई चाहते थे, तो आपको कोई दूसरा license चुनना चाहिए था

    • अगर आपको यह पसंद नहीं कि कंपनियाँ FOSS-असंगत तरीके से उसे commercialize करें, तो आपको GPL इस्तेमाल करना चाहिए था
    • license वही तय करता है जिसके पास copyright है
      commercial use पर भुगतान माँगने वाले dual license या copyleft विकल्प भी बहुत हैं
  • open source funding को usage-based तरीके से बाँटने का प्रस्ताव अप्रभावी है
    downloads ज़्यादा होने का मतलब यह नहीं कि उसकी value या maintenance effort भी ज़्यादा है
    मेरे पास भी एक npm package है जिसके करोड़ों downloads हैं, लेकिन वह पहले ही पूरा हो चुका है और उसमें छेड़ने जैसा कुछ नहीं है
    gaming prevention और efficiency दोनों को साथ में संतुष्ट करने वाला algorithm होना मुश्किल है

  • अगर ऐसी व्यवस्था आई, तो AI-generated spam code फट पड़ेगा
    ऐसा ही कुछ Spotify AI music scam case में भी हो चुका है

    • वास्तव में Tea.xyz में भी इस तरह की spam समस्या हुई थी
    • ऊपर से यह भी कहा जा रहा है कि Spotify खुद भी AI music बना रहा है
  • मैं कई सालों से grants और donations पर जीवन जी रहा हूँ
    open source funding platforms पहले से बहुत हैं, समस्या platform नहीं बल्कि developer का रवैया है
    अगर पैसे चाहिए, तो साफ़-साफ़ कहना होगा
    ज़्यादातर लोग donation link को FAQ के अंदर गहराई में छिपा देते हैं
    लेकिन अगर सीधे माँगो, तो उम्मीद से ज़्यादा लोग पैसे दे देते हैं
    Twitch streamers भी पैसे कमाते हैं, तो उपयोगी software बनाने वाले हम क्यों नहीं कमा सकते
    अगर users कंपनियाँ हैं, तो सीधे संपर्क करके sponsorship proposal देना असरदार होता है

    • उदाहरण के लिए Krita ने Steam और Windows Store पर paid sale शुरू की, और उसकी टीम 2 लोगों से बढ़कर 4 हो गई
      संबंधित लिंक
  • अगर ऐसी व्यवस्था आई, तो बेकार dependency spam बढ़ जाएगा
    पहले से ही कुछ developers download count बढ़ाने के लिए बेकार packages को PR के जरिए घुसा रहे हैं
    क्योंकि ज़्यादा downloads को resume में काबिलियत के संकेतक की तरह इस्तेमाल किया जाता है

    • अगर ऐसा ढाँचा बनता है, तो maintainers को dependency spam की निगरानी पर और ज़्यादा ध्यान देना पड़ेगा
  • अगर आप product बनाना चाहते हैं, तो बस product बनाकर बेचिए
    उसे मुफ्त में बाँटने की वजह से ही वह लोकप्रिय हुआ, और बाद में पैसे माँगना विरोधाभासी है
    अगर वह paid होता, तो लोग उसे खुद बना लेते या कुछ और इस्तेमाल करते