10.12 ओपन सोर्स बनाम क्लोज़्ड सोर्स

अवलोकन और प्रेरणा

लगभग हर आधुनिक सिस्टम उस सॉफ़्टवेयर का मिश्रण है जो आपने लिखा, जो आपने खरीदा, और जो आपने मुफ़्त में लिया। इन तीन में से दो के साथ एक बुनियादी विकल्प आता है: क्या सॉफ़्टवेयर ओपन सोर्स है या क्लोज़्ड सोर्स? ओपन-सोर्स सॉफ़्टवेयर (OSS) एक ऐसे लाइसेंस के तहत वितरित किया जाता है जो हर किसी को सोर्स कोड, उस प्रोग्राम को परिभाषित करने वाले मानव-पठनीय निर्देशों, का उपयोग करने, अध्ययन करने, संशोधित करने, और पुनर्वितरित करने का अधिकार देता है। क्लोज़्ड-सोर्स सॉफ़्टवेयर, जिसे प्रोप्राइटरी सॉफ़्टवेयर भी कहा जाता है, एक तैयार उत्पाद के रूप में वितरित किया जाता है जिसका सोर्स कोड विक्रेता निजी रखता है। आपको इसे एक लाइसेंस के तहत चलाने का अधिकार मिलता है, लेकिन यह जाँचने या बदलने का नहीं कि यह कैसे काम करता है। एक मध्य श्रेणी, सोर्स-उपलब्ध सॉफ़्टवेयर, सोर्स को पढ़ने के लिए प्रकाशित करती है लेकिन उपयोग, संशोधन, या पुनर्वितरण को सीमित करती है। यह मानक परिभाषा के अनुसार दृश्यमान है लेकिन ओपन नहीं है।

तुलना करने से पहले दो स्पष्टीकरण मायने रखते हैं। पहला, “फ्री” अस्पष्ट है। समुदाय फ्री-एज़-इन-फ्रीडम (संशोधित करने और साझा करने की स्वतंत्रता, कभी-कभी “libre” लिखी जाती है) को फ्री-एज़-इन-प्राइस (शून्य लागत, “gratis”) से अलग करता है। ओपन सोर्स स्वतंत्रता के बारे में है, ज़रूरी नहीं कि कीमत के बारे में हो। दूसरा, ओपन-सोर्स लाइसेंस दो परिवारों में बँटते हैं। अनुमति देने वाले (permissive) लाइसेंस (जैसे MIT, BSD, और Apache 2.0) आपको लगभग कुछ भी करने देते हैं, जिसमें कोड को एक क्लोज़्ड उत्पाद में एम्बेड करना शामिल है। कॉपीलेफ्ट लाइसेंस (जैसे GNU General Public License, GPL) माँग करते हैं कि आप जो व्युत्पन्न कार्य वितरित करते हैं वे भी उन्हीं ओपन शर्तों के तहत जारी किए जाएँ, एक पारस्परिकता नियम जिसे आलोचक कभी-कभी “वायरल” और समर्थक “शेयर-अलाइक” कहते हैं।

यह अध्याय इस विकल्प को दो पक्षों से देखता है। एक उपभोक्ता के रूप में, आप तय करते हैं कि एक ओपन-सोर्स या प्रोप्राइटरी कंपोनेंट अपनाएँ या नहीं। एक उत्पादक के रूप में, आप तय करते हैं कि आपने जो सॉफ़्टवेयर बनाया है उसे ओपन-सोर्स करें या नहीं। बड़े एंटरप्राइज़ों और विशेष रूप से सरकार के लिए, दोनों निर्णय लाइसेंस फ़ाइल से कहीं अधिक महत्व रखते हैं। वे खरीद (अध्याय 10.3), डिजिटल संप्रभुता (अध्याय 10.11), सप्लाई-चेन सुरक्षा (अध्याय 4.2), इंटरऑपरेबिलिटी (अध्याय 3.8), और बनाना-या-खरीदना गणना (अध्याय 6.1) को छूते हैं।

मुख्य सिद्धांत

• लाइसेंस, कीमत नहीं, “ओपन” को परिभाषित करता है। लाइसेंस पढ़ें; मुफ़्त-में-उपलब्ध और ओपन-सोर्स अलग-अलग दावे हैं।
• कोई भी मॉडल स्वाभाविक रूप से अधिक सुरक्षित नहीं है। दोनों उत्कृष्ट या लापरवाह हो सकते हैं; कोड के आसपास के अभ्यास उसकी खुलेपन से अधिक मायने रखते हैं।
• खुलापन निर्भरता-कमी करने वाला एक लीवर है। सोर्स तक पहुँच विक्रेता लॉक-इन के खिलाफ़ सबसे बड़ी सुरक्षा है।
• परिचालन का बोझ हमेशा आपका होता है। मुफ़्त-में-प्राप्त कभी मुफ़्त-में-चलाना नहीं होता; स्वामित्व की कुल लागत असली कहानी बताती है।
• विभेदक बंद रहते हैं; सामान्य वस्तुएँ खुल सकती हैं। जो आपको अलग नहीं बनाता उसे ओपन-सोर्स करें; जो बनाता है उसकी रक्षा करें।
• कॉपीलेफ्ट के परिणाम होते हैं। जो उत्पाद आप वितरित करते हैं उसमें कॉपीलेफ्ट कोड एम्बेड करने से पहले पारस्परिकता दायित्वों को समझें।
• एक जीवंत समुदाय एक संपत्ति है; एक परित्यक्त रिपॉज़िटरी एक देनदारी है। केवल लाइसेंस नहीं, परियोजना को आँकें।

सिफारिशें

प्रोजेक्ट पर एक कंपोनेंट का आकलन करें, केवल लाइसेंस पर नहीं

