ओपन सोर्स का भविष्य

 (blog.gitbutler.com)
19 पॉइंट द्वारा xguru 2024-08-12 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • हमारी COO और सह-संस्थापक Anne पर उस समय मुकदमा किया गया था जब वह जर्मन फ़ूड कंपनी Delinero की CEO थीं। वजह यह थी कि एक सप्लायर द्वारा दिए गए raspberry jam को "Himbeermarmelade" लेबल किया गया था, जबकि जर्मनी में एक Konfitürenverordnung (जैम विनियमन) था जिसके अनुसार किसी चीज़ को "marmalade" कहने के लिए उसमें कम-से-कम 20% citrus होना ज़रूरी था
  • यह आम तौर पर इस्तेमाल होने वाले शब्द के अर्थ के उलट एक नियम था, लेकिन चूँकि यह बहुत पहले कुछ हितधारकों द्वारा बनाया गया कानून था, इसलिए इसका पालन करना ही पड़ता था
  • मौजूदा "ओपन सोर्स" को भी इसी तरह की स्थिति में देखा जा सकता है। OSI, Konfitürenverordnung की तरह, ऐसे शब्द को अब भी सख्ती से नियंत्रित कर रहा है जो सामान्य उपयोग से अलग दिशा में विकसित हो चुका है
  • लेकिन अब सवाल यह है कि हम रचनात्मक दिशा में आगे कैसे बढ़ें?

"ओपन सोर्स" न करने का तरीका

  • जब GitButler ने क्लाइंट कोड को "Fair Sourcing" के रूप में OSI-स्वीकृत न होने वाले लाइसेंस के साथ सार्वजनिक किया, तब यह सोचने में काफ़ी समय लगा कि इसकी घोषणा कैसे की जाए
  • ज़्यादातर लोग "ओपन सोर्स" को "GitHub पर सार्वजनिक" होने के बराबर मानते हैं, और GPL/copyleft लाइसेंस के कुछ हद तक जोखिमपूर्ण अर्थों की वजह से लोग यह जाँचना भी बहुत अच्छी तरह जानते हैं कि कौन-सा लाइसेंस लागू है
  • फिर भी हम "Source Avaialable'd" जैसे अस्पष्ट शब्दों का उपयोग नहीं करना चाहते थे, और भ्रम से बचने के लिए "ओपन" शब्द इस्तेमाल किया, लेकिन इस पर हमला हुआ
  • तब यह समझ में आया कि कुछ कम संख्या में मगर बहुत मुखर लोग इस शब्द की रक्षा करने और इसे और अधिक सख्ती से परिभाषित करने की कोशिश कर रहे हैं
  • "ओपन सोर्स", "क्लोज़्ड सोर्स" का तार्किक निषेध नहीं है। GitHub पर सार्वजनिक और सहभागितापूर्ण होने की धारणा और OSI द्वारा स्वयं-नियंत्रित "ओपन सोर्स" की तकनीकी 10-परिभाषाओं के बीच जन-समझ का एक अंतर मौजूद है

