ओपन सोर्स सॉफ़्टवेयर में मुआवज़े की कमी अस्थिर है

Open source मेंटेनर बताते हैं कि कंपनियाँ मुफ़्त software पर जितना निर्भर हैं, उसके बदले काम करने वाले लोगों तक उतना ही कम पैसा या support पहुँचता है। टिप्पणीकार बहस करते हैं कि क्या यह एक संरचनात्मक समस्या है जिसे नए funding models, licenses, unions या public support से हल किया जाना चाहिए, या फिर यह व्यक्तिगत choice का मामला है जहाँ unpaid projects को बिना अपेक्षाओं के hobbies की तरह माना जाना चाहिए। इसके पीछे बार-बार मेंटेनर burnout, user entitlement, पैसा स्वीकार करने की legal और tax बाधाएँ, और code को freely उपलब्ध रखने तथा उससे sustainable living कमाने के तनाव जैसे विषय आते हैं.

क्या OSS सच में “अस्थिर” है?

  • कई लोग तर्क देते हैं कि मौजूदा पारिस्थितिकी तंत्र चलता रह सकता है: व्यक्तिगत मेंटेनर थक जाते हैं, लेकिन नए लोग आ जाते हैं; बड़े प्रोजेक्ट्स को कंपनियों से भारी फंडिंग मिलती है।
  • अन्य लोग कहते हैं कि OSS द्वारा पैदा किए गए भारी मूल्य और कई प्रमुख मेंटेनरों, खासकर लंबे-पूंछ वाले इंफ्रास्ट्रक्चर लाइब्रेरियों, को मिलने वाले बहुत छोटे प्रत्यक्ष मुआवज़े के बीच एक असंतुलन है।

अपेक्षाएँ, हक़दारी, और मेंटेनर की सीमाएँ

  • एक मजबूत थीम: उपयोगकर्ता अक्सर हक़दार जैसा व्यवहार करते हैं—मुफ़्त में बग फ़िक्स, फ़ीचर्स, और सपोर्ट की मांग करते हैं।
  • प्रतिवाद: मेंटेनरों पर कोई बाध्यता नहीं है; वे अनदेखा कर सकते हैं, “नहीं” कह सकते हैं, या छोड़ सकते हैं। अगर यह मज़ेदार नहीं है या भुगतान नहीं मिलता, तो छोड़ दें।
  • कुछ मेंटेनर मानते हैं कि वे खुद भी समस्या पैदा करते हैं क्योंकि वे बहुत अधिक जुड़ जाते हैं, हर issue/PR स्वीकार करते हैं, और कॉर्पोरेट उपयोगकर्ताओं के प्रति ज़िम्मेदार महसूस करते हैं।
  • सुझाई गई निपटने की रणनीतियाँ: issue trackers बंद करें, templates इस्तेमाल करें, ruthlessly triage करें, maintainership सौंपें या साझा करें, और हर चीज़ को “best effort” मानें।

पैसा, business models, और licensing

  • कई लोगों का तर्क है: अगर आपको पैसा चाहिए, तो “donations” से इसकी उम्मीद न करें; कोई product/service बनाएँ, consulting करें, support contracts लें, या dual-licensing करें।
  • अन्य लोग मनोवैज्ञानिक रुकावटों का वर्णन करते हैं: charging से यह उजागर हो सकता है कि monetary demand कम है, या यह “selling out” जैसा या पुराने contributors के साथ अन्याय जैसा लग सकता है।
  • licenses पर बहस:
    • permissive (MIT/BSD/Apache) को कुछ लोग corporate free-riding को सक्षम करने और software का मूल्य घटाने वाला मानते हैं।
    • copyleft/AGPL को अधिक “reciprocal” बताया जाता है, जो dual-licensing को सक्षम कर सकता है।
    • “non-commercial” या pay-to-use-commercially योजनाएँ भी सुझाई जाती हैं, लेकिन मानक परिभाषाओं के अनुसार इन्हें open source नहीं माना जाता।

दान, कराधान, और platforms

  • व्यावहारिक बाधाएँ: कुछ देशों में, छोटे-से-छोटे donations स्वीकार करने पर भी भारी self-employment या nonprofit bureaucracy और tax risk उत्पन्न हो जाता है।
  • GitHub Sponsors और fiscal hosts (जैसे Open Collective) रुकावट कम करते हैं, लेकिन tax/legal जटिलता नहीं सुलझाते।
  • crypto को पैसा प्राप्त करने के एक तरीके के रूप में उल्लेख किया गया है, जिस पर यह कहा गया कि यह मुख्यतः tax evasion को आसान बनाता है, न कि संरचनात्मक समाधान देता है।

कॉर्पोरेट व्यवहार और procurement

  • कंपनियाँ अक्सर OSS का उपयोग इसलिए करती हैं क्योंकि इससे procurement red tape से बचाव होता है, सिर्फ इसलिए नहीं कि यह मुफ़्त है। यहाँ तक कि $1 licenses भी paperwork शुरू कर सकते हैं।
  • कुछ लोग बताते हैं कि कंपनियाँ contractors को बड़ी रकम खुशी से देती हैं, लेकिन projects को मामूली recurring payments या “donations” देने से इनकार करती हैं।

संरचनात्मक और दार्शनिक प्रस्ताव

  • विचारों में शामिल हैं: कंपनियों द्वारा funded OSS “royalty” foundations, “category A” infrastructure के लिए सरकार/NGO funding, FOSS के लिए समय निकालने हेतु छोटे workweeks या UBI, और यहाँ तक कि OSS “unions” या collectives।
  • अन्य लोग कहते हैं कि यह एक स्वैच्छिक गतिविधि को ज़रूरत से ज़्यादा जटिल बनाता है: OSS को कला या शौक की तरह मानें—अगर funding मिले तो शानदार, लेकिन ऐसा कुछ नहीं जिसे समाज स्वाभाविक रूप से वेतन के रूप में दे।