किसी भी निर्भरता को अपनाने से पहले, चाहे वह ओपन-सोर्स हो या प्रोप्राइटरी, उसके स्वास्थ्य का आकलन करें: रिलीज़ गति, अनुरक्षकों (maintainers) की संख्या और विविधता, सुरक्षा रिपोर्टों के प्रति प्रतिक्रियाशीलता, और अपनाने की व्यापकता। एक ही अनुरक्षक वाली एक ओपन-सोर्स लाइब्रेरी और एक छोटा प्रोप्राइटरी विक्रेता एक ही बस-फ़ैक्टर जोखिम (यह खतरा कि यदि एक या कुछ प्रमुख लोग चले जाएँ तो परियोजना ढह जाती है) ले जाते हैं। एक व्यापक योगदानकर्ता आधार या एक वित्तीय रूप से मज़बूत विक्रेता वाले कंपोनेंट को प्राथमिकता दें, और आकलन को उचित परिश्रम (due diligence) के हिस्से के रूप में दर्ज करें (अध्याय 10.2, 4.2)।

लाइसेंस को एक प्रथम-श्रेणी दायित्व के रूप में पढ़ें और ट्रैक करें

हर कंपोनेंट और उसके लाइसेंस की एक सूची बनाए रखें, और यह नीति लागू करें कि कौन से लाइसेंस परिवार किन उपयोगों के लिए स्वीकार्य हैं। महत्वपूर्ण अंतर कॉपीलेफ्ट का है। अनुमति देने वाला (permissive) कोड (MIT, Apache 2.0) आमतौर पर क्लोज़्ड उत्पादों में स्वतंत्र रूप से एम्बेड किया जा सकता है। मज़बूत कॉपीलेफ्ट (GPL) आपको उन्हीं शर्तों के तहत अपने स्वयं के वितरित व्युत्पन्न को जारी करने के लिए बाध्य कर सकता है। स्वचालित सॉफ़्टवेयर कंपोज़िशन एनालिसिस (SCA) का उपयोग करें, ऐसे टूल जो आपकी निर्भरताओं को स्कैन करके कंपोनेंट, लाइसेंस, और ज्ञात भेद्यताओं की पहचान करते हैं, और एक सॉफ़्टवेयर बिल ऑफ़ मटेरियल्स (SBOM) बनाएँ, एक उत्पाद में हर कंपोनेंट की एक औपचारिक सूची (अध्याय 10.3, 4.2)।

सुरक्षा को अभ्यास से आँकें, खुलेपन से नहीं

यह मान न लें कि “बहुत सारी आँखें” तर्क (लिनस का नियम: “पर्याप्त आँखों को देखते हुए, सभी बग उथले हैं”) के कारण ओपन सोर्स सुरक्षित है। और यह मान न लें कि सिक्योरिटी-थ्रू-ऑब्स्क्यूरिटी (यह ग़लत विश्वास कि सोर्स छुपाना खामियों को छुपाता है) के माध्यम से प्रोप्राइटरी कोड सुरक्षित है। बहुत सारी आँखें तभी मदद करती हैं जब योग्य लोग वास्तव में देखते हों, और कई व्यापक रूप से उपयोग की जाने वाली परियोजनाएँ पतले ढंग से अनुरक्षित होती हैं। दोनों मॉडल सप्लाई-चेन जोखिम ले जाते हैं: ओपन सोर्स समझौता की गई या परित्यक्त निर्भरताओं के माध्यम से, प्रोप्राइटरी अपारदर्शी कोड और अपडेट चैनलों के माध्यम से जिन्हें आप जाँच नहीं सकते। मॉडल की परवाह किए बिना वर्ज़न पिन करें, उद्गम (provenance) सत्यापित करें, लगातार स्कैन करें, और एडवाइज़री पर नज़र रखें (अध्याय 4.2)।

निकास (exit) और इंटरऑपरेबिलिटी के लिए डिज़ाइन करें

ऐसे कंपोनेंट को प्राथमिकता दें जो ओपन मानकों और पोर्टेबल डेटा फ़ॉर्मेट की भाषा बोलते हैं, ताकि आप उन्हें बाद में बदल सकें (अध्याय 3.8, 10.11)। ओपन सोर्स के साथ आपको सबसे बड़ा निकास मिलता है: यदि कोई परियोजना रुक जाती है, तो आप इसे फ़ोर्क कर सकते हैं (अपनी खुद की प्रति बनाएँ और बनाए रखें)। प्रोप्राइटरी सॉफ़्टवेयर के साथ, पहले से ही सुरक्षा पर बातचीत करें: ओपन फ़ॉर्मेट में डेटा निर्यात, दस्तावेज़ीकृत API, और सोर्स-कोड एस्क्रो (एक कानूनी व्यवस्था जहाँ विक्रेता सोर्स को एक तीसरे पक्ष के पास जमा करता है, जो विक्रेता के विफल होने पर आपको जारी किया जाता है)। ऐसे डिज़ाइन करें कि किसी भी प्रकार का कोई भी एकल कंपोनेंट आपके सिस्टम को बंधक न बना सके।

स्टिकर मूल्य नहीं, स्वामित्व की कुल लागत तौलें

विकल्पों की तुलना केवल लाइसेंस शुल्क के बजाय स्वामित्व की कुल लागत (TCO) पर करें, जो अधिग्रहण, एकीकरण, संचालन, सहायता, प्रशिक्षण, अपग्रेड, और अंतिम प्रतिस्थापन सहित पूरे जीवनकाल की लागत है। ओपन सोर्स अक्सर लाइसेंसिंग लागत को उच्च परिचालन और स्टाफ़िंग लागत से बदल देता है। प्रोप्राइटरी सॉफ़्टवेयर अक्सर पूर्वानुमेय सब्सक्रिप्शन शुल्क को लॉक-इन और कम नियंत्रण से बदल देता है। मॉडल की ही लागत शामिल करें: स्व-समर्थित ओपन सोर्स को आंतरिक कौशल चाहिए, जबकि प्रोप्राइटरी सॉफ़्टवेयर को विक्रेता-प्रबंधन क्षमता चाहिए।

