InnerSource को परिभाषित करने का क्या मतलब है

प्रश्न #

लोग अक्सर मुझसे पूछते हैं कि InnerSource की परिभाषा क्या है। अब, InnerSource क्या है? मैं InnerSource के बारे में और इसका मेरे लिए क्या मतलब है, इस बारे में कुछ विचार साझा करना चाहता हूं।

मैं शुरुआत से ही स्पष्ट कर देता हूं: ये मेरे व्यक्तिगत विचार हैं, कोई आधिकारिक स्थिति नहीं। जबकि मैं वर्तमान में InnerSource Commons Foundation के अध्यक्ष के रूप में सेवा करता हूं, InnerSource को कई अग्रणियों द्वारा आकार दिया गया है जिनका मैं गहरा सम्मान करता हूं। उनके योगदान ने आज InnerSource को जो कुछ भी है, उसे बनाया है।

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

एक एकल निश्चित उत्तर प्रदान करने के बजाय, मैं इस प्रश्न पर विभिन्न दृष्टिकोण साझा करना चाहूंगा, ऐसे दृष्टिकोण प्रदान करना जो आपको अपनी स्वयं की परिभाषा और समझ खोजने में मदद कर सकें कि InnerSource का आपके संदर्भ में क्या मतलब है।


InnerSource के दो पथ #

हम एक दिलचस्प मोड़ पर हैं। मैं अपने कहने का मतलब और स्पष्ट करता हूं। आज InnerSource में आने वाले मूल रूप से दो प्रकार के लोग हैं:

पहला समूह उन लोगों का है जो ओपन सोर्स का अभ्यास कर रहे हैं, इसकी सहयोगी विधियों को शक्तिशाली पाया है, और स्वाभाविक रूप से इन सिद्धांतों को आंतरिक रूप से लागू किया है। उनके लिए, InnerSource केवल उस चीज़ को दिया गया नाम था जो वे पहले से ही कर रहे थे—ओपन सोर्स सहयोग की उत्कृष्टता को अपने संगठनों में लाना।

दूसरा समूह InnerSource को एक नामित पद्धति के रूप में खोजा है। उनके पास व्यापक ओपन सोर्स पृष्ठभूमि नहीं हो सकती है, लेकिन वे पहचानते हैं कि एक संगठनात्मक पद्धति के रूप में InnerSource परिवर्तन के लिए जबरदस्त मूल्य प्रदान करता है। वे InnerSource को अपना रहे हैं क्योंकि वे ओपन सोर्स प्रैक्टिशनर थे, बल्कि इसलिए कि InnerSource स्वयं संगठनात्मक लाभों का वादा करता है।

यह द्वैत हमारे समुदाय में आकर्षक अवसर पैदा करता है। पहला समूह सहज रूप से समझता है कि किसी संगठन के भीतर InnerSource को लागू करने का क्या मतलब है, साथ ही InnerSource और ओपन सोर्स के मूल्य और संस्कृति को भी। इसलिए, वे इस बात पर विचार कर सकते हैं कि InnerSource को कैसे परिभाषित किया जाना चाहिए और ओपन सोर्स के ढांचे के भीतर इसके बारे में सोच सकते हैं। दूसरी ओर, दूसरे समूह की ओपन सोर्स के साथ जरूरी तौर पर भागीदारी नहीं है, इसलिए वे इस बारे में स्पष्ट विचार खोजते हैं कि यह वास्तव में क्या है।

90%


DevOps से सीखना: नामकरण की शक्ति #

InnerSource की परिभाषात्मक चुनौती को समझने के लिए, आइए DevOps को देखते हैं। मैं इसके विकास को इस प्रकार समझता हूं: Flickr जैसी कंपनियों के प्रैक्टिशनर कुछ नवाचार कर रहे थे—विकास और संचालन के बीच साइलो को तोड़ना। जब उन्होंने अपने अनुभव साझा किए और किसी ने इसे एक नाम दिया—“DevOps”—तो कुछ जादुई हुआ। अचानक, हर जगह की कंपनियों को एहसास हुआ कि वे समान चीजें कर रही हैं, और वे सभी अपनी कहानियां साझा करने लगीं।

मुख्य अंतर्दृष्टि यह है: अभ्यास नाम से पहले मौजूद था, लेकिन नामकरण ने समुदाय बनाया। उस समुदाय के साथ उपकरण, साझा अवधारणाएं, सम्मेलन और विस्फोटक वृद्धि आई। DevOps का आविष्कार नहीं हुआ था; इसे खोजा और नाम दिया गया। नामकरण ने बाकी सब कुछ को उत्प्रेरित किया।