ओपन सोर्स का संक्षिप्त इतिहास

  • 1950-60 के शुरुआती computing दौर में software, hardware से बँधा हुआ था, इसलिए उसे अलग से पहचानने की ज़रूरत नहीं थी, और hardware कंपनियाँ इसे स्वतंत्र रूप से वितरित करती थीं
  • 1970-80 के दशक में hardware के commodity बनने के साथ software की अपनी अलग वैल्यू बनी, और IBM, AT&T जैसी बड़ी कंपनियों ने अपने खर्च से बनाए गए source code तक पहुँच सीमित करना शुरू किया
  • इसके जवाब में Richard Stallman और अन्य लोगों ने अपना OS और ऐसे tools बनाना शुरू किया जो कॉर्पोरेट हितों से सुरक्षित हों, और GPL जैसे reciprocal लाइसेंस के ज़रिए IBM या AT&T अगर उनका काम इस्तेमाल करें तो उन्हें भी सब कुछ free software बनाना पड़े

    "अगर हम आपके खिलौनों से नहीं खेल सकते, तो आप भी हमारे खिलौनों से नहीं खेल सकते।"

    • उन्होंने इस आंदोलन को "free software" नाम दिया और Emacs तथा GNU compiler system जैसे कई अद्भुत tools बनाए। ये आज भी आधुनिक computing के अधिकांश बुनियादी tools हैं
    • free software आंदोलन का मूल फ़ोकस यह सुनिश्चित करना था कि उपयोगकर्ताओं को software चलाने, कॉपी करने, वितरित करने, अध्ययन करने, बदलने और सुधारने की स्वतंत्रता मिले। वही स्वतंत्रता जो उस समय उनके आसपास के कॉर्पोरेट हित उनसे छीन रहे थे
  • 1990 के शुरुआती दशक में Linus Torvalds के Linux kernel के साथ एक पूर्ण OS उपलब्ध हुआ, और LAMP stack जैसे free software ecosystem के बढ़ने के साथ कंपनियाँ भी इसे इस्तेमाल और इस पर निर्भर करने लगीं
  • 1997 में Eric Raymond ने निबंध "The Cathedral and the Bazaar" प्रकाशित किया, जिसमें free software development model को closed model से श्रेष्ठ बताया गया; इसी का हवाला देकर Netscape ने Navigator Suite का source code सार्वजनिक करने को उचित ठहराया
    • जब Netscape ने source code सार्वजनिक करने का फ़ैसला किया, तब Palo Alto में हुई एक strategy session में Raymond और कुछ प्रमुख Linux तथा free software developers ने मिलकर "open source" जैसा नया शब्द गढ़ने और उपयोग करने पर सहमति बनाई

    "बैठक में शामिल लोगों का मानना था कि वह व्यावहारिक और business-उन्मुख तर्क, जिसने Netscape को अपना code सार्वजनिक करने के लिए प्रेरित किया, संभावित software users और developers से संवाद करने और उन्हें community में शामिल होकर source code बनाने व सुधारने के लिए राज़ी करने का एक मूल्यवान तरीका हो सकता है। बैठक के प्रतिभागियों को यह भी लगा कि इस दृष्टिकोण की पहचान करने और इसे दार्शनिक व राजनीतिक रूप से केंद्रित ‘free software’ लेबल से अलग करने के लिए एक एकल लेबल होना उपयोगी होगा।"

  • महत्वपूर्ण बात यह है कि "free software" और "open source" के बीच वास्तव में कोई ठोस कानूनी या व्यावहारिक अंतर नहीं है
    • अधिकांश लाइसेंस दोनों परिभाषाओं में संगत और मान्य हैं
    • "open source" दरअसल सिर्फ़ एक business-friendly rebranding था, ताकि Netscape जैसी और कंपनियाँ पेशेवर source code को खोलने के विचार को अपना सकें, और Stallman तथा उनके आंदोलन के राजनीतिक लक्ष्यों को software openness की व्यावहारिकता से अलग किया जा सके
  • या जैसा free software पक्ष के लोग कहते थे

    "Open source एक development methodology है, और free software एक social movement है।"

ओपन सोर्स और GitHub का युग

  • "open source" वाक्यांश की परिभाषा और marketing 1998 में हुई थी, यानी आज से 25 साल से भी पहले। तो फिर computing के पिछले 25 वर्षों में open source और software development के क्षेत्र में क्या हुआ?
  • खासकर पिछले 10 वर्षों में GitHub और GitHub-शैली के software development ने open source पर बहुत बड़ा प्रभाव डाला है
  • 1998 में कंपनियों को open software अपनाने के लिए मनाना पड़ता था, लेकिन आज लगभग हर open source software या तो कंपनियों द्वारा लिखा जाता है या उनके समर्थन से बनता है
  • सबसे बड़े बदलावों में से एक है "development workflow का standardization", जिसमें GitHub की प्रमुख भूमिका रही है
  • पहले open software projects और corporate projects के बीच बड़ा अंतर होता था, लेकिन अब लगभग कोई अंतर नहीं बचा
    • हर कोई Git का उपयोग करता है
    • लगभग हर कोई pull requests (या merge requests, या इस feature की किसी और नकल) का उपयोग करता है
    • ज़्यादातर टीमें GitHub Flow (Trunk-based development, GitLab Flow आदि) के किसी-न-किसी रूप का उपयोग करती हैं
  • अब repository का public या private होना ही लगभग एकमात्र अंतर रह गया है। 25 साल पहले प्रक्रिया में बहुत friction था, लेकिन अब किसी चीज़ को open source बनाने के लिए लगभग कोई process change नहीं चाहिए