एक उत्पादक के रूप में, जो आपको अलग नहीं बनाता उसे ओपन-सोर्स करें

अपने स्वयं के सॉफ़्टवेयर को उसमें वर्गीकृत करें जो आपको प्रतिस्पर्धात्मक या मिशन लाभ देता है और जो अविभेदित (undifferentiated) प्लंबिंग है। विभेदकों को प्रोप्राइटरी रखें। सामान्य वस्तु (commodity) इन्फ्रास्ट्रक्चर को ओपन-सोर्स करने पर विचार करें, जहाँ एक समुदाय रखरखाव और सुधार साझा कर सकता है। सरकार के लिए, पारदर्शिता, पुनः उपयोग, और संप्रभुता (अध्याय 10.5, 10.11) के चालक के रूप में “सार्वजनिक धन, सार्वजनिक कोड” (यह सिद्धांत कि करदाताओं द्वारा वित्तपोषित सॉफ़्टवेयर डिफ़ॉल्ट रूप से सार्वजनिक रूप से उपलब्ध होना चाहिए) को तौलें। लाइसेंस को सोच-समझकर चुनें: अपनाने को अधिकतम करने के लिए अनुमति देने वाला (permissive), पारिस्थितिकी तंत्र को खुला रखने के लिए कॉपीलेफ्ट।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

आयाम	ओपन सोर्स	क्लोज़्ड / प्रोप्राइटरी
अधिग्रहण लागत	आमतौर पर अधिग्रहण के लिए शून्य	लाइसेंस या सब्सक्रिप्शन शुल्क
स्वामित्व की कुल लागत	लागत संचालन और स्टाफ़ की ओर स्थानांतरित होती है	अधिक पूर्वानुमेय, लेकिन लॉक-इन प्रीमियम
नियंत्रण और अनुकूलन	पूर्ण: आप सोर्स पढ़ और बदल सकते हैं	विक्रेता जो उजागर करता है उस तक सीमित
सहायता और जवाबदेही	समुदाय, या भुगतान किया गया तीसरा पक्ष; दबाने के लिए कोई एक गला नहीं	संविदात्मक सहायता और एक स्पष्ट जवाबदेह पक्ष
सुरक्षा मुद्रा	ऑडिट करने योग्य; यदि वास्तव में अनुरक्षित हो तो “बहुत सारी आँखें”	विक्रेता-प्रबंधित; अपारदर्शी; अस्पष्टता सुरक्षा नहीं है
दीर्घायु / परित्याग	अनुरक्षित रहने पर फ़ोर्क किया जा सकता है; फिर भी क्षीण हो सकता है	विक्रेता की व्यवहार्यता और रोडमैप पर निर्भर
विक्रेता लॉक-इन	कम: सोर्स और ओपन फ़ॉर्मेट निकास सक्षम करते हैं	मानकों और एस्क्रो द्वारा कम न किया जाए तो अधिक
पारिस्थितिकी तंत्र	खुला समुदाय और इंटरऑपरेबिलिटी	क्यूरेटेड, एकीकृत, कभी-कभी दीवार से घिरा

बार-बार आने वाला तनाव नियंत्रण बनाम सुविधा और जवाबदेही का है। ओपन सोर्स नियंत्रण, ऑडिट करने की क्षमता, और लॉक-इन से स्वतंत्रता को अधिकतम करता है, लेकिन यह आपसे क्षमता, एकीकरण, और सहायता स्वयं प्रदान करने के लिए कहता है। प्रोप्राइटरी सॉफ़्टवेयर एक समर्थित, एकीकृत, जवाबदेह उत्पाद लागू करने के लिए एक अनुबंध के साथ देता है, लेकिन यह नियंत्रण छोड़ देता है और लॉक-इन को आमंत्रित करता है। समाधान शायद ही कभी सब-या-कुछ-नहीं होता है। अधिकांश परिपक्व संपत्तियाँ ओपन-सोर्स नींव को प्रोप्राइटरी सिस्टम के साथ मिलाती हैं जहाँ सहायता, जवाबदेही, या विशेष क्षमता ट्रेड को उचित ठहराती है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. क्या हम पाइपलाइन में स्वचालित SCA और SBOM के साथ एक लाइसेंस नीति लागू करते हैं, विशेष रूप से मज़बूत कॉपीलेफ्ट को शिप होने से पहले पकड़ने के लिए? एक वितरित प्रोप्राइटरी उत्पाद में एक GPL लाइब्रेरी को एम्बेड करना आपको अपना खुद का सोर्स जारी करने के लिए बाध्य कर सकता है, और वह आश्चर्य आमतौर पर देर से सामने आता है, जब इसे उलझाना महंगा होता है। हर कंपोनेंट और उसके लाइसेंस की एक सूची बनाए रखें, लागू करें कि कौन से लाइसेंस परिवार किन उपयोगों के लिए स्वीकार्य हैं, और सॉफ़्टवेयर कंपोज़िशन एनालिसिस स्वचालित रूप से चलाएँ ताकि पाइपलाइन उल्लंघनों को रोके बजाय एक वकील द्वारा शिप के समय पकड़े जाने के। एक SBOM को नियमित रूप से बनाएँ। एक बड़ी या सरकारी संपत्ति के लिए, यह सप्लाई-चेन स्वच्छता भी है और अक्सर एक खरीद आवश्यकता। अपनी वर्तमान लाइसेंस सूची लाएँ, या यह तथ्य कि आपके पास एक नहीं है, और तय करें कि नीति का स्वामित्व किसके पास है।

