मैं इस लेख को पढ़ रहा था और एक टिप्पणी पोस्ट करना चाहता था लेकिन मुझे लगा कि यह एक प्रतिक्रिया लेख की आवश्यकता है। सबसे पहले, यदि आप मुझे नहीं जानते हैं तो मैंने एक टन ओपन सोर्स कोड लिखा है। पूरा मंच और फिर कुछ। मुझे लगता है कि सामान्य दृष्टिकोण जो उस लेख में व्यक्त किया गया है और बहुत सारी फुलझड़ी जो मुझे ऑनलाइन दिखाई देती है, वह अधिक सरल और खतरनाक है।
आपका वेतन कौन देगा?
ओपन सोर्स बिजनेस मॉडल के लिए लोगों के पास विभिन्न उत्तर हैं। जैसे "परामर्श" या अस्पष्ट "समर्थन"। मुझे हमेशा आश्चर्य होता है कि क्या ऐसे लोगों ने कभी परामर्श बेचने की कोशिश की? या शायद "समर्थन"।
लोग इन चीजों को नहीं खरीदते हैं। खासकर मंदी की अर्थव्यवस्था में। जिस तरह से बिक्री करने वाले लोग आम तौर पर इन चीजों को बेचते हैं, वह संकेत है कि आप लाइसेंस का उल्लंघन कर सकते हैं और यदि आपने भुगतान किया और वाणिज्यिक लाइसेंस प्राप्त किया तो यह बहुत आसान होगा। मैं मुफ्त में "समर्थन" भी डालूंगा। हां, अगर आप अपना सारा समय फोन पर बिताते हैं तो आपको कुछ प्रायोजक मिल सकते हैं। यह कभी न खत्म होने वाली बिक्री प्रक्रिया है। लीड का पीछा करना और कॉल करना। इस तरह के व्यवसाय को चलाने के लिए बहुत अधिक लागत की आवश्यकता होती है।
कुछ डेवलपर समस्याग्रस्त ओपन सोर्स लाइसेंस का उपयोग करते हैं जिसका वे बिक्री के लिए लाभ उठा सकते हैं। लेकिन फिर उन्हें "पर्याप्त खुला स्रोत नहीं" के रूप में बदनाम किया जाता है। वहां कोई जीत नहीं है।
सन माइक्रोसिस्टम्स ने मेरे कुछ ओएसएस कार्य के दौरान मेरे वेतन का भुगतान किया। वे नीचे चले गए और 200+ बिलियन डॉलर के मूल्यांकन से गिर गए, अंततः लगभग 7 बिलियन में बिक गए। दी, ऐसा इसलिए नहीं है क्योंकि वे खुले स्रोत थे। यह सिर्फ एक किस्सा है, और इससे कोई फायदा नहीं हुआ। असली लोग अपनी वास्तविक नौकरी खो देते हैं क्योंकि ओपन सोर्स पैसा नहीं बनाता है। होता भी है तो बहुत कम बनाता है। लोग कहते थे कि यह एक बड़े पाई में से एक छोटे टुकड़े के साथ समाप्त होता है। यह सच है, लेकिन केवल बड़े खिलाड़ियों के लिए लागू होता है और आपके पास दो विकल्प होते हैं: बड़े खिलाड़ी बनें या बड़े खिलाड़ी को अपनी मेहनत से लाभ लेते हुए देखें।
मुझे गलत मत समझो, मैं उन लोगों के खिलाफ नहीं हूं जो मेरे काम या यहां तक कि बड़े निगमों को लाभ पहुंचा रहे हैं। मैं मनोरंजन के लिए ओएसएस करता हूं और अपने काम के आधार पर लोगों के सफल होने के विचार को पसंद करता हूं। लेकिन मुझे निराशा होती है जो कई डेवलपर्स महसूस करते हैं, और कंबल "ओपन सोर्स वकालत" जो मैं लोगों से देखता हूं वह समस्याग्रस्त है।
बुरी बात कॉर्पोरेट निंदक है। गूगल को ही लीजिए। जब उनके पास कोई उपयोगकर्ता नहीं था तो उन्होंने सोर्स किए गए एंड्रॉइड को खोल दिया। कंपनियों ने इसके ऊपर निर्माण किया और इसी तरह डेवलपर्स ने भी। इसके चारों ओर वकालत का गठन हुआ क्योंकि "यह खुला स्रोत है"। फिर उन्होंने बंद स्रोत Google Play Services को जारी किया, जिसने बाद में कुछ आवश्यक कार्यक्षमता के लिए SaaS Firebase आवश्यकता को जोड़ा (यह इस समय इसके लिए मुफ़्त है) और अब हमारे पास खुले स्रोत के रूप में गहरी विक्रेता बंद स्रोत निर्भरताएँ हैं।
अगर हम Android के लिए निर्माण करना चाहते हैं तो हमें Google Play सेवाओं का उपयोग करने की आवश्यकता नहीं है । ज़रूर। लेकिन इससे एंड्रॉइड ऐप बनाना बहुत कठिन हो जाता है और यदि आप इसे कुछ चीजों (जैसे पुश, खरीदारी, आदि) के लिए उपयोग नहीं करते हैं तो आपको सबसे बड़े एंड्रॉइड मार्केटप्लेस से प्रतिबंधित कर दिया जाता है। अधिकांश डेवलपर्स "बस इसका इस्तेमाल करते हैं"। इसका मतलब यह है कि जो कोई भी 100% ओपन सोर्स समाधान के पक्ष में अपने एंड्रॉइड डिवाइस से Google Play को मिटा देना चाहता है; पाएंगे कि उनके पास ऐप्स के लिए बहुत कम सॉफ़्टवेयर विकल्प हैं।
लोचदार खोज लें। वे खुले स्रोत थे और इसे मार रहे थे। लेकिन एडब्ल्यूएस फोर्किंग कर रहा था और वास्तव में उनकी निचली रेखा की मदद नहीं कर रहा था। इसलिए इलास्टिक ने AWS को ब्लॉक करने के लिए अपना लाइसेंस बदल दिया। AWS ने अपना कांटा शुरू किया। कुछ लोग इस कहानी में इलास्टिक की निंदा करते हैं लेकिन उन लोगों को शायद अपने व्यवसाय के अस्तित्व के लिए अमेज़ॅन से कभी नहीं लड़ना पड़ा। इस मामले में, दोनों पक्षों ने व्यापारिक लड़ाई में खुले स्रोत को हथियार बनाया।
जावा का मामला थोड़ा अलग है। जावा ओपन-सोर्स नहीं था और बाद में इसे ओपन सोर्स बना दिया गया। इसने अभी भी आईपी को भाषा के ऊपर रखा है। इसलिए मुझे परियोजना पर ओरेकल की कुछ कड़ी पकड़ मिलती है और इसे स्वीकार करते हैं। यह अच्छा है कि जहाज का हाथ स्थिर है और इसने जावा की सफलता में योगदान दिया है। Google मुकदमे के साथ समस्या यह थी कि Oracle ने एपीआई को शामिल करने के लिए अपने आईपी को फैलाने की कोशिश की। वह एक ग़लती थी।
लगभग एक दशक पहले, रोबोवीएम नामक एक स्टार्टअप ने एक ओपन सोर्स कंपाइलर जारी किया जिसने जावा को देशी आईओएस ऐप में अनुवादित किया। यह बहुत अच्छा था, और मैंने JavaOne के संस्थापक के साथ काफी बात की। उस समय हम अपना खुद का वीएम बनाने या रोबोवीएम जैसे समाधान को चुनने पर विचार कर रहे थे। हमने पूर्व के साथ समाप्त किया और अपना स्वयं का वीएम बनाया जो हमारी आवश्यकताओं के लिए बहुत आसान और बेहतर था ( यह खुला स्रोत भी है )।
वह निर्णय तकनीकी गुणों पर आधारित था और मुझे लगता है कि इसका भुगतान किया गया लेकिन रोबोवीएम टीम के लिए मेरे मन में अभी भी बहुत सम्मान है। मेरी चिंता Apple थी। वे सामान तोड़ते हैं, बहुत कुछ ... निम्न स्तर का वीएम बनाना बिल्ली और चूहे का एक खतरनाक खेल है जहां ऐप्पल अचानक कुछ बदल देगा और हम फंस जाएंगे। एक माध्यमिक चिंता मुद्रीकरण थी। मैं समझ गया था कि RoboVM टीम को अपने कर्मचारियों और संस्थापकों के वेतन का भुगतान किसी तरह करना होगा। ओपन सोर्स कंपाइलर से कोई पैसा कैसे कमाता है? ध्यान दें कि यह एक दशक पहले था और ज़िग जैसी कोई मिसाल नहीं थी जिसे हम एक टेम्पलेट के रूप में देख सकें।
कुछ बिंदु पर, Apple की नीतियों के बारे में मेरा डर भौतिक हो गया, और Apple ने कुछ प्लेटफार्मों को लक्षित करते समय एक बिटकोड आवश्यकता को जोड़ा। रोबोवीएम ने बिटकोड समर्थन पर काम करने में काफी समय बिताया और इसके स्रोत कोड को बंद करने का फैसला किया। वे समझ गए थे कि वे इसके बिना निरंतर विकास को निधि नहीं दे सकते। इसे उनके निर्णय के प्रति निर्णय के रूप में न लें। जैसा कि मैंने कहा, मुझे वह पूरी तरह से समझ में आ गया है, ओएसएस का मुद्रीकरण करना बहुत कठिन है।
जीपीएल ने समुदाय की रक्षा की, रोबोवीएम को बिटकोड प्रवास से पहले अंतिम संस्करण के लिए कोड जारी करने के लिए मजबूर किया। इसने बाद के वर्षों में कोड के कुछ कांटे की अनुमति दी लेकिन यह अभी भी अनजान है। कंपनी को Xamarin द्वारा खरीदा गया था और तुरंत बंद कर दिया गया था क्योंकि बाद में Microsoft द्वारा खरीदा गया था। जीपीएल के बिना, कोड दुर्गम हो सकता है। इसने तीसरे पक्ष को अपना कोड प्रकाशित करने के लिए भी मजबूर किया।
इस संबंध में, मैं एमआईटी, बीएसडी, अपाचे, आदि जैसे अधिक अनुमोदित लाइसेंसों के बजाय जीपीएल में एक बड़ा विश्वास रखता हूं। मुझे लगता है कि हमें एक समुदाय के रूप में ऐसे लाइसेंस को प्राथमिकता देनी चाहिए जो कॉर्पोरेट अधिकारों के विरोध में सामुदायिक अधिकारों को सुरक्षित रखे। यह परियोजना के निर्माता को एक अच्छा मुद्रीकरण विकल्प भी प्रदान करता है। एक मालिकाना लाइसेंस के रूप में बस फिर से लाइसेंस और उसके लिए शुल्क। दुर्भाग्य से, जीपीएल अक्सर कई डेवलपर्स के लिए नो-स्टार्टर होता है क्योंकि वे गलत तरीके से मानते हैं कि यह उनके लिए बुरा है। सामने है सच। जीपीएल लंबी अवधि में सामुदायिक अधिकारों को संरक्षित करने के सर्वोत्तम तरीकों में से एक है।
मैंने पहले ज़िग का उल्लेख किया था। नींव के कई अन्य उदाहरण हैं जो सफल रहे जैसे SQLite, Mozilla, आदि। इस बिंदु तक पहुंचना आम तौर पर कठिन होता है और जरूरी नहीं कि हर ओपन सोर्स प्रोजेक्ट के लिए काम करे। उदाहरण के लिए, कर्ल का उपयोग लगभग सभी लोग करते हैं, लेकिन मुझे नहीं लगता कि हम एक कर्ल फाउंडेशन देखेंगे। यह भी ध्यान दें कि ये सभी प्रोजेक्ट यूएस टेक हब में आधारित हैं। मेरे अनुभव से, अन्य क्षेत्रों में प्रायोजक प्राप्त करना बहुत कठिन है।
क्या इसका मतलब यह है कि सभी ओपन सोर्स को एक शौक या एक मेगा-ऑल इनवेरिंग प्रोजेक्ट होना चाहिए?
दुर्भाग्य से, मेरे पास अच्छे उत्तर नहीं हैं। लेकिन मुझे एक समस्या है: अति उत्साही ओपन सोर्स अधिवक्ताओं। आप मदद नहीं कर रहे हैं!
ओपन सोर्स एक कॉरपोरेट-ओनली गेम बनता जा रहा है। यह तकनीकी कंपनियों से जूझने के बीच एक हथियार के रूप में प्रयोग किया जाता है। रिटेल में इसके लिए एक नाम है: लॉस लीडर।
खुदरा क्षेत्र में, एक बड़ा सुपरमार्केट स्टोर कुछ उत्पादों को नुकसान में बेचेगा और इस आश्चर्यजनक कम कीमत का विज्ञापन करेगा। यह दर्शकों को लाता है जो रास्ते में अन्य चीजें खरीदते हैं और इसलिए सुपरमार्केट लाभ कमाता है। लेकिन इसका कारण प्रतियोगिता से बाहर होना है। प्रतियोगिता महंगी लगती है (क्योंकि वे नुकसान पर नहीं बेच सकते हैं)। वे व्यवसाय से बाहर हो जाते हैं, और बड़ी खुदरा कंपनी कीमतें बढ़ाती हैं। प्रारंभ में, ऐसा लगता है कि हमें प्रतियोगिता से जबरदस्त सौदा मिला, लेकिन अंत में हम हार गए। इस वजह से कुछ नियामक ऐसी प्रथाओं को प्रतिबंधित करते हैं क्योंकि वे बाजार को नष्ट कर देते हैं।
ओपन सोर्स का उपयोग बड़ी तकनीक द्वारा समान, निंदक तरीके से किया जाता है। वे जमीनी स्तर पर उत्साह का बहाना बनाने के लिए डेवलपर संबंध पेशेवरों की सेनाओं को काम पर रखकर "समुदाय" बनाते हैं। कभी-कभी उन्हें बाजार का मुद्रीकरण करने की आवश्यकता नहीं होती है, यह प्रतिस्पर्धा को दूर रखने के लिए पर्याप्त है।
मुझे ओपन सोर्स पसंद है और मुझे लगता है कि यह उल्लेखनीय रूप से महत्वपूर्ण है। इसलिए हमें निगमों को इसे हथियार बनाने नहीं देना चाहिए। हमें पारिस्थितिकी तंत्र के भीतर विविधता की जरूरत है और हमें छोटी, महत्वपूर्ण परियोजनाओं का समर्थन करने की जरूरत है। स्रोत परियोजनाओं या "परामर्श" को खोलने के लिए "हैंडआउट्स" का विचार टिकाऊ नहीं है।
प्रमुख निगम एक दूसरे से लड़ने के लिए एक हथियार के रूप में खुले स्रोत का उपयोग करते हैं, हमें अल्पावधि में लाभ होता है। लेकिन जैसे ही वे जीतते हैं कॉर्पोरेट मानसिकता हावी हो जाती है और वे नियंत्रण में दुगने हो जाते हैं।
मेरे द्वारा सुझाए गए समाधान हैं:
जीपीएल का प्रयोग करें - यह यहां सामुदायिक अधिकारों की रक्षा के लिए है। कोई आश्चर्य नहीं कि निगम इसे पसंद नहीं करते हैं।
ओएसएस शुद्धतावादी मत बनो - छोटी कंपनियों को पैसा बनाने की जरूरत है। वे SaaS, क्लोज्ड सोर्स एक्सटेंशन आदि की पेशकश करेंगे। कोई बात नहीं।
बड़े निगम उदार नहीं हैं - FAANG (MAANG) कंपनियों की OSS परियोजनाओं के आसपास मुझे जो वकालत दिखाई दे रही है, वह समस्याग्रस्त है। वे ओएसएस का समर्थन नहीं करते हैं। वे इसका उपयोग करते हैं और इसका लाभ उठाते हैं। मुझे गलत मत समझो, मैं उनके कोड के लिए आभारी हूं और यह आश्चर्यजनक है कि वे इसे जारी करते हैं। लेकिन हमें सतर्क रहने की जरूरत है, उनकी भरोसेमंद आवश्यकताएं हैं जो ओएसएस मानकों द्वारा "सही काम" करने से टकरा सकती हैं।
मुझे नहीं पता कि मैं जो अगला काम करूंगा वह ओएसएस होगा या नहीं। मुझे नहीं पता कि मैं जीपीएल को चुनूंगा या नहीं, जैसा कि मैंने कहा, लोगों को इससे कोई समस्या है। लेकिन मुझे यह पता है: यदि आप एक ओपन सोर्स एडवोकेट हैं। बयानबाजी को ट्यून करें। यह मददगार नहीं है।
यहाँ भी प्रकाशित हो चुकी है।.