InnerSource एक झूठ है - सामान्य गलतफहमियों का जवाब
जब आप YouTube पर “InnerSource” खोजते हैं, तो आपको सबसे पहले जो परिणाम मिलने की संभावना है, वह एक वीडियो है जो दावा करता है कि “InnerSource एक झूठ है।”
(लिंक: https://youtube.com/shorts/53jEP3mPP3E)
यह दृष्टिकोण एक विशिष्ट नुकसान का प्रतिनिधित्व करता है जिसमें कई लोग तब फंस जाते हैं जब वे पहली बार InnerSource के बारे में सीखते हैं।
मैं इस वीडियो को एक केस स्टडी के रूप में उपयोग करना चाहता हूं ताकि यह समझा सकूं कि यह किस प्रकार की भ्रामक निष्कर्षों को बढ़ावा देता है। यह एक गलती है जो मैंने भी अतीत में की है, और यह एक जाल है जिसमें कई लोग आसानी से फंस सकते हैं जिन्होंने इस क्षेत्र की गहराई से खोज नहीं की है। इसीलिए मैं इसे आत्म-चिंतन के साथ जांचना चाहता हूं और इन नुकसानों को सुलझाकर दूसरों को सही रास्ता खोजने में मदद करना चाहता हूं।
पहली गलतफहमी: “React का उपयोग करें ताकि दूसरे योगदान कर सकें” #
मुझे पहले इस मामले में तर्क को समझाने दें। वीडियो आंतरिक एप्लिकेशन के लिए React का उपयोग करने का सुझाव देता है “React का उपयोग करें क्योंकि अन्य लोग इसमें योगदान कर सकते हैं।” इस प्रकार का तर्क वास्तविक InnerSource चर्चाओं में शायद ही कभी सुना जाता है।
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
इस तर्क को तीन मुख्य मुद्दों में विभाजित किया जा सकता है:
- InnerSource का वास्तविक अर्थ क्या है, इसकी मौलिक गलतफहमी
- InnerSource अनुप्रयोग के लिए गलत डोमेन चुनना
- व्यक्तिगत बनाम टीम दृष्टिकोण को भ्रमित करना
InnerSource का वास्तविक अर्थ क्या है #
InnerSource कंपनी के भीतर ओपन सोर्स सिद्धांतों का अभ्यास करने के बारे में है। यह केवल “योगदान” या “योगदान प्राप्त करने” के बारे में नहीं है।
अधिकांश लोग जो ओपन सोर्स के साथ बातचीत करते हैं वे केवल “उपयोगकर्ता” हैं। कुछ केवल उपभोक्ता हैं, अन्य बग रिपोर्ट दाखिल करते हैं, और केवल एक छोटा सा हिस्सा वास्तव में पुल रिक्वेस्ट सबमिट करता है। InnerSource ओपन सोर्स सीखों को आंतरिक रूप से लागू करता है ताकि ऐसे संगठन बनाए जा सकें जो खुले हों, व्यापक रूप से सुलभ हों, पारदर्शी निर्णय लेने के साथ, और स्वामित्व और मार्गदर्शन के माध्यम से विश्वास पर आधारित टीम संबंधों के साथ। यह पारदर्शिता और सहयोग की संस्कृति बनाता है।
यही “आंतरिक रूप से ओपन सोर्स का अभ्यास करने” का अर्थ है - यह केवल “पुल रिक्वेस्ट प्राप्त करने” के बारे में नहीं है। पुल रिक्वेस्ट इस संस्कृति का केवल एक परिणाम हैं, प्राथमिक लक्ष्य नहीं।
InnerSource अनुप्रयोग के लिए कम अनुकूल डोमेन #
दूसरा मुद्दा यह है कि यह तर्क एक ऐसे डोमेन में सामने आता है जहां InnerSource और ओपन सोर्स को विशेष चुनौतियों का सामना करना पड़ता है।
यदि आप “पुल रिक्वेस्ट प्राप्त करना” या “कई लोगों को गुणवत्ता सुधारने के लिए आपके कोड का उपयोग करवाना” चाहते हैं, तो यह आपके उत्पाद की प्रकृति द्वारा सीमित हो सकता है। यह स्पष्ट है कि “उच्च-निर्भरता घटकों” या प्लेटफॉर्म-स्तरीय उपकरणों को साझा करना अंतिम-उपयोगकर्ता एप्लिकेशन की तुलना में अधिक मूल्य बनाएगा। जबकि स्ट्रीम-संरेखित टीमों को अभी भी ओपन सोर्स प्रथाओं को अपनाना चाहिए जब फायदेमंद हो, सहयोग की गतिशीलता काफी अलग होती है।
एंटरप्राइज कंपनियों के साथ काम करने के मेरे अनुभव में, प्रोजेक्ट-स्तरीय पहलों के लिए InnerSource का उपयोग करना जहां अंतिम उपयोगकर्ता “गैर-इंजीनियर” हैं, अनूठी चुनौतियां प्रस्तुत करता है। क्यों? क्योंकि अंततः, इन उत्पादों को “अंतिम उपयोगकर्ताओं” या “व्यावसायिक उपयोगकर्ताओं” की जरूरतों को पूरा करना होता है जिनके पास विकास कौशल और विकास टीमों के साथ प्रत्यक्ष संचार चैनल की कमी हो सकती है। यह जटिल, व्यक्तिगत आवश्यकताएं और लंबे संचार लीड टाइम बनाता है।
InnerSource कार्यान्वयन साझा लाइब्रेरी, प्लेटफॉर्म घटकों, विकास उपकरणों, और इंफ्रास्ट्रक्चर कोड पर लागू होने पर अपेक्षाकृत अच्छा काम करते हैं—ऐसे क्षेत्र जहां “उपयोगकर्ता” मुख्यतः अन्य डेवलपर्स हैं जो सहयोगी विकास प्रथाओं में सार्थक योगदान दे सकते हैं और उनसे लाभ उठा सकते हैं।
जबकि उपयोगकर्ता-सामना करने वाले एप्लिकेशन पर InnerSource प्रथाओं को लागू करना पारदर्शिता और बेहतर इश्यू ट्रैकिंग जैसे मूल्यवान लाभ ला सकता है (जो अकेले इसे सार्थक बनाता है)।
व्यक्तिगत बनाम टीम दृष्टिकोण #
तीसरा मुद्दा इस बात से संबंधित है कि “आप” का मतलब व्यक्ति है या टीम।
यह ध्यान रखना महत्वपूर्ण है कि InnerSource जरूरी नहीं कि किसी के कंपनी के भीतर “आपके व्यक्तिगत प्रोजेक्ट” में योगदान करने का इंतजार करने के बारे में है। जब InnerSource लागू किया जाता है, तो ऐसे मामले हो सकते हैं जहां लोग 20% समय के दौरान विकसित प्रोजेक्ट्स में योगदान करते हैं, जैसे बड़ी तकनीकी फर्मों में, लेकिन यह जरूरी नहीं कि मुख्यधारा का दृष्टिकोण हो।
InnerSource मुख्यतः इसलिए पेश किया और बनाए रखा जाता है क्योंकि यह लागत में कमी, पहिया को फिर से आविष्कार करने से बचने, तालमेल बनाने, गुणवत्ता आश्वासन, और पदानुक्रमित निर्णय लेने से संचार ओवरहेड को हटाने के माध्यम से ROI उत्पन्न करता है। इसमें आमतौर पर साझा आंतरिक लाइब्रेरी, मालिकाना प्रतिस्पर्धी लाभ घटक, या एंटरप्राइज के भीतर उच्च निर्भरता वाली चीजें शामिल होती हैं जो विशिष्ट होती हैं। और ये “व्यावसायिक लाभ” आमतौर पर अधिकांश मामलों में “टीम संचालन” में वापस प्रवाहित होते हैं। अंततः, यह सब टीमों और संगठनों के लिए ROI के बारे में है। यदि हम टीमों के बारे में नहीं सोचते हैं, तो कोई आपको प्रोजेक्ट्स में योगदान करने से रोक देगा। आपको अपने ROI को उचित ठहराना होगा चाहे वह अल्पकालिक हो या दीर्घकालिक।
InnerSource के बारे में जो अनूठी बात है वह यह है कि यह मौलिक रूप से टीम-से-टीम सहयोग के बारे में है। यहीं पर अधिकांश कार्यान्वयन अंततः पहुंचते हैं। यह जरूरी नहीं कि व्यक्ति यादृच्छिक रूप से सुविधाजनक व्यक्तिगत प्रोजेक्ट्स में योगदान करें। यह आमतौर पर होस्ट टीम और गेस्ट टीम संबंधों के माध्यम से लागू किया जाता है, जहां गेस्ट टीमें होस्ट टीमों द्वारा बनाए रखे गए भागों के साथ चलती हैं। अधिकांश एंटरप्राइजेज में परिभाषित भूमिकाओं और जिम्मेदारियों वाले कर्मचारी होते हैं, और सहयोग इन संरचनाओं के भीतर होता है।
इसलिए, InnerSource विशेष रूप से प्रभावी होता है जब प्लेटफॉर्म टीमों और स्ट्रीम-संरेखित टीमों (गेस्ट टीमों और होस्ट टीमों) के बीच संबंध स्थापित होते हैं। स्ट्रीम-संरेखित टीमों या व्यक्तियों के बीच सक्रिय सह-निर्माण प्राकृतिक रूप से सफल होने के लिए अधिक अनिश्चित हैं।
ऐसे परिदृश्यों के आधार पर सभी InnerSource की आलोचना करना जिनके काम करने की संभावना नहीं है, कोई तार्किक अर्थ नहीं रखता।
दूसरी गलतफहमी: “यह वास्तविक कंपनियों में कभी नहीं होता” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
वास्तव में, यह हो रहा है। केस स्टडीज इसे साबित करती हैं। बिंदु।
तीसरी गलतफहमी: “99.69% InnerSource प्रोजेक्ट्स असफल होंगे” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
यह सही हो सकता है इस पर निर्भर करते हुए कि आप “InnerSource” को कैसे परिभाषित करते हैं। जैसा कि पहले उल्लेख किया गया है, InnerSource “PR योगदान प्राप्त करने” के बारे में नहीं है।
हालांकि, तीन महत्वपूर्ण बिंदुओं पर विचार करना है:
- InnerSource विशेष रूप से रणनीतिक घटकों पर लागू होता है - यह सभी घटकों के लिए आवश्यक नहीं है
- लाभ सक्रिय योगदान से परे विस्तृत होते हैं
- ओपन सोर्स में भी वही “असफलता दर” समस्या है
InnerSource एक कॉर्पोरेट रणनीति है #
जब लोग InnerSource के बारे में सोचते हैं, तो वे कभी-कभी “एंटरप्राइज के भीतर सभी कोड साझा करना” या “हर कोई सब कुछ में योगदान करना” जैसे कट्टरपंथी विचारों की कल्पना करते हैं। वे कंपनी के भीतर सैकड़ों साझा रिपॉजिटरी की कल्पना कर सकते हैं जिसमें हर कोई सक्रिय रूप से योगदान का आदान-प्रदान कर रहा हो। जैसे ओपन सोर्स कंपनियों के लिए एक रणनीति है, InnerSource भी प्राथमिकताओं के साथ एक कॉर्पोरेट रणनीति है। कंपनियां पहले “जो साझा करने योग्य है” उसे साझा करती हैं।
इसलिए, कोडबेस की वास्तविक संख्या जहां टीमों के बीच कोड सक्रिय रूप से प्रवाहित होता है और जीवंत क्रॉस-टीम सहयोग होता है, अपेक्षाकृत छोटी है। यह वास्तव में एकल-अंकीय प्रतिशत हो सकती है। हालांकि, सक्रिय क्रॉस-टीम सहयोग के बिना भी, कई प्रोजेक्ट्स खुले और पारदर्शी होने से लाभ उठा सकते हैं। InnerSource के इस अर्थ में, एंटरप्राइजेज अक्सर कई और मामलों में मूल्य साझा कर सकते हैं।
जबकि InnerSource में व्यक्तिगत योगदान शामिल हैं, यह मुख्यतः टीम-से-टीम सहयोग पर केंद्रित है। इसलिए, InnerSource के माध्यम से जो साझा किया जाता है वह एंटरप्राइजेज के भीतर अपेक्षाकृत विशिष्ट होता है, या विशेष आवश्यकताओं के लिए फोर्क किए गए Linux वितरण जैसी उद्देश्य-विशिष्ट वस्तुएं हो सकती हैं। या यह केवल ओपन सोर्स-जैसी विकास संस्कृति हो सकती है, जैसे जब GitHub सभी कर्मचारियों में Ruby on Rails कोड साझा करता है।
जब हम इस प्रतिशत चर्चा को InnerSource पर शर्त लगाते हैं जो सक्रिय रूप से सहयोग करता है और सामान्य आवश्यकताओं के रूप में बनाए रखा जाता है, तो प्रतिशत वास्तव में अपेक्षाकृत कम हो सकता है। हालांकि, गेस्ट टीमों और प्लेटफॉर्म/होस्ट टीमों के बीच दस्तावेज़ीकरण पुल रिक्वेस्ट या मामूली कॉन्फ़िगरेशन परिवर्तन (छोटे पैच भेजना) जैसे छोटे सहयोग अपेक्षाकृत बार-बार होते हैं। जब आप इन सूक्ष्म-सहयोगों और पारदर्शिता लाभों को शामिल करते हैं जो डुप्लिकेट प्रयासों को रोकते हैं, तो ये संख्याएं काफी बढ़ जाती हैं।
ओपन सोर्स में भी वही “समस्या” है #
दूसरी ओर, यदि हम इसे इस तरह परिभाषित करते हैं, तो ओपन सोर्स भी एक “झूठ” होगा। क्योंकि “99.69% ओपन सोर्स प्रोजेक्ट्स असफल होंगे।” ओपन सोर्स के रूप में प्रकाशित अधिकांश कोड को योगदान नहीं मिलते। लेकिन कोई भी इसके कारण “ओपन सोर्स एक झूठ है” नहीं कहता। लोग ओपन सोर्स का पीछा करते हैं क्योंकि योगदान प्राप्त करने से परे भी लाभ हैं।
फिर से, “योगदान मिलना” InnerSource का एकमात्र मूल्य नहीं है। और यही ओपन सोर्स मूल्य के लिए भी सच है
पारदर्शिता के वास्तविक लाभ #
आंतरिक कोड को छुपाने के बजाय खुला रखना - GitHub में, राजस्व टीम के आर्किटेक्ट या समाधान इंजीनियर प्रासंगिक जानकारी खोजने के लिए स्रोत कोड की जांच कर सकते हैं, संभावित रूप से ग्राहक अनुरोधों के बहुत करीब विवरण खोज सकते हैं, सहायता बातचीत को सुगम बना सकते हैं, और मुद्दों से अधिक सटीक जानकारी निकाल सकते हैं। मैं टोक्यो में रहता हूं, और कभी-कभी परिवर्तनों और उनकी पृष्ठभूमि के बारे में कार्यान्वयन प्रश्न पूछने के लिए SF-आधारित उत्पाद टीम के जागने का इंतजार करने के बजाय, कार्यान्वयन की जांच करने के लिए Ruby कोड को देखना, या परिवर्तनों की पृष्ठभूमि की जांच करने के लिए मुद्दों पर जाना तेज़ होता है।
git blame कमांड का उपयोग करके, आप कोड के “वास्तविक” हितधारकों की पहचान कर सकते हैं और निर्णयों की पृष्ठभूमि के बारे में प्रश्न पूछ सकते हैं।
कहने की जरूरत नहीं, यही अन्य विकास टीमों पर भी लागू होता है। उन घटकों के बारे में जानकारी आसानी से उपलब्ध होना जो निर्भरताएं बना सकते हैं, स्पष्ट रूप से संचार ओवरहेड को कम करता है।
InnerSource आंतरिक रूप से ओपन सोर्स सिद्धांतों का अभ्यास करने के बारे में है। InnerSource केवल पुल रिक्वेस्ट को आगे-पीछे भेजने के बारे में नहीं है - यह पारदर्शिता सुनिश्चित करने और ओपन सोर्स-शैली सहयोग के माध्यम से लाभ प्राप्त करने के बारे में है। ये लाभ सक्रिय रूप से बनाए रखे गए रिपॉजिटरी के कुछ प्रतिशत से कहीं व्यापक सांस्कृतिक कार्यान्वयन लाभों तक विस्तृत होते हैं।
चौथी गलतफहमी: “जब आप छोड़ेंगे तो आपको वापस बुलाया जाएगा” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
संसाधन कभी-कभी अनुरक्षित हो जाते हैं, लेकिन यह InnerSource की उचित आलोचना नहीं है - यह InnerSource को ठीक से लागू करने में असफल होने की आलोचना है। यह InnerSource की आलोचना नहीं है, बल्कि रखरखाव संस्कृति की कमी की आलोचना है जहां कोई भी कोड को बनाए नहीं रखता। यह InnerSource को ठीक से लागू करने में असफल होने या इसे बिल्कुल भी नहीं मानने का परिणाम है - स्वामित्व की कमी का परिणाम।
DevOps सादृश्य #
यह InnerSource करने में असफल होने की आलोचना है, InnerSource की आलोचना नहीं। कभी-कभी यह तर्क को भ्रमित करता है। इसे DevOps शब्दों में कहें तो: यह कहने जैसा है “कंपनियां कई महीनों की धीमी समीक्षा चक्र या ऑडिट अपनाती हैं, या रिलीज़ निर्णयों के लिए प्रक्रियाएं जोड़ती हैं, इसलिए रिलीज़ तिमाही या साल में केवल दो बार होती हैं। इसलिए DevOps, जो तेज़ रिलीज़ को सक्षम करने का दावा करता है, अच्छा नहीं है।” यह इसलिए नहीं है कि DevOps पद्धति खराब है, बल्कि केवल इसलिए कि “ऐसे मामले थे जहां DevOps लागू नहीं किया जा सका।”
व्यावसायिक प्रक्रियाओं को तोड़ना अत्यंत कठिन है, और कई कंपनियों ने कहा कि DevOps असंभव था। लेकिन जब लोगों ने सोचा कि यह असंभव है, तब भी साहसी अग्रदूत थे जिन्होंने संस्कृति को बदलने के लिए कड़ी मेहनत की और DevOps हासिल किया। InnerSource के साथ भी ऐसा ही हो सकता है।
पांचवीं गलतफहमी: “आपको 100% सब कुछ का मालिक होना चाहिए” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource का मतलब कोड स्वामित्व छोड़ना है” गलत है। InnerSource वास्तव में टीमों को कोड का मालिक होने की आवश्यकता है। यह एक सामान्य गलती है। यह उन लोगों की तरह है जो रखरखाव जिम्मेदारी छोड़ना चाहते हैं और कहते हैं “चलो इसे ओपन सोर्स बनाते हैं।” यह काम नहीं करता।
व्यक्तिगत बनाम टीम स्वामित्व - क्या InnerSource मजबूत कोड स्वामित्व है? #
पहले, यह “आप” व्यक्तिगत है या बहुवचन? हालांकि संगठनों में व्यक्तियों को CODEOWNERS फ़ाइल में सूचीबद्ध किया जा सकता है, टीमें अंततः कोड की जिम्मेदारी रखती हैं। संदर्भ के अनुसार, यह संभवतः Strong Code Ownership के बारे में बात कर रहा है। लेकिन संगठनात्मक रखरखाव पर विचार करते समय यह अच्छा नहीं है। क्योंकि कर्मचारी छोड़ सकते हैं।
InnerSource Strong Code Ownership नहीं है। कम से कम, कई लोगों को जिम्मेदारी साझा करने की आवश्यकता है। यह कहते हुए, मैं स्वीकार करता हूं कि Strong Code Ownership अल्पावधि में उभर सकता है, और प्रोजेक्ट के शुरुआती चरणों में, मजबूत व्यक्तिगत इच्छा प्राकृतिक रूप से ऐसी व्यवस्थाओं का कारण बन सकती है, लेकिन यदि आप दीर्घकालिक सफलता प्राप्त करना चाहते हैं, तो अधिकार सौंपना आवश्यक है ताकि संगठन सामूहिक रूप से रखरखाव को संभाल सके।
टीम स्वामित्व के प्रकार - क्या InnerSource सामूहिक कोड स्वामित्व है? #
इस प्रकार का तर्क कभी-कभी Collective Ownership का उल्लेख कर सकता है। इस मामले में, तर्क यह भी सुझाता है कि InnerSource का मतलब सामूहिक स्वामित्व है, लेकिन यह वास्तव में अलग है। InnerSource Collective Code Ownership नहीं है InnerSource में होस्ट टीमें अंततः रखरखाव को संभालती हैं। InnerSource Weak Code Ownership है। इसलिए जबकि रखरखाव जिम्मेदारी 100% सही है, “आपको 100% का मालिक होना चाहिए और InnerSource अलग है” कहना पूरी तरह से अतार्किक है। यह वास्तव में एक गलत राय है।
जैसा कि Martin Fowler ने कोड स्वामित्व के बारे में प्रसिद्ध रूप से तर्क दिया, सभी को कोड का 100% मालिक होना (सामूहिक स्वामित्व) कभी-कभी ऐसी स्थितियां बनाता है जहां कोई भी जिम्मेदारी नहीं लेता। यह बहुत समस्याजनक है - जिम्मेदारी अस्पष्ट हो जाती है और प्रोजेक्ट्स अंततः असफल हो जाते हैं।
Weak Code Ownership मॉडल #
Weak Code Ownership में, रखरखावकर्ता मौजूद होते हैं, होस्ट टीमें प्रोजेक्ट्स को बनाए रखती हैं, और विशिष्ट भाग अन्य टीमों से विश्वसनीय कमिटर्स/रखरखावकर्ताओं को ला सकते हैं। कोई योगदान कर सकता है, कोई बनाए रख सकता है, लेकिन “आप” या “आपकी टीम” द्वारा 100% नहीं - यह काफी अलग हो सकता है। उदाहरण के लिए, 98% कोड आपकी टीम का हो सकता है, जबकि 2% अन्य टीमों का हो सकता है।
इस मामले में, याद रखें कि भले ही संगठनों में व्यक्तियों को कोड मालिकों के रूप में असाइन किया गया हो, टीमें अंततः कोड की जिम्मेदारी रखती हैं। टीमों को इसका मालिक होना चाहिए, और इस महत्वपूर्ण बिंदु को न भूलें।
छठी गलतफहमी: “कोई आप पर 7000 लाइनें गिरा देगा” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
7000-लाइन पुल रिक्वेस्ट का अचानक दिखाई देना स्वयं InnerSource संस्कृति को पेश करने में असफलता है - यह InnerSource करने से होने वाली चीज नहीं है। यह मामला चिंता कर सकता है कि InnerSource पेश करने से ऐसा सहयोग होता है, लेकिन यह पूरी तरह से गलत है।
वास्तविक समस्या #
यह तर्क InnerSource संस्कृति और सहयोगी प्रथाओं को लागू करने में असफल होने का प्रतिनिधित्व करता है, InnerSource का नहीं। 7000-लाइन कार्यान्वयन बहुत सीमित मामले हैं। यह सहयोग संस्कृति की असफलता का प्रतिनिधित्व करता है जहां 7000 लाइनें बिना किसी सूचना के अचानक पुल रिक्वेस्ट के रूप में सबमिट की जाती हैं - संगठन को इस मौलिक संस्कृति समस्या को ठीक करना चाहिए, जो InnerSource से पहले की है।
यदि आप इसे रोकना चाहते हैं, तो एक समाधान है। अपने संगठन के भीतर InnerSource संस्कृति को बढ़ावा दें:)
वास्तविकता: InnerSource वास्तव में क्या है #
InnerSource सांस्कृतिक कार्यान्वयन है - सहयोग के माध्यम से ओपन सोर्स को मिलने वाले विभिन्न लाभों का आनंद लेने के लिए ओपन सोर्स सहयोग प्रथाओं का उपयोग करना। InnerSource का अंतिम उद्देश्य केवल योगदान (पुल रिक्वेस्ट) प्राप्त करना नहीं है, बल्कि इसमें मुद्दों के माध्यम से फीचर अनुरोध, सहायता समन्वय, और विभिन्न अन्य लाभ, साथ ही निर्णय लेने में पारदर्शिता और व्यावहारिक सांस्कृतिक संवर्धन शामिल है।
इसलिए, मैं इस दावे को निश्चित रूप से खारिज करता हूं कि “पुल रिक्वेस्ट प्राप्त करने के लिए InnerSource सर्वोत्तम प्रथाओं को लागू करना एक झूठ है।”
योगदान वास्तविकता को समझना #
“Nobody ever is going to contribute”
ओपन सोर्स सहयोग में, योगदानकर्ता वास्तव में एक छोटा सा हिस्सा हैं। 1000 उपयोगकर्ताओं में से, शायद विशाल बहुमत केवल उपयोगकर्ता हैं, 20 मुद्दे या फीचर अनुरोध सबमिट कर सकते हैं, 5 पुल रिक्वेस्ट भेज सकते हैं, और शायद केवल एक रखरखावकर्ता बनता है।
फिर से, InnerSource सर्वोत्तम प्रथाएं सभी 1000 लोगों को योगदान नहीं कराएंगी। InnerSource ऐसे सहयोग को प्रेरित करने में मदद करता है, लेकिन अंततः एंटरप्राइज साइलो को तोड़ने, पारंपरिक संगठनात्मक बाधाओं से बाधित सहयोग में सुधार करने, सूचना साइलो से लीड टाइम कम करने, और ओपन सोर्स प्रथाओं का उपयोग करके संगठनात्मक संसाधन आवंटन को अनुकूलित करने का लक्ष्य रखता है।
निष्कर्ष #
जबकि इस मामले में तर्क कुछ वास्तविक चुनौतियों को छूते हैं, वे सामान्य गलतफहमियों पर आधारित हैं जिनका सामना कई लोग तब करते हैं जब वे पहली बार InnerSource के बारे में सीखते हैं। ये समुदाय में प्रसिद्ध नुकसान हैं, और यह समझ में आता है कि कैसे कोई व्यक्ति क्षेत्र की गहरी खोज के बिना इन निष्कर्षों तक पहुंच सकता है।
मुख्य अंतर्दृष्टि यह है कि InnerSource ओपन सोर्स प्रथाओं को एक कठोर ढांचे में मजबूर करने के बारे में नहीं है। इसके बजाय, यह मौलिक प्रश्न पर वापस जाने के बारे में है: हम ओपन सोर्स से क्या सीख सकते हैं? ओपन सोर्स को व्यापक दृष्टिकोण से जांचकर, हम इन सिद्धांतों को आंतरिक रूप से बेहतर तरीके से अनुकूलित कर सकते हैं।
आप इस बातचीत में शामिल हो सकते हैं और नए दृष्टिकोण ला सकते हैं। चाहे आप इस चर्चा पर निर्माण करना चाहते हैं, अधिक विशिष्ट कार्यान्वयन विवरणों का पता लगाना चाहते हैं, या इन तर्कों को पूरी तरह से चुनौती देना चाहते हैं - सभी दृष्टिकोण स्वागत हैं। सबसे महत्वपूर्ण बात यह है कि ओपन सोर्स सीखों पर व्यापक दृष्टिकोण बनाए रखना और यह कि वे आंतरिक संगठनात्मक संदर्भों में कैसे अनुवादित होते हैं।
InnerSource के बारे में व्यापक जानकारी के लिए, मैं InnerSource Commons Foundation की जांच करने की सिफारिश करता हूं। वे विविध दृष्टिकोणों और इस बारे में निरंतर संवाद का स्वागत करते हैं कि ओपन सोर्स सिद्धांत संगठनों के भीतर कैसे मूल्य बना सकते हैं।