2. जब हम एक निर्भरता अपनाते हैं, तो क्या हम प्रोजेक्ट स्वास्थ्य और बस-फ़ैक्टर का आकलन उचित परिश्रम के रूप में करते हैं? एक ही अनुरक्षक वाली एक ओपन-सोर्स लाइब्रेरी और एक छोटा प्रोप्राइटरी विक्रेता एक ही जोखिम ले जाते हैं: यदि एक या कुछ प्रमुख लोग चले जाएँ तो परियोजना ढह जाती है। कुछ भी अपनाने से पहले, रिलीज़ गति, अनुरक्षकों की संख्या और विविधता, सुरक्षा रिपोर्टों के प्रति प्रतिक्रियाशीलता, और अपनाने की व्यापकता का आकलन करें, और आकलन दर्ज करें। कोई भी मॉडल डिफ़ॉल्ट रूप से अधिक सुरक्षित नहीं है; “बहुत सारी आँखें” तभी मदद करती हैं जब योग्य लोग वास्तव में देखते हों, और कई व्यापक रूप से उपयोग की जाने वाली परियोजनाएँ पतले ढंग से अनुरक्षित होती हैं। अपने उत्पाद द्वारा सबसे अधिक निर्भर की जाने वाली तीन या चार निर्भरताएँ लाएँ और हर एक के लिए पूछें, यह आपकी समस्या बनने से पहले कितने लोगों को चले जाना होगा। यदि आप उत्तर नहीं दे सकते, तो यही वह आकलन है जो आप स्वयं के लिए बकाया रखते हैं।

3. जब हम प्रोप्राइटरी खरीदते हैं, तो क्या हम पहले से निकास सुरक्षा सुनिश्चित करते हैं? प्रोप्राइटरी सॉफ़्टवेयर नियंत्रण के बदले जवाबदेही और सुविधा प्रदान करता है, और छुपी हुई लागत लॉक-इन है: स्विचिंग लागत जो एक विक्रेता को कीमतें बढ़ाने या बिना अधिक उपाय के सेवा घटाने देती है। हस्ताक्षर करने से पहले सुरक्षा पर बातचीत करें, जब आपके पास अभी भी लाभ हो: ओपन फ़ॉर्मेट में डेटा निर्यात, दस्तावेज़ीकृत API, और सोर्स-कोड एस्क्रो जो विक्रेता के विफल होने पर सोर्स जारी करता है। ओपन सोर्स के साथ आपका निकास फ़ोर्क करने की क्षमता है; प्रोप्राइटरी के साथ आपको निकास को अनुबंध में लिखना होगा। अपने सबसे महत्वपूर्ण प्रोप्राइटरी सिस्टम लाएँ और पूछें कि यदि विक्रेता कीमत दोगुनी कर दे या बंद हो जाए तो वास्तव में क्या होता है। यदि उत्तर “हम फँस गए हैं” है, तो नवीनीकरण पर अनुबंध ठीक करें।

4. हम जो सॉफ़्टवेयर स्वयं बनाते हैं, उसके लिए हम कैसे तय करते हैं कि क्या ओपन-सोर्स करना है और क्या बंद रखना है, और उस निर्णय को लेने का अधिकार किसके पास है? इसे एक दिशा में गलत करें तो आप वही कोड दे देते हैं जो आपको अलग बनाता है; इसे दूसरी दिशा में गलत करें तो आप सामान्य वस्तु प्लंबिंग जमा कर लेते हैं जिसका रखरखाव एक समुदाय खुशी से साझा करता। प्रतिस्पर्धी दबाव वास्तविक हैं: इंजीनियर एक सार्वजनिक रिपॉज़िटरी के भर्ती और प्रतिष्ठा लाभ चाहते हैं, जबकि उत्पाद और कानूनी टीम प्रतिद्वंद्वियों को लाभ देने या सुरक्षा-संवेदनशील ह्यूरिस्टिक उजागर करने की चिंता करती है। अपने सिस्टम का मिशन-विभेदक बनाम अविभेदित इन्फ्रास्ट्रक्चर में एक ईमानदार वर्गीकरण लाएँ, और उस व्यक्ति या बोर्ड को नाम दें जो रिलीज़ पर साइन-ऑफ करता है, क्योंकि जो भी रिपॉज़िटरी को पुश करे उसके द्वारा लिया गया एक तदर्थ निर्णय ऐसे ही होता है जिससे कीमती हीरे रिस जाते हैं। एक बड़े एंटरप्राइज़ के लिए प्रश्न पोर्टफ़ोलियो रणनीति का है, और सरकार के लिए यह “सार्वजनिक धन, सार्वजनिक कोड” से टकराता है, यह सिद्धांत कि करदाता-वित्तपोषित सॉफ़्टवेयर डिफ़ॉल्ट रूप से सार्वजनिक होना चाहिए, इसलिए पहले से तय करें कि कौन-सी छूट (राष्ट्रीय सुरक्षा, धोखाधड़ी का पता लगाना, व्यक्तिगत डेटा) कोड को बंद रखने को उचित ठहराती है।

5. क्या हमारी बनाना-या-खरीदना तुलनाएँ स्वामित्व की पूरी कुल लागत पकड़ती हैं, या हम अभी भी शून्य लाइसेंस शुल्क को शून्य लागत मानते हैं? ओपन सोर्स के साथ सबसे आम वित्तीय गलती “अधिग्रहण के लिए मुफ़्त” को “चलाने के लिए मुफ़्त” पढ़ना है, फिर यह खोजना कि एकीकरण, संचालन, सुरक्षा प्रतिक्रिया, और भुगतान की गई सहायता किसी भी टाले गए लाइसेंस को बौना कर देती है। तनाव यह है कि एक प्रोप्राइटरी सब्सक्रिप्शन चालान पर महंगा दिखता है जबकि एक लॉक-इन प्रीमियम छुपाता है, और एक ओपन कंपोनेंट चालान पर मुफ़्त दिखता है जबकि लागत को आपके अपने स्टाफ़ पर स्थानांतरित करता है। दो या तीन वास्तविक निर्णयों के लिए एक जैसी-से-जैसी TCO मॉडल लाएँ: अधिग्रहण, एकीकरण, संचालन, सहायता, प्रशिक्षण, अपग्रेड, सुरक्षा प्रतिक्रिया, और अंतिम प्रतिस्थापन, पहले साल के बजाय पूरे जीवनकाल पर कीमत लगाई गई। एक एंटरप्राइज़ या सरकारी संपत्ति में, संचालन मॉडल की ही लागत जोड़ें, क्योंकि स्व-समर्थित ओपन सोर्स को आंतरिक कौशल चाहिए जिसे आपको भर्ती और बनाए रखना होगा, और उस तुलना को जो इन पंक्तियों को छोड़ देती है, विश्लेषण नहीं बल्कि प्रमाण के रूप में मानें।

