10.18 ओपन सोर्स प्रोग्राम ऑफ़िस (OSPO) और अपस्ट्रीम योगदान

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

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

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

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

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

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

सिफ़ारिशें

अपनी वास्तविकता के अनुरूप आकार का एक OSPO खड़ा करें

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

ज़िम्मेदारी से उपभोग करें, और सुरक्षित रास्ते को आसान रास्ता बनाएँ

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

अपस्ट्रीम योगदान करें क्योंकि यह फ़ायदेमंद है, अच्छा लगने के लिए नहीं

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

असली गवर्नेंस के साथ अपनी ख़ुद की परियोजनाएँ रिलीज़ करें

जब आप अपना बनाया सॉफ़्टवेयर ओपन-सोर्स करते हैं, तो इसे सोच-समझकर करें या बिल्कुल न करें। पहले यह तय करें कि क्या कोड एक कमोडिटी है जो साझा करने लायक़ है या एक विभेदक (differentiator) है जिसे बंद रखना बेहतर है, अध्याय 10.12 के तर्क का उपयोग करते हुए। यदि आप रिलीज़ करते हैं, तो एक ऐसा लाइसेंस चुनें जो आपके इरादे से मेल खाता हो (अपनाव अधिकतम करने के लिए अनुज्ञेय/permissive, पारितंत्र को पारस्परिक बनाए रखने के लिए कॉपीलेफ़्ट), एक लिखित गवर्नेंस मॉडल के ज़रिए दस्तावेज़ीकृत करें कि कौन क्या तय करता है, और परियोजना के नाम पर ट्रेडमार्क पंजीकृत करें ताकि आप कोड को मुक्त रखते हुए भी उसे दुरुपयोग से बचा सकें। असली संरक्षण के लिए प्रतिबद्ध रहें: एक सार्वजनिक इश्यू ट्रैकर, एक योगदान गाइड, एक आचार संहिता, और समन्वित प्रकटीकरण (coordinated disclosure) वाली एक सुरक्षा नीति ताकि रिपोर्टर जान सकें कि आप तक कैसे पहुँचें (अध्याय 4.2)। एक अनुरक्षक नामित करें और उनका समय बजट करें। धूमधाम से लॉन्च की गई और एक साल में छोड़ दी गई एक परियोजना आपकी प्रतिष्ठा को उससे कहीं अधिक नुक़सान पहुँचाती है जितना आपके द्वारा कभी शिप न की गई परियोजना पहुँचाती।

कंपनी के भीतर सहयोग के लिए InnerSource लागू करें

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

जिन अनुरक्षकों पर आप निर्भर हैं उन्हें फ़ंड करें और बनाए रखें

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

ऐसी योगदान नीति बनाएँ जो तेज़ी से मंज़ूरी दे

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

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

दृष्टिकोण	फ़ायदे	नुकसान
केंद्रीय OSPO	सुसंगत नीति, गहरी विशेषज्ञता, स्पष्ट स्वामित्व	अगर यह केवल रोकता है और कभी सक्षम नहीं बनाता तो एक बाधा बन सकता है
संघबद्ध OSPO (टीमों में चैंपियन)	स्केल करता है, निर्णयों को इंजीनियरों के क़रीब रखता है	मज़बूत समन्वय चाहिए वरना नीति अलग-अलग बहक जाती है
अपस्ट्रीम योगदान	निजी-पैच टैक्स मिटाता है, प्रभाव दिलाता है, भर्ती में मदद करता है	निरंतर प्रयास, IP समीक्षा, किसी और के शेड्यूल पर काम
निजी फ़ोर्क बनाए रखना	पूर्ण नियंत्रण, अपने समय पर शिप करें	स्थायी रखरखाव टैक्स, अपस्ट्रीम सुरक्षा फ़िक्स से दूर बहकना
अपनी ख़ुद की परियोजना रिलीज़ करना	पारितंत्र, प्रतिष्ठा, साझा रखरखाव	असली संरक्षण लागत; छोड़ देना प्रतिष्ठा को नुक़सान पहुँचाता है
अनुरक्षकों को फ़ंड करना	महत्वपूर्ण डिपेंडेंसी की रक्षा करता है, सद्भावना दिलाता है	प्रत्यक्ष लागत, और किसे फ़ंड करना है यह चुनना राजनीतिक है
कोई OSPO नहीं (तदर्थ)	शून्य सेटअप लागत	अदृश्य क़ानूनी, सुरक्षा, और स्थिरता ऋण

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

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

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

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

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

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

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

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

क्षेत्र-विशेष दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

