10.13

View in English

10.13 अंतर-संगठनात्मक सहयोग

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

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

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

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

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

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

सिफ़ारिशें

लक्ष्य के अनुरूप सहयोग का स्वरूप चुनें

कोई एक मॉडल नहीं है, इसलिए सोच-समझकर चुनें। उद्योग गठबंधन और कंसोर्टिया एक डोमेन के लिए दिशा तय करते हैं और फंडिंग जुटाते हैं। ओपन-सोर्स फ़ाउंडेशन (निष्पक्ष गैर-लाभकारी संस्थाएँ जैसे Linux Foundation या Apache Software Foundation जो साझा कोड को रखती और गवर्न करती हैं) ऐसे सॉफ़्टवेयर की मेज़बानी करते हैं जिसे कई संगठन बनाते हैं और जिन पर निर्भर रहते हैं। मानक निकाय (ISO, IETF, या W3C जैसे संगठन जो सहमत तकनीकी विनिर्देश प्रकाशित करते हैं) इंटरऑपरेबिलिटी के वे नियम बनाते हैं जिनके अनुरूप हर कोई कोड लिखता है। संयुक्त उद्यम एक साझा वाणिज्यिक लक्ष्य के लिए एक नई संयुक्त-स्वामित्व वाली इकाई बनाते हैं। सार्वजनिक-निजी भागीदारी (PPP), यानी दीर्घकालिक व्यवस्थाएँ जिनमें सरकार और निजी कंपनियाँ किसी सार्वजनिक सेवा की डिलीवरी, वित्तपोषण, और जोखिम साझा करती हैं, सार्वजनिक अधिदेश को निजी क्षमता के साथ जोड़ती हैं। अंतर-एजेंसी और क्रॉस-गवर्नमेंट सहयोग सार्वजनिक निकायों को सीधे जोड़ता है। साझा प्लेटफ़ॉर्म और साझा सेवाएँ, डेटा-शेयरिंग व्यवस्थाएँ, और कोऑपिटिशन इस टूलकिट को पूरा करते हैं। स्वरूप को लक्ष्य से मिलाएँ: हल्के-फुल्के संरेखण के लिए गठबंधन चाहिए; साझा कोड के लिए फ़ाउंडेशन चाहिए; एक टिकाऊ वाणिज्यिक वाहन के लिए संयुक्त उद्यम चाहिए।

सीमा के आर-पार निष्पक्ष गवर्नेंस स्थापित करें

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

योगदान और बौद्धिक-संपदा शर्तों को पहले से स्पष्ट करें

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

डेटा, गोपनीयता, और एंटीट्रस्ट के लिए सावधानी से अनुबंध करें

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

इंटरऑपरेबिलिटी और ओपन स्टैंडर्ड पर निर्माण करें

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

प्रोत्साहनों और विश्वास को सोच-समझकर विकसित करें

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

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

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

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

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

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

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

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

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

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

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

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

स्टार्टअप। आपका सबसे दुर्लभ संसाधन इंजीनियरिंग ध्यान है, इसलिए केवल किसी कमोडिटी डिपेंडेंसी को दोबारा बनाना बंद करने के लिए सहयोग करें, किसी मानक समिति पर प्रतिष्ठा पाने के लिए कभी नहीं। उस एक साझा लाइब्रेरी का सह-अनुरक्षण करें जिसे आप अकेले रखने का ख़र्च नहीं उठा सकते, प्रोविनेंस साफ़ रखने के लिए एक हल्का-फुल्का गवर्नेंस नोट और एक Developer Certificate of Origin उपयोग करें, और दायरे को इतना संकीर्ण रखें कि पीछे हटने की क़ीमत सिर्फ़ एक फ़ोर्क हो। गति मेज़ पर सीट से अधिक मायने रखती है: भारी-भरकम कंसोर्टियम को तब तक छोड़ें जब तक एक साझा आधार सीधे आपके अस्तित्व को ख़तरे में न डाले।

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

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

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

उदाहरण

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

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

सरकार। एक राष्ट्रीय सरकार एक साझा पहचान प्लेटफ़ॉर्म खड़ा करती है ताकि नागरिक एक बार साइन इन करके कई एजेंसियों की सेवाओं तक पहुँच सकें। प्लेटफ़ॉर्म को एक निष्पक्ष केंद्रीय निकाय द्वारा गवर्न किया जाता है, जिसका एक प्रकाशित रोडमैप और स्पष्ट निर्णय-अधिकार हैं, जबकि हर एजेंसी स्वतंत्र बनी रहती है और खुले API तथा साझा डेटा मानकों (अध्याय 3.8, 7.1) के ज़रिए एकीकृत होती है। अंतर-एजेंसी डेटा-शेयरिंग समझौते यह स्पष्ट रूप से तय करते हैं कि क्या साझा किया जा सकता है, किस उद्देश्य के लिए, और किन गोपनीयता सुरक्षा उपायों के तहत (अध्याय 4.5), ताकि किसी नागरिक का डेटा केवल उतना ही प्रवाहित हो जितना क़ानून और सहमति अनुमति देते हैं। विश्वास बनाने और मॉडल को साबित करने के लिए कम-संवेदनशील एजेंसियाँ पहले ऑनबोर्ड होती हैं, इससे पहले कि अधिक-जोखिम वाली सेवाएँ जुड़ें।

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

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

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

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

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

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

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

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

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

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

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

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

  • Elinor Ostrom, Governing the Commons: The Evolution of Institutions for Collective Action (1990): यह मूलभूत अध्ययन है कि केंद्रीय अधिकार के बिना साझा संसाधनों को कैसे बनाए रखा जाता है।
  • Henry Chesbrough, Open Innovation: The New Imperative for Creating and Profiting from Technology (2003): नवाचार के स्रोत के रूप में संगठनात्मक सीमाओं के आर-पार सहयोग।
  • The Apache Software Foundation: गवर्नेंस मॉडल, “The Apache Way,” और मेरिटोक्रेटिक निर्णय-निर्माण (apache.org)।
  • The Linux Foundation: बड़े पैमाने पर ओपन-सोर्स सहयोग के लिए निष्पक्ष होस्टिंग और गवर्नेंस (linuxfoundation.org)।
  • Karim Lakhani और अन्य, ओपन-सोर्स तथा समुदाय-आधारित नवाचार पर लेखन; और Adam Brandenburger और Barry Nalebuff, Co-opetition (1996): एक साथ सहयोग और प्रतिस्पर्धा करने की रणनीति।
  • OpenSSF (Open Source Security Foundation) और OpenChain मानक (ISO/IEC 5230): सप्लाई-चेन और लाइसेंस अनुपालन के लिए क्रॉस-ऑर्गनाइज़ेशन दृष्टिकोण।
  • साझा प्लेटफ़ॉर्मों और अंतर-एजेंसी डेटा शेयरिंग पर सरकारी डिजिटल सेवा और GovTech साहित्य (उदाहरण के लिए, राष्ट्रीय डिजिटल-सेवा और ओपन-स्टैंडर्ड मार्गदर्शन)।