6. क्या हम एक कंपोनेंट की सुरक्षा को उसके अभ्यासों से आँकते हैं, या हम खुलेपन के लेबल पर टिकते हैं, चाहे वह “बहुत सारी आँखें” हो या क्लोज़्ड कोड की गोपनीयता? दोनों डिफ़ॉल्ट जाल हैं: “बहुत सारी आँखें” आपकी तभी रक्षा करती हैं जब योग्य लोग वास्तव में कोड की समीक्षा करते हों, और कई व्यापक रूप से उपयोग की जाने वाली ओपन परियोजनाएँ एक थके हुए अनुरक्षक पर चलती हैं, जबकि क्लोज़्ड सोर्स जो इस पर निर्भर करता है कि हमलावर इसे न देखें वह सिक्योरिटी-थ्रू-ऑब्स्क्यूरिटी है, एक नियंत्रण नहीं। यह बहस मायने रखती है क्योंकि यह बदल देती है कि आप दुर्लभ सुरक्षा प्रयास कहाँ खर्च करते हैं, और ईमानदार उत्तर यह है कि दोनों मॉडल सप्लाई-चेन जोखिम ले जाते हैं, ओपन सोर्स समझौता की गई या परित्यक्त निर्भरताओं के माध्यम से और प्रोप्राइटरी अपारदर्शी अपडेट चैनलों के माध्यम से जिन्हें आप जाँच नहीं सकते। अपने सबसे महत्वपूर्ण कंपोनेंट के लिए प्रमाण लाएँ: उनकी वास्तव में समीक्षा कौन करता है, एडवाइज़री कितनी तेज़ी से पैच की जाती हैं, क्या वर्ज़न पिन किए गए हैं और उद्गम सत्यापित है, और क्या आप एक SBOM बनाते हैं। एक बड़ी या सरकारी संपत्ति के लिए, इसे खरीद और निरंतर स्कैनिंग दायित्वों से जोड़ें, क्योंकि एक नियामक पूछेगा कि आपने क्या जाँचा, न कि क्या सोर्स सार्वजनिक था।

क्षेत्रीय दृष्टिकोण

स्टार्टअप। कम रनवे के साथ आप ओपन-सोर्स नींव पर निर्माण करते हैं क्योंकि आप लाइसेंस शुल्क वहन नहीं कर सकते और आप चाहते हैं कि यदि कोई परियोजना रुक जाए तो फ़ोर्क करने की स्वतंत्रता हो। शिप करने से पहले एक कंपोज़िशन-एनालिसिस स्कैन चलाएँ ताकि एक मज़बूत-कॉपीलेफ्ट लाइब्रेरी चुपचाप आपको अपना खुद का सोर्स प्रकाशित करने के लिए बाध्य न करे, और अपने एकमात्र वास्तविक विभेदक को सख्ती से बंद रखें। यदि यह भर्ती में मदद करे तो एक छोटा, गैर-महत्वपूर्ण टूल ओपन-सोर्स करें, लेकिन ऐसा रखरखाव बोझ स्टाफ़ न करें जिसे आप वहन नहीं कर सकते।

लघु व्यवसाय। बिना किसी आंतरिक कानूनी या प्लेटफ़ॉर्म विशेषज्ञ के, लाइसेंस को एक ऐसे विषय के बजाय जिसे आप महारत हासिल कर सकते हैं, एक ऐसे जोखिम के रूप में मानें जिसे आपको गलत नहीं पढ़ना चाहिए। समर्थित प्रोप्राइटरी टूल या कमर्शियल ओपन-सोर्स डिस्ट्रिब्यूशन को प्राथमिकता दें जहाँ एक विक्रेता पैच और जवाबदेही का स्वामित्व रखता है, क्योंकि एक ऐसे स्टैक को स्व-समर्थन करना जिसे आप संचालित नहीं कर सकते एक झूठी मितव्ययिता है। जब आप एक मुफ़्त कंपोनेंट अपनाते हैं, तो जाँच लें कि उसका लाइसेंस आपके उपयोग की अनुमति देता है और परियोजना वास्तव में अनुरक्षित है, परित्यक्त नहीं।

एंटरप्राइज़। बड़े पैमाने पर समस्या कई टीमों में स्थिरता की है: एक लिखित लाइसेंस नीति, हर पाइपलाइन में स्वचालित सॉफ़्टवेयर कंपोज़िशन एनालिसिस और SBOM निर्माण, और प्रति-टीम आदत के बजाय TCO-आधारित बनाना-या-खरीदना निर्णय। ओपन और प्रोप्राइटरी सॉफ़्टवेयर को एक पोर्टफ़ोलियो के रूप में प्रबंधित करें, खरीद में ओपन फ़ॉर्मेट और सोर्स-कोड एस्क्रो जैसी निकास सुरक्षा को मानकीकृत करें, और महत्वपूर्ण निर्भरताओं के स्वास्थ्य को ट्रैक करें ताकि एक अकेली परित्यक्त परियोजना एक घटना न बन जाए। उत्पादक पक्ष को भी गवर्न करें, इस स्पष्ट नियम के साथ कि संगठन क्या ओपन-सोर्स करता है बनाम क्या बंद रखता है।