ओपन सोर्स का अगला चरण क्या है

  • अब जबकि लगभग सभी कंपनियाँ open source software का उपयोग भी कर रही हैं और उसे बना भी रही हैं, क्या इसका मतलब है कि open source (free software) आंदोलन सफल हो चुका है?
  • open source दुनिया के सामने अभी दो बड़ी समस्याएँ हैं: "developer sustainability" और "क्या commercial open source viable है"

डेवलपर sustainability की समस्या

  • open source पर भारी निर्भरता के साथ sustainability और maintenance की समस्याएँ सामने आ रही हैं। XZ Utils backdoor exploit इसका हाल का चर्चित उदाहरण है
  • लगभग सभी maintainers burnout और harassment से जूझ रहे हैं। open source software लिखते और maintain करते हुए पैसा कमाना लगभग असंभव है
  • अब अधिकांश open source developers और maintainers बड़ी कंपनियों द्वारा supported हैं
    • Linux, Git, Ruby, React आदि को देखें तो महत्वपूर्ण open source projects में योगदान देने वालों में से अधिकांश GitHub, Microsoft, Red Hat जैसी कंपनियों के पेशेवर कर्मचारी हैं
  • किसी developer के लिए XZ Utils जैसे project को maintain करते हुए सम्मानजनक जीविका कमाना मुश्किल है
    • आदर्श रूप में, एक कंपनी द्वारा एक developer को भुगतान करने के बजाय, हज़ारों कंपनियों को पेशेवर maintainers को छोटी-छोटी राशि देनी चाहिए
  • मुख्य समस्या यह है कि अभी इसे करने का कोई अच्छा तरीका मौजूद नहीं है
    • GitHub Sponsors, Thanks.dev, Liberapay, Tidelift जैसी आशाजनक initiatives हैं, लेकिन कंपनियों को योगदान देने के लिए सही incentive की समस्या अब भी हल नहीं हुई है
  • Sentry, OSS Pledge नाम की एक नई initiative को आगे बढ़ा रहा है, और GitButler की योजना है कि अक्टूबर में launch होने पर वह इसमें शामिल होगा
  • लेकिन क्या इस तरह का मॉडल open source ecosystem में developer sustainability की इस बड़ी और लगातार बढ़ती समस्या को हल कर पाएगा, यह अभी स्पष्ट नहीं है

commercial open source की समस्या

  • developers लंबे समय से open source और open community को पसंद करते हुए बड़े हुए हैं, इसलिए जब वे कंपनी या project शुरू करते हैं तो डिफ़ॉल्ट रूप से उसे open रखना चाहते हैं
    • लेकिन individual maintainers की तरह open source के भीतर भी corporate sustainability की समस्या है
  • Elasticsearch और Redis के मामलों की तरह, जब कोई professional software development में समय और पैसा लगाता है, तो यह जोखिम होता है कि Amazon जैसी बड़ी कंपनियाँ उसी काम का उपयोग करके सीधे प्रतिस्पर्धा करें
  • कई पेशेवर निर्माता software में निवेश करना चाहते हैं और बाद में यह नहीं चाहते कि वही उनके ख़िलाफ़ इस्तेमाल हो
    • इसका मतलब है licensing में रचनात्मक होना, या source code को बंद कर देना
  • मेरा मानना है कि Fair Source आंदोलन इस बढ़ती समस्या का एक बेहतरीन और ज़रूरी समाधान है, और यह open source ecosystem में मौजूद उस खाली जगह को भरता है जिसने पिछले कुछ वर्षों में लगातार अधिक समस्याएँ और भ्रम पैदा किया है
    • यह एक नया शब्द है, जो अधिकतर permissive, source-available, और GitHub community की भागीदारी वाले professional projects को दर्शाता है; और मुझे लगता है कि यह उस अत्यंत आवश्यक समाधान की तरह है जो पहले निजी रूप से चलाए जाने वाले अधिक projects को सार्वजनिक होने के लिए प्रोत्साहित कर सकता है

