ओपन सोर्स पर काम करने के लिए लोगों को भुगतान करना अच्छा है
ओपन सोर्स सॉफ़्टवेयर पर काम करने वाले डेवलपर्स को भुगतान करना स्थिरता के लिए व्यापक रूप से आवश्यक माना जाता है, लेकिन इस पर विवाद है कि इसका वित्तपोषण कौन करे और किन शर्तों पर। टिप्पणीकार कॉर्पोरेट प्रायोजन, अनुदान, सरकारी कार्यक्रमों, और “freemium” या समर्थन-आधारित बिज़नेस मॉडलों पर विचार करते हैं, और वित्तीय व्यवहार्यता, परियोजना की दिशा, तथा समुदाय नियंत्रण के बीच समझौतों को रेखांकित करते हैं। एक बड़ा विभाजन “open source” की परिभाषा को लेकर है, जहाँ कुछ लोग OSI-अनुमोदित लाइसेंसों पर ज़ोर देते हैं और अन्य क्लाउड युग तथा कॉर्पोरेट शोषण के लिए अधिक प्रतिबंधात्मक, source-available लाइसेंसों को व्यावहारिक अनुकूलन मानते हैं.
ओपन सोर्स रखरखावकर्ताओं को भुगतान करने पर समग्र भावना
- व्यापक सहमति है कि ओपन सोर्स पर काम करने के लिए लोगों को भुगतान करना लाभकारी है।
- कई टिप्पणीकार व्यक्तिगत रूप से दान करते हैं (अक्सर आय का एक निश्चित %) और/या उपकरणों के महत्व के आधार पर गैर-लाभकारी संस्थाओं के माध्यम से संरचित दान आयोजित करते हैं।
- कुछ लोग रखरखावकर्ताओं के लिए किसी भी टिकाऊ रास्ते का उत्सव मनाने पर ज़ोर देते हैं (रोज़गार, अनुदान, समर्थन अनुबंध, आदि), न कि धन के स्रोत की शुद्धता पर।
“हमेशा अच्छा” और बिज़नेस मॉडलों पर चिंताएँ
- कई लोगों का तर्क है कि भुगतान हमेशा अच्छा नहीं होता: कॉर्पोरेट प्रायोजक परियोजनाओं को उपयोगकर्ता-विरोधी दिशाओं में मोड़ सकते हैं या शोषणकारी बिज़नेस मॉडलों को सहारा दे सकते हैं।
- अन्य लोग जवाब देते हैं कि “पूर्णता को अच्छाई के रास्ते में नहीं आना चाहिए”: जब तक बड़े पैमाने पर सार्वजनिक वित्तपोषण मौजूद नहीं है, कॉर्पोरेट पैसा अक्सर एकमात्र व्यावहारिक विकल्प होता है और फ़ॉर्क्स एक सुरक्षा वाल्व बने रहते हैं।
- चिंता यह है कि कुछ “जीत” (जैसे कॉर्पोरेट-वित्तपोषित, उपयोगकर्ता-विरोधी OSS) वास्तव में शुद्ध नकारात्मक हैं, खासकर जब वे डी फैक्टो एकाधिकारों को मज़बूत करते हैं।
चर्चित वित्तपोषण तंत्र
- अनुदान: सहायक लेकिन अस्थिर, आमतौर पर विशिष्ट फीचर्स से जुड़े; अकेले पर्याप्त नहीं।
- सेवाएँ, कंसल्टिंग, होस्टिंग, सपोर्ट, और भुगतान वाले “एंटरप्राइज़” फीचर्स को कुछ इकोसिस्टम में पूरी तरह मुक्त सॉफ़्टवेयर के सफल वित्तपोषण के रूप में उद्धृत किया गया है।
- थ्रेशहोल्ड प्लेज / “फीचर्स के लिए Kickstarter” मॉडल का उल्लेख किया गया है (जैसे Blender का GPL रिलीज़) लेकिन इसे फ्री-राइडर प्रोत्साहनों के कारण सीमित माना गया है।
- “क्वाज़ी-ओपन-सोर्स” या source-available लाइसेंसों के साथ एक ऐसी फ़ाउंडेशन के प्रस्ताव जो अनिवार्य व्यावसायिक योगदान एकत्र करे, बहस छेड़ते हैं।
“ओपन सोर्स” की परिभाषा पर बहस
- सबसे गरम चर्चाओं में से एक: कुछ लोग ज़ोर देते हैं कि “open source” का अर्थ OSI-अनुरूप लाइसेंस होना चाहिए जिनमें उपयोग प्रतिबंध न हों; बाकी सब “source available” है।
- अन्य लोग एक व्यापक, अधिक व्यावहारिक छतरी का समर्थन करते हैं जिसमें BSL, Polyform, और अन्य post-cloud वेरिएंट जैसे लाइसेंस शामिल हों, यह तर्क देते हुए कि मूल “open source” अभियान भी व्यवसाय-उन्मुख था।
- “openwashing” का प्रबल डर: इस शब्द को open-core, bait-and-switch relicensing, और प्रतिबंधात्मक source-available योजनाओं को ढकने के लिए पतला करना।
- कुछ लोग कहते हैं कि वे OSI-शैली की परिभाषा को ढीला करने से बेहतर परियोजनाओं को मरते देखना चाहेंगे।
अर्थशास्त्र और किसे भुगतान करना चाहिए
- OSS को एक सार्वजनिक वस्तु के रूप में वर्णित किया गया है, जिसमें क्लासिक फ्री-राइडर समस्याएँ हैं; लाइब्रेरियाँ सहायक घटक हैं जो संरचनात्मक रूप से समेकन को बढ़ावा देती हैं।
- कई लोगों का तर्क है कि अधिकांश उपयोगकर्ता मुख्यतः “free as in price” की परवाह करते हैं, न कि freedoms की, जिससे प्रोत्साहन विकृत होते हैं।
- बार-बार यह भावना व्यक्त की गई कि बड़े कंपनियों को, न कि व्यक्तिगत डेवलपर्स को, अधिकांश वित्तीय ज़िम्मेदारी उठानी चाहिए; सुझावों में कॉर्पोरेट OSS बजट और volunteer-time PTO शामिल हैं।
सरकारी और सार्वजनिक-क्षेत्र की भूमिका
- EU मॉडल जैसे NLNet और German Sovereign Tech Fund की प्रशंसा की गई है; कुछ लोग अमेरिका में भी ऐसा ही तंत्र चाहते हैं।
- अन्य लोग नौकरशाही और अपव्यय के कारण प्रत्यक्ष सरकारी भागीदारी के प्रति संशय में हैं, और सार्वजनिक धन को चैनल करने वाली स्वतंत्र फ़ाउंडेशनों का समर्थन करते हैं।
भुगतान प्राप्त योगदानकर्ताओं का प्रभाव
- कुछ भाषा इकोसिस्टम के उदाहरण दिखाते हैं कि थोड़े से पूर्णकालिक वित्तपोषित योगदानकर्ता दस्तावेज़ीकरण, UX, और समन्वय में नाटकीय सुधार कर सकते हैं।
- एक अल्पसंख्यक चेतावनी देता है कि पैसा समुदाय की गतिशीलता को विकृत कर सकता है और भुगतान वाली टीमें बाद में परियोजनाओं को छोड़ सकती हैं, जिससे उपयोगकर्ताओं पर अप्रत्याशित रखरखाव बोझ रह जाता है।