सरकार। खरीद नियम, पारदर्शिता दायित्व, और सार्वजनिक जवाबदेही हर विकल्प को आकार देते हैं। “सार्वजनिक धन, सार्वजनिक कोड” को तौलें, यह सिद्धांत कि करदाता-वित्तपोषित सॉफ़्टवेयर डिफ़ॉल्ट रूप से सार्वजनिक होना चाहिए, ताकि एजेंसियों में पुनः उपयोग और डिजिटल संप्रभुता को आगे बढ़ाया जा सके, साथ ही सुरक्षा-संवेदनशील या व्यक्तिगत-डेटा कोड के लिए संकीर्ण छूट तराशें। किसी भी प्रोप्राइटरी आपूर्तिकर्ता को ओपन फ़ॉर्मेट में डेटा निर्यात और सोर्स-कोड एस्क्रो प्रदान करने की माँग करें ताकि एक विक्रेता की विफलता एक सार्वजनिक सेवा को फँसा न सके, और गैर-संवेदनशील सोर्स प्रकाशित करें ताकि नागरिक उन नियमों का ऑडिट कर सकें जो उन्हें गवर्न करते हैं।

उदाहरण

स्टार्टअप। तीन-संस्थापकों वाला एक स्टार्टअप अपना पूरा उत्पाद ओपन-सोर्स नींव (Linux, एक ओपन-सोर्स डेटाबेस, एक वेब फ्रेमवर्क) पर बनाता है क्योंकि यह लाइसेंस शुल्क वहन नहीं कर सकता और चाहता है कि यदि कोई परियोजना रुक जाए तो फ़ोर्क करने की स्वतंत्रता हो। शिपिंग से पहले, एक संस्थापक एक कंपोज़िशन-एनालिसिस स्कैन चलाता है और एक मज़बूत-कॉपीलेफ्ट लाइब्रेरी पकड़ता है जो उन्हें उनका प्रोप्राइटरी मैचिंग एल्गोरिद्म प्रकाशित करने पर मजबूर कर देती, इसलिए वे इसे एक अनुमति देने वाले लाइसेंस वाले समतुल्य से बदल देते हैं। वे उस एल्गोरिद्म को, अपना एकमात्र विभेदक, सख्ती से बंद रखते हैं, और सद्भावना बनाने तथा इंजीनियरों को आकर्षित करने के लिए केवल एक छोटा आंतरिक लॉगिंग टूल ओपन-सोर्स करते हैं।

एंटरप्राइज़। एक बड़ी बीमा कंपनी अपने मुख्य प्लेटफ़ॉर्म को ओपन-सोर्स नींव पर चलाती है: Linux, एक व्यापक रूप से उपयोग किया जाने वाला ओपन-सोर्स डेटाबेस, और एक कंटेनर ऑर्केस्ट्रेटर। लेकिन यह एक प्रोप्राइटरी एक्चुएरियल-मॉडलिंग सूट खरीदती है, क्योंकि विक्रेता की डोमेन विशेषज्ञता, नियामक प्रमाणन, और सहायता अनुबंध शुल्क के लायक हैं और कोई तुलनीय ओपन विकल्प नहीं है। यह कमर्शियल ओपन सोर्स (ओपन कंपोनेंट के विक्रेता-समर्थित डिस्ट्रिब्यूशन) के लिए एक सब्सक्रिप्शन भुगतान करती है ताकि प्लंबिंग पर जवाबदेही और पैच मिलें, जबकि इसे अलग बनाने वाले मूल्य-निर्धारण एल्गोरिद्म को सख्ती से प्रोप्राइटरी और आंतरिक रखती है। TCO विश्लेषण (अध्याय 10.10) विचारधारा के बजाय हर विकल्प को संचालित करता है।

सरकार। एक “सार्वजनिक धन, सार्वजनिक कोड” नीति के तहत एक राष्ट्रीय कर एजेंसी, ओपन-सोर्स कंपोनेंट और ओपन मानकों (अध्याय 3.8) पर एक नई लाभ-पात्रता सेवा बनाती है, ताकि अन्य एजेंसियाँ इसे पुनः उपयोग कर सकें और नागरिक नियमों का ऑडिट कर सकें। यह गैर-संवेदनशील कोड को एक सार्वजनिक रिपॉज़िटरी में प्रकाशित करती है, केवल धोखाधड़ी-पहचान ह्यूरिस्टिक्स को सुरक्षा कारणों से बंद रखती है। यह विक्रेता लॉक-इन को कम करता है और डिजिटल संप्रभुता (अध्याय 10.11) को आगे बढ़ाता है। खरीद नियम (अध्याय 10.3) माँग करते हैं कि कोई भी प्रोप्राइटरी कंपोनेंट ओपन फ़ॉर्मेट में डेटा निर्यात और सोर्स-कोड एस्क्रो प्रदान करे, ताकि यह गारंटी हो कि यदि आपूर्तिकर्ता विफल हो जाए तो भी निरंतरता बनी रहे।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

ओपन सोर्स की वित्तीय अपील, इसका लाइसेंस शुल्क का अभाव, मामले का सबसे कम भरोसेमंद हिस्सा है, क्योंकि अधिग्रहण TCO का एक छोटा अंश है। स्थायी प्रतिफल रणनीतिक हैं: लॉक-इन से स्वतंत्रता (पुनः-आर्किटेक्ट किए बिना एक आपूर्तिकर्ता को बदलने या छोड़ने की क्षमता), सुरक्षा और अनुपालन के लिए ऑडिट करने की क्षमता, तेज़ अपनाना क्योंकि इंजीनियर प्रतिबद्ध होने से पहले आज़मा सकते हैं, और पूरे उद्योग में सामान्य वस्तु कोड का साझा रखरखाव। संतुलन बनाने वाली लागतें वास्तविक हैं। आपको एकीकरण, संचालन, सुरक्षा प्रतिक्रिया, और अक्सर भुगतान की गई सहायता प्रदान करनी होगी, और एक खराब चुनी गई अनुरक्षित न परियोजना किसी भी लाइसेंस से अधिक घटनाओं में लागत डाल सकती है।