सहयोग का भविष्य

  • open source का भविष्य सिर्फ़ "Open Source" और OSI के 10 Konfitürenverordnung तक सीमित नहीं है
  • यह सबके लिए संभव और मूल्यवान Open Source, सुरक्षित निवेश के लिए आवश्यक Fair Source, और महत्वपूर्ण foundational open libraries तथा projects के लिए बड़े पैमाने की collective funding का संयोजन है
  • हमें महत्वपूर्ण open source libraries के maintenance को sustainable बनाना होगा, और sustainable commercial source-available लाइसेंस की एक श्रेणी को स्वीकार और सामान्य बनाना होगा
  • जहाँ तक संभव हो, हर चीज़ को OSI लाइसेंस के तहत open source बनाना चाहिए, और सबसे बढ़कर closed source को अतीत की चीज़ बना देना चाहिए
  • आप अभी क्या कर सकते हैं
    • closed software को Fair Source बनाइए
    • और अगर आप open source पर निर्भर हैं, तो OSS Pledge में शामिल होइए

संबंधित पढ़ाई

5 टिप्पणियां

 
bus710 2024-08-13

पूंजीवादी दुनिया में रहते हुए केवल open source पर ही पूरी तरह ध्यान केंद्रित कर पाना व्यावहारिक रूप से संभव नहीं है। दूसरी ओर, अगर कोई लाइब्रेरी या utility सचमुच बहुत महत्वपूर्ण है, तो अच्छा होगा कि उसे कंपनियों से अधिक sponsorship मिले.

user space की desktop/terminal utilities के लिए खास तौर पर इस तरह का समर्थन पाना मुश्किल होता है। अगर kernel हो तो बड़ी कंपनियाँ काफी समर्थन देती हैं, mobile के मामले में app store का commercialization अच्छी तरह स्थापित है, और web या firmware जैसी चीज़ों में कुछ हद तक market analysis करके development किया जाता है, इसलिए चिंता अपेक्षाकृत कम होती है। लेकिन जिन software और libraries का आम user अनजाने में इस्तेमाल करते हैं, उनके लिए barrier तय करना भी कठिन होता है, इसलिए उनसे कमाई करना सच में बहुत मुश्किल लगता है। open source काफी सक्रिय तो है, लेकिन उससे आगे बड़ी छलांग लगाना आसान नहीं होता।
 
bus710 2024-08-13

मैं open source से प्यार करता हूँ और उसे अक्सर इस्तेमाल करता हूँ, इसलिए मुझे लगता है कि जो लोग पर्दे के पीछे मेहनत से कई लोगों के लिए समर्पित होकर विकास करते हैं, उन्हें भी उचित license settings के ज़रिए लाभ मिलना चाहिए।
 
chabulhwi 2024-08-13

Drew Devault के लिखे लेख 'So you want to compete with or replace open source(आप open source से प्रतिस्पर्धा करना चाहते हैं या उसे बदलना चाहते हैं?)' में नीचे दिया गया वाक्य आता है।

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

free and open source software में तब साझा लाभ पैदा होता है जब अलग-अलग संगठनों से जुड़े contributor मिलकर सहयोग करते हैं, लेकिन fair source software में किसी एकाधिकार स्थिति का लाभ उठाने वाले व्यक्ति या संगठन के लिए दूसरे contributor के पास मुफ्त में सहयोग करने का कारण कम होता है या होता ही नहीं।

वैसे भी, मैं भी मानता हूँ कि fair source, closed source से बेहतर है, और मैं भी यह नहीं चाहता कि open source software के maintainer अपनी मेहनत का उचित प्रतिफल पाना चाहें लेकिन पा न सकें।

लेकिन मुझे संदेह है कि क्या fair source, open source की तरह मुफ्त development contribution का लाभ उठा पाएगा। और जब कोई अपने software को open source के रूप में वितरित करता है, तो उसे यह ध्यान में रखना चाहिए कि हो सकता है उसे किसी भी user से कोई आर्थिक प्रतिफल न मिले, और वह software cloud दिग्गजों के लिए 'मुफ्त का लंच' बन सकता है।