• स्तर 1, आरंभ (Initiate): इंजीनियर बिना किसी नीति और स्वामी के ओपन सोर्स जोड़ते, पैच करते, और कभी-कभार प्रकाशित करते हैं। उपभोग, योगदान, और रिलीज़ प्रतिक्रियात्मक और तदर्थ होते हैं, व्यक्तिगत पहल से संचालित। निजी फ़ोर्क बिना ध्यान दिए जमा होते जाते हैं, कोई भी किसी अपस्ट्रीम परियोजना को फ़ंड नहीं करता, और ड्यू डिलिजेंस के दौरान कोई भी लाइसेंस सवाल का जवाब नहीं दे सकता।
• स्तर 2, विकास (Develop): बुनियादी प्रथाएँ दिखाई देती हैं लेकिन टीमों में भिन्न होती हैं। एक मोटी-मोटी उपभोग नीति और एक स्वीकृत-लाइसेंस सूची मौजूद है, और कोई ढीले तरीक़े से ज़िम्मेदार है, फिर भी योगदान धीमा और मामला-दर-मामला है और कुछ समूह दूसरों से कहीं अधिक करते हैं। कुछ महत्वपूर्ण डिपेंडेंसी ज्ञात हैं, लेकिन स्थिरता, रिलीज़, और संरक्षण असंगत बने रहते हैं।
• स्तर 3, मानकीकरण (Standardize): एक चार्टर्ड OSPO उपभोग, योगदान, रिलीज़िंग, और समुदाय का स्वामित्व रखता है, और प्रथाएँ पूरे संगठन में दस्तावेज़ीकृत और लागू हैं। स्कैनिंग और एक सॉफ़्टवेयर बिल ऑफ़ मटीरियल्स स्वचालित हैं, एक पहले से मंज़ूर कंट्रिब्यूटर एग्रीमेंट और एक तेज़ अनुमोदन रास्ता मौजूद है, रिलीज़ की गई परियोजनाएँ असली गवर्नेंस, ट्रेडमार्क, और सुरक्षा नीतियाँ रखती हैं, और InnerSource फैल रहा है। सरकारी टीमें डिफ़ॉल्ट रूप से प्रकाशित करती हैं।
• स्तर 4, प्रबंधन (Manage): ओपन-सोर्स फ़ंक्शन को आधार रेखाओं के विरुद्ध मापा और नियंत्रित किया जाता है। अनुमोदन-समय को एक लक्ष्य के विरुद्ध ट्रैक किया जाता है, योगदान की मात्रा और अपस्ट्रीम स्वीकृति दर रिपोर्ट की जाती है, डिपेंडेंसी-स्वास्थ्य और अनुरक्षक-गिनती डैशबोर्ड एकल विफलता बिंदुओं को फ़्लैग करते हैं, शीर्ष-जोखिम डिपेंडेंसी की फ़ंडेड-अनुरक्षक कवरेज की निगरानी की जाती है, और निजी पैच तथा फ़ोर्क की इन्वेंट्री तिमाही-दर-तिमाही घटती जाती है। रिलीज़ की गई परियोजनाओं के मापे गए इश्यू-प्रतिक्रिया समय हैं, अपवादों की एक लय पर समीक्षा की जाती है, और स्टार जैसे वैनिटी मापदंडों को इनके पक्ष में छोड़ दिया जाता है।
• स्तर 5, ऑर्केस्ट्रेशन (Orchestrate): ओपन सोर्स एक प्रबंधित रणनीतिक क्षमता है, जो इंजीनियरिंग, लीगल, सुरक्षा, और प्रोक्योरमेंट योजना के साथ एकीकृत है और निरंतर अनुकूलित होती है। योगदान नियमित है, महत्वपूर्ण अनुरक्षक और फ़ाउंडेशन फ़ंडेड हैं, संगठन अच्छी तरह चलाई गई परियोजनाओं का संरक्षण करता है और उन पारितंत्रों को दिशा देता है जिन पर यह निर्भर है, और InnerSource सामान्य नियम है। जुड़ाव और स्वास्थ्य मापदंड निरंतर सुधार में योगदान देते हैं, और डिपेंडेंसी, जोखिम, और अधिदेश बदलने के साथ पोर्टफ़ोलियो को पुनः संतुलित किया जाता है।

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

1. एक OSPO जो सक्षम बनाता है और एक जो रोकता है, इसके बीच रेखा कहाँ है, और आपको बाहर से कैसे पता चलेगा कि आपने कौन-सा बनाया है?
2. आप अपने कौन-से निजी पैच या फ़ोर्क को ज़रूरत के बजाय आदत के कारण ढो रहे हैं, और शीर्ष तीन को अपस्ट्रीम करने के लिए क्या करना होगा?
3. जब महत्वपूर्ण डिपेंडेंसी की सूची बजट से लंबी हो, तो आपको यह कैसे तय करना चाहिए कि किन अनुरक्षकों और फ़ाउंडेशनों को फ़ंड करना है?
4. यदि आपको अपनी अगली रिलीज़ को पहले दिन से असली गवर्नेंस, एक ट्रेडमार्क, और एक समन्वित प्रकटीकरण नीति के साथ प्रकाशित करना पड़े, तो वास्तव में क्या बदल जाएगा?
5. सार्वजनिक-क्षेत्र के पाठकों के लिए, बिना सिद्धांत को चुपचाप क्षीण किए publish-by-default से कोड को छूट देने की एक बचाव योग्य प्रक्रिया क्या है?
6. कौन-सी आंतरिक लाइब्रेरी को InnerSource से सबसे अधिक लाभ होगा, और आज किसी दूसरी टीम को आपको पुल रिक्वेस्ट भेजने से क्या रोक रहा है?

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

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

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

• Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
• Nadia Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure
• Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
• Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
• The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
• The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
• Heather Meeker, Open (Source) for Business
• Open Source Initiative, The Open Source Definition and approved-license list
• Free Software Foundation Europe, Public Money, Public Code campaign materials
• U.S. Federal Source Code Policy and Code.gov guidance