प्रोप्राइटरी सॉफ़्टवेयर का व्यावसायिक मामला जवाबदेही और सुविधा है: उत्पाद के लिए जवाबदेह एक ही विक्रेता, एक सहायता अनुबंध जिसे आप लागू कर सकते हैं, एकीकृत विशेषताएँ, और पूर्वानुमेय बजटिंग। इसकी छुपी लागत लॉक-इन है, वह स्विचिंग लागत जो एक विक्रेता को कीमतें बढ़ाने या बिना अधिक उपाय के सेवा घटाने देती है, साथ ही विक्रेता की सॉल्वेंसी और रोडमैप पर निर्भरता। सामान्य व्यावसायिक मॉडल रेखा को धुंधला करते हैं: ओपन कोर (प्रोप्राइटरी भुगतान वाले ऐड-ऑन के साथ एक ओपन आधार), दोहरा लाइसेंसिंग (एक कॉपीलेफ्ट और एक भुगतान किए गए कमर्शियल लाइसेंस दोनों के तहत पेश किया गया एक ही कोड), सॉफ़्टवेयर एज़ ए सर्विस (SaaS) (सॉफ़्टवेयर एक होस्ट की गई सेवा के रूप में चलता है जिसे आप किराए पर लेते हैं, जहाँ सोर्स अप्रासंगिक हो सकता है क्योंकि आप कभी बाइनरी नहीं रखते), और सहायता/सब्सक्रिप्शन मॉडल जो अन्यथा मुफ़्त कोड के आसपास सेवा बेचते हैं।

एक उत्पादक के लिए, अपने स्वयं के गैर-विभेदक सॉफ़्टवेयर को ओपन-सोर्स करने का ROI काफ़ी बड़ा हो सकता है। बाहरी योगदानकर्ता आपके रखरखाव बोझ को कम करते हैं। परियोजना एक भर्ती और प्रतिष्ठा संपत्ति बन जाती है। बाहरी अपनाना आपके मानक को वास्तविक मानक बनाता है। सरकार के लिए, यह सार्वजनिक क्षेत्र में पारदर्शिता और पुनः उपयोग देता है। रणनीतिक नियम सरल है: सामान्य वस्तु को ओपन-सोर्स करें ताकि इसकी लागत साझा हो और एक पारिस्थितिकी तंत्र बढ़े, और विभेदक को बंद रखें ताकि उस लाभ की रक्षा हो सके जो बाकी सब कुछ फंड करता है।

एंटी-पैटर्न और नुकसान

• “मुफ़्त का मतलब मुफ़्त है”: शून्य अधिग्रहण लागत को शून्य TCO मानना, फिर संचालन और सहायता को कम-वित्तपोषित करना।
• लाइसेंस अंधापन: एक वितरित प्रोप्राइटरी उत्पाद में मज़बूत-कॉपीलेफ्ट कोड एम्बेड करना और ऐसे दायित्व ट्रिगर करना जिनकी आपने कभी योजना नहीं बनाई थी।
• “बहुत सारी आँखें” पर आस्था: यह मान लेना कि एक ओपन परियोजना का ऑडिट होता है जबकि उसके पास एक अतिश्रमित अनुरक्षक और कोई सुरक्षा समीक्षा नहीं है।
• सिक्योरिटी-थ्रू-ऑब्स्क्यूरिटी: यह विश्वास करना कि क्लोज़्ड सोर्स केवल इसलिए सुरक्षित है क्योंकि हमलावर इसे पढ़ नहीं सकते।
• वैचारिक निरपेक्षतावाद: प्रति-कंपोनेंट योग्यता और TCO पर चुनने के बजाय “सब ओपन” या “सब प्रोप्राइटरी” अनिवार्य करना।
• उद्गम को नज़रअंदाज़ करना: बिना SBOM, वर्ज़न पिनिंग, या सप्लाई-चेन सत्यापन (अध्याय 4.2) के निर्भरताएँ खींचना।
• कीमती हीरों को ओपन-सोर्स करना: वही कोड जारी करना जो आपको अलग बनाता है, अपना लाभ दे देना।
• फ़ोर्क-एंड-फ़र्गेट: एक परित्यक्त परियोजना को फ़ोर्क करना बिना फ़ोर्क को वास्तव में बनाए रखने की क्षमता के।

परिपक्वता मॉडल

स्तर 1 (आरंभ)। ओपन-सोर्स और प्रोप्राइटरी कंपोनेंट तदर्थ रूप से संपत्ति में प्रवेश करते हैं। लाइसेंस पढ़े नहीं जाते, कोई सूची या SBOM नहीं है, और मॉडलों के बीच का चुनाव केवल आदत या कीमत से किया जाता है। परित्याग और लाइसेंस जोखिम तभी सामने आते हैं जब कुछ टूटता है, और हर टीम अपने दम पर प्रतिक्रिया करती है।

स्तर 2 (विकास)। कुछ टीमें बुनियादी अभ्यास शुरू करती हैं: एक कंपोनेंट और लाइसेंस सूची, स्वीकार्य लाइसेंस का एक मोटा दृष्टिकोण, और कभी-कभार सॉफ़्टवेयर कंपोज़िशन एनालिसिस। बनाना-या-खरीदना और ओपन-या-क्लोज़्ड निर्णय लिख लिए जाते हैं, लेकिन अनुशासन एक टीम से दूसरी में असंगत और धब्बेदार है, इसलिए एक कॉपीलेफ्ट या बस-फ़ैक्टर आश्चर्य वहाँ अभी भी फिसल सकता है जहाँ आदत ने जड़ नहीं पकड़ी है।