InnerSource एक उल्लेखनीय समान पैटर्न का पालन करता है। Tim O’Reilly ने 2000 में एक ब्लॉग पोस्ट में इसका उल्लेख किया था। 2015 में, Danese Cooper और सहयोगियों ने, तब PayPal में, InnerSource Commons को औपचारिक रूप दिया, बाद में इसे एक फाउंडेशन के रूप में स्पिन आउट किया। लेकिन उन्होंने अभ्यास का आविष्कार नहीं किया—उन्होंने उस चीज़ को नाम दिया जो लोग पहले से ही कर रहे थे।

यह नामकरण जादुई था। अचानक, अलग-थलग प्रैक्टिशनर्स को एहसास हुआ कि वे अकेले नहीं हैं। “ओह, वह चीज़ जो हम अपनी आंतरिक लाइब्रेरियों के साथ कर रहे हैं? वह InnerSource है!” समुदाय पैटर्न साझाकरण के साथ फट गया, जिससे InnerSource Patterns जैसे संसाधन बने जो सामूहिक ज्ञान को कैप्चर करते हैं।

आज DevOps क्या है? कई में से एक दृष्टिकोण #

लोग DevOps को अनगिनत तरीकों से परिभाषित करते हैं, और मैं उन सभी को कवर नहीं कर सकता। यहां एक उदाहरण है कि इसे कैसे समझा जा सकता है:

  • पारंपरिक रूप से अलग टीमों के बीच सहयोग की संस्कृति
  • प्रथाओं और स्वचालन उपकरणों का एक सेट
  • एक दर्शन जो पारंपरिक वॉटरफॉल विकास का विरोध करती है
  • पद्धतियों और ढांचों का संग्रह
  • विशेष क्षेत्रों में विस्तार: BizDevOps, DevSecOps, और उससे आगे

यह केवल एक व्याख्या है। दस प्रैक्टिशनर्स से पूछें, और आपको दस अलग जोर मिलेंगे। यह विविधता कमजोरी नहीं है—यह विकासवादी शक्ति है।

90%


“आंतरिक ओपन सोर्स” के कई अर्थ #

“आंतरिक ओपन सोर्स” वाक्यांश विरोधाभासी लगता है, और यह विरोधाभास बताता है कि InnerSource का विभिन्न संगठनों के लिए अलग-अलग मतलब क्यों है। मैं हमारे समुदायिक चर्चाओं से उभरे कुछ प्रतिनिधि उदाहरण साझा करना चाहूंगा:

ओपन सोर्स परिपक्वता के पथ के रूप में InnerSource #

कुछ के लिए, InnerSource ओपन सोर्स भागीदारी और डिजिटल परिवर्तन की दिशा में एक जैविक पथ खोलता है। यह केवल अंतिम ओपन सोर्स योगदान की तैयारी के बारे में नहीं है—यह एक ऐसा वातावरण बनाने के बारे में है जहां संगठन एक सच्ची सॉफ्टवेयर कंपनी में विकसित हो सके। Microsoft और Google जैसी कंपनियां इस यात्रा का उदाहरण देती हैं, जहां आंतरिक प्रथाएं स्वाभाविक रूप से बाहरी प्रथाओं को दर्शाने के लिए विकसित होती हैं, कंपनी के अंदर और बाहर दोनों में निर्बाध सहयोग बनाती हैं।

लेकिन निर्माण कंपनियों, खुदरा विक्रेताओं, या वित्तीय संस्थानों का क्या? जबकि वे बड़े पैमाने पर ओपन सोर्स का उपयोग कर सकते हैं, उनकी यात्रा अलग है। उनके लिए, InnerSource एक लंबे परिवर्तन में पहला कदम हो सकता है—सॉफ्टवेयर क्षमताओं का निर्माण, नवाचार संस्कृति को बढ़ावा देना, और संभवतः अंततः ओपन सोर्स के साथ जुड़ने का अपना अनूठा तरीका खोजना जो उनके व्यापारिक मॉडल के साथ संरेखित हो।

संगठनात्मक पारदर्शिता के रूप में InnerSource #