स्तर 3 (मानकीकरण)। एक दस्तावेज़ीकृत फ्रेमवर्क खपत और उत्पादन दोनों को पूरे संगठन में गवर्न करता है। कंपोनेंट को TCO और प्रोजेक्ट स्वास्थ्य पर चुना जाता है, लाइसेंस को पाइपलाइन में स्वचालित रूप से लागू किया जाता है ताकि उल्लंघन एक बिल्ड को रोकें, SBOM नियमित रूप से बनाए जाते हैं, और एक स्पष्ट नीति बताती है कि संगठन क्या ओपन-सोर्स करता है बनाम क्या बंद रखता है। ओपन फ़ॉर्मेट और सोर्स-कोड एस्क्रो जैसी निकास सुरक्षा खरीद में मानक हैं, और हर टीम अपनी नहीं बल्कि एक ही नियमों का पालन करती है।

स्तर 4 (प्रबंधन)। कार्यक्रम को आधार रेखाओं के विरुद्ध मापा और नियंत्रित किया जाता है। संगठन उत्पादों में SBOM कवरेज, नीति का उल्लंघन करने वाली निर्भरताओं का हिस्सा, एक प्रकट निर्भरता भेद्यता को पैच करने का औसत समय, महत्वपूर्ण परियोजनाओं के लिए बस-फ़ैक्टर और स्वास्थ्य स्कोर, और हर विकल्प को उचित ठहराने वाले अनुमान के विरुद्ध वास्तविक TCO जैसे मेट्रिक्स को ट्रैक करता है। सीमाएँ कार्रवाई ट्रिगर करती हैं: एक कंपोनेंट जिसका रखरखाव रुक जाता है या जिसकी पैच विलंबता लक्ष्य से आगे बढ़ जाती है, उसे प्रमाण के आधार पर प्रतिस्थापन के लिए चिह्नित किया जाता है, और ओपन-या-क्लोज़्ड तथा बनाना-या-खरीदना निर्णयों की समीक्षा आदत से बचाव किए जाने के बजाय संख्याओं के विरुद्ध की जाती है।

स्तर 5 (संचालन)। ओपन-सोर्स रणनीति एक सोच-समझकर बनाई गई व्यावसायिक क्षमता है, जो पूरे संगठन में एकीकृत और निरंतर सुधारी जाती है। संगठन उन परियोजनाओं में योगदान देता है और कभी-कभी उनका संरक्षक (steward) बनता है जिन पर यह निर्भर करता है, अपने गैर-विभेदक सॉफ़्टवेयर को नियमित रूप से ओपन-सोर्स करता है, और निर्भरता-स्वास्थ्य तथा TCO डेटा को खरीद, सुरक्षा, और उत्पाद योजना में वापस फीड करता है। यह नियमित रूप से अपने ओपन और प्रोप्राइटरी सॉफ़्टवेयर के पोर्टफ़ोलियो को फिर से संतुलित करता है, लागत, जोखिम, संप्रभुता, और रणनीतिक लाभ में बदलावों के अनुकूल होता है इससे पहले कि वे एक संकट को मजबूर करें।

चर्चा के लिए विचार

• आपकी संपत्ति में कहाँ एक अकेले विक्रेता या अनुरक्षक को खोना अस्तित्व-संकट होगा, और आपकी निकास योजना क्या है?
• आपके अपने कौन से सिस्टम सामान्य वस्तुएँ हैं जिन्हें आप ओपन-सोर्स कर सकते हैं, और कौन से सच्चे विभेदक हैं जिनकी रक्षा करनी है?
• क्या आपका संगठन “बहुत सारी आँखें” को एक वास्तविक सुरक्षा नियंत्रण के रूप में मानता है या एक अपरीक्षित धारणा के रूप में?
• सार्वजनिक-क्षेत्र के पाठकों के लिए: एक “सार्वजनिक धन, सार्वजनिक कोड” डिफ़ॉल्ट आपकी अगली खरीद में क्या बदल देगा?
• आपकी TCO तुलनाएँ उन परिचालन और सहायता लागतों को कितनी अच्छी तरह पकड़ती हैं जिन्हें ओपन सोर्स आप पर स्थानांतरित करता है?

मुख्य निष्कर्ष

• ओपन बनाम क्लोज़्ड लाइसेंस द्वारा परिभाषित होता है, कीमत से नहीं; फ्री-एज़-इन-फ्रीडम और फ्री-एज़-इन-प्राइस के बीच, और अनुमति देने वाले (permissive) और कॉपीलेफ्ट के बीच अंतर जानें।
• कोई भी मॉडल स्वाभाविक रूप से अधिक सुरक्षित या सस्ता नहीं है। खुलेपन के लेबल के बजाय परियोजना के अभ्यासों और उसके पूरे TCO को आँकें।
• खुलापन लॉक-इन का सबसे मज़बूत प्रतिरोधक है, जो ऑडिट करने की क्षमता, पोर्टेबिलिटी, और फ़ोर्क करने की क्षमता देता है; प्रोप्राइटरी सॉफ़्टवेयर नियंत्रण के बदले जवाबदेही और सुविधा प्रदान करता है।
• प्रति-कंपोनेंट योग्यता पर निर्णय लें, और मॉडलों को विचारधारा से नहीं बल्कि सोच-समझकर मिलाएँ।
• एक उत्पादक के रूप में, सामान्य वस्तु को ओपन-सोर्स करें और विभेदक को बंद रखें, और सरकार में, पारदर्शिता, पुनः उपयोग, और संप्रभुता के लिए “सार्वजनिक धन, सार्वजनिक कोड” को तौलें।

संदर्भ और आगे पढ़ने के लिए

• Eric S. Raymond, The Cathedral and the Bazaar
• Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
• Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
• Adrian Cockcroft and others, various O’Reilly titles on open-source strategy and operations
• Free Software Foundation, The Free Software Definition (and the GNU General Public License texts)
• Open Source Initiative, The Open Source Definition and approved-license list
• Free Software Foundation Europe, Public Money, Public Code campaign materials
• Yochai Benkler, The Wealth of Networks