कई सांस्कृतिक परिवर्तन के लिए InnerSource की ओर आकर्षित होते हैं। यह केवल पुल रिक्वेस्ट भेजने के बारे में नहीं है—हालांकि यह इसका हिस्सा है। यह जैविक पारदर्शिता बनाने के बारे में है जहां आप कर सकते हैं:

  • अन्य टीमों को फीचर रिक्वेस्ट सबमिट करना
  • देखना कि पड़ोसी टीमें क्या बना रही हैं
  • व्यापक संगठनात्मक प्रौद्योगिकी परिदृश्य को समझना
  • सहयोग को रोकने वाले साइलो को तोड़ना
  • एक अधिक खुली, सांस लेने योग्य संगठनात्मक संस्कृति बनाना जहां जानकारी स्वाभाविक रूप से प्रवाहित होती है

यह पारदर्शिता संगठनों को कठोर पदानुक्रमों से सहयोग के जीवित नेटवर्क में बदल देती है।

अंततः, ये इंजीनियरों, उत्पाद टीमों, और संगठन के भीतर शामिल सभी की खुशी और कल्याण में योगदान देते हैं। एक सहायक कार्य वातावरण में भरोसा महसूस करना—डिफ़ॉल्ट रूप से भरोसा महसूस करना—अविश्वसनीय रूप से महत्वपूर्ण है। यह डेवलपर अनुभव से संबंधित है, और परिणामस्वरूप बेहतर प्रतिभा प्रतिधारण की ओर ले जाता है जबकि भर्ती के लिए भी सकारात्मक परिणाम देता है।

संसाधन अनुकूलन के रूप में InnerSource #

पारंपरिक पदानुक्रमित परियोजना प्रबंधन हर स्तर पर मार्जिन जोड़ता है। आवश्यकताएं नीचे की ओर प्रवाहित होती हैं, प्रत्येक परत अनिश्चितता के लिए बफर समय जोड़ती है। जब तक काम कार्यान्वयन तक पहुंचता है, समयसीमा फूली हुई होती है और इंजीनियर दबाव में होते हैं।

InnerSource इसे उलट देता है। समस्याओं के सबसे करीब के लोग उन्हें सबसे अच्छा समझते हैं। वे कैस्केडिंग मीटिंग्स और अनुमोदन के बिना प्राथमिकता दे सकते हैं, चर्चा कर सकते हैं, और समस्याओं को हल कर सकते हैं। यह हमेशा सही नहीं है—फील्ड टीमें केवल अपने फील्ड को जानती हैं—लेकिन जब रणनीतिक निरीक्षण के साथ संतुलित होती है, तो यह शक्तिशाली है।

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


परिभाषा दुविधा: संदर्भ ही सब कुछ है #

कई अर्थों की यह चुनौती InnerSource के लिए अनूठी नहीं है। विचार करें कि Open Source Program Office (OSPO) के वकील आंतरिक रूप से ओपन सोर्स को कैसे बढ़ावा देते हैं। वे बिल्कुल विभिन्न दर्शकों के लिए अलग संदेश का उपयोग करते हैं क्योंकि प्रत्येक गतिविधि को विभिन्न हितधारकों से समर्थन की आवश्यकता होती है, और संगठन की प्रत्येक परत के अलग हित और चिंताएं होती हैं।

InnerSource वकालत के लिए, संदेश कुछ इस प्रकार दिख सकता है:

इंजीनियरों के लिए: “प्रतिभाशाली सहयोगियों के साथ सहयोग करें, सर्वोत्तम कोड से सीखें, अपनी तत्काल टीम से परे रोमांचक परियोजनाओं में योगदान दें”

मध्यम प्रबंधन के लिए: “दोहराव कम करें, दक्षता बढ़ाएं, पुन: उपयोग और सहयोग के माध्यम से डिलीवरी में तेजी लाएं”

अधिकारियों के लिए: “लागत कम करें, नवाचार वेग बढ़ाएं और शीर्ष प्रतिभा को बनाए रखें”

एक ही InnerSource पहल एक साथ इन सभी लक्ष्यों की सेवा करती है, लेकिन आप विभिन्न दर्शकों के लिए विभिन्न पहलुओं पर जोर देते हैं। यह धोखा नहीं है—यह इस बात की पहचान है कि InnerSource, किसी भी परिवर्तनकारी पद्धति की तरह, कई स्तरों पर मूल्य प्रदान करता है।

आपकी InnerSource परिभाषा केवल दर्शक-निर्भर नहीं है—यह चरण-निर्भर है। और यह बिल्कुल ठीक है।


आपकी InnerSource यात्रा: एक विकसित होती परिभाषा #

तो InnerSource क्या है? यह वही है जो आप इसे परिभाषित करते हैं।

शायद भविष्य में, InnerSource Commons Foundation एक स्पष्ट, अधिक संप्रेषणीय परिभाषा विकसित करेगा जो तुरंत स्पष्ट कर देगी कि InnerSource क्या है। व्यक्तिगत रूप से, मैं उस दिन की प्रतीक्षा करता हूं, हालांकि मैं पहचानता हूं कि इतनी विविधता के बीच ऐसी परिभाषा बनाना एक अविश्वसनीय रूप से कठिन कार्य है।

इसके अलावा, आपकी परिभाषा विकसित हो सकती है और होनी चाहिए। InnerSource जो आपकी यात्रा शुरू करने में मदद करता है, वह तीन साल बाद आपके द्वारा अभ्यास किए जाने वाले InnerSource से अलग हो सकता है। आपकी परिभाषा बदल सकती है जैसे-जैसे आपका संगठन परिपक्व होता है, जैसे-जैसे आपकी चुनौतियां बदलती हैं, जैसे-जैसे आपकी समझ गहरी होती है।

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

90%


कार्य का आह्वान #

सही परिभाषा की तलाश के बजाय, मैं आपको InnerSource का अनुभव करने के लिए प्रोत्साहित करता हूं:

  • आपको दिखाई देने वाली समस्या का वर्णन करते हुए एक इश्यू सबमिट करें
  • दस्तावेज़ीकरण को ठीक करने वाला पुल रिक्वेस्ट भेजें
  • दूसरी टीम से फीचर का अनुरोध करें
  • सहयोगियों के साथ अपना कोड साझा करें
  • देखें कि अन्य टीमें क्या बना रही हैं
  • संगठनात्मक सीमाओं के पार सहयोग करें

अभ्यास के माध्यम से, आप खोजेंगे कि InnerSource का आपके संगठन के लिए क्या मतलब है। आप नए पैटर्न का आविष्कार भी कर सकते हैं जिनसे हम बाकी लोग सीख सकें।

बातचीत में शामिल हों #

2025 में, जैसे-जैसे AI हमारे कोड लिखने और सहयोग करने के तरीके को बदलता है, InnerSource सिद्धांत और भी प्रासंगिक हो जाते हैं। जब AI तुरंत हजारों लाइनें उत्पन्न कर सकता है तो हम गुणवत्ता कैसे बनाए रखें? जब कोड निर्माण स्वचालित हो तो हम ज्ञान साझाकरण को कैसे संरक्षित करें? हम कैसे सुनिश्चित करें कि मानवीय निर्णय सॉफ्टवेयर विकास के केंद्र में बना रहे?

इस मुद्दे के लिए, कृपया AI युग में सहयोग पद्धति को कवर करने वाले लेख को देखें।

खैर, इन प्रश्नों के अभी तक उत्तर नहीं हैं, लेकिन मेरा मानना है कि InnerSource—खुलेपन, पारदर्शिता, प्राथमिकता प्राप्त मेंटरशिप, और स्वैच्छिक कोड योगदान पर जोर देने के साथ—इन्हें खोजने के लिए विशिष्ट रूप से स्थित है।

InnerSource के कई स्वाद हैं। आप अपना स्वयं का जोड़ सकते हैं। आप उन पैटर्न को नाम दे सकते हैं जो मौजूद हैं लेकिन स्पष्ट नहीं किए गए हैं। यही कारण है कि InnerSource रोमांचक है: यह एक बैनर है जिसके तहत एक समुदाय बढ़ता है, विकसित होता है, और नवाचार फैलाता है।

InnerSource Commons Foundation इन चर्चाओं का स्वागत करता है। हमारे समुदाय के सदस्य दैनिक आधार पर इन प्रश्नों की खोज कर रहे हैं, अनुभव साझा कर रहे हैं, और आंतरिक सहयोग का भविष्य बना रहे हैं।

तो मैं आपसे पूछता हूं: आपका InnerSource क्या है? आप इसे अपने संगठन के लिए कैसे परिभाषित करेंगे? आप कौन से पैटर्न खोजेंगे और साझा करेंगे?

आइए इन प्रश्नों को एक साथ खोजते हैं। यात्रा अभी शुरू हुई है। मैं innersourcecommons.org पर बातचीत में आपका स्वागत करने की प्रतीक्षा कर रहा हूं।

Yuki Hattori

Yuki Hattori

President of the InnerSource Commons Foundation
Sr. Architect at GitHub
Open Source Technical Advisor at IPA (Japanese government administration)
Author of two books on AI and GitHub
O’Reilly books translator for Prompt Enginnering for LLMs and two InnerSource books[1][2]
 
Opinions expressed here are my own and do not represent any organization I am affiliated with.