खरीद प्रक्रिया में ओपन सोर्स VPN क्यों अस्वीकार होता है
ओपन सोर्स पर आपत्ति करने वाला समीक्षक आम तौर पर एक आवश्यकता की रक्षा करता है, लाइसेंस की पसंद की नहीं। पूछें कौन-सी, फिर वह दस्तावेज़ तैयार करें जो उसका उत्तर देता है।
ओपन सोर्स का ज़िक्र करने वाले अस्वीकार कम ही लाइसेंसिंग पर टिकते हैं। समीक्षक आम तौर पर एक आवश्यकता की रक्षा करता है: कि कोई तैनात संस्करण का रखरखाव करे, कि स्थापित बिल्ड की पहचान हो सके, कि कोई मूल्यांकन उस चीज़ को कवर करे जो जोड़ी जा रही है, या कि कनेक्शन वापस लिया जा सके। इसके बाद की बहस आम तौर पर ऐसे सवाल का जवाब देती है जो किसी ने पूछा ही नहीं।
लाइसेंस की रक्षा से पहले पूछें कि कौन-सी आवश्यकता लागू होती है। जवाब तय करता है कि आपको कौन-सा दस्तावेज़ चाहिए।
लेबल ही आवश्यकता नहीं है
पढ़ने योग्य स्रोत कोड का अर्थ है कि प्रकाशित अमल को जाँचा जा सकता है। इसका अर्थ यह नहीं है कि किसी ने इसे जाँचा, कि गेटवे पर बना बिल्ड प्रकाशित बिल्ड से मेल खाता है, या कि कोई रखरखावकर्ता आपकी तैनाती के लिए सुधार का ऋणी है। इनमें से हर एक अलग स्वामी वाला अलग दावा है, और जिस समीक्षक को इनमें से एक चाहिए, वह बाकी से संतुष्ट नहीं होगा। दावे को ज़ोर से कहना आम तौर पर बातचीत बदलने के लिए पर्याप्त है।
उलटी गलती भी उतनी ही आम है। वाणिज्यिक लाइसेंस यह साबित नहीं करता कि सहायता उस सुविधा को कवर करती है जिस पर आप निर्भर हैं, कि किसी मूल्यांकन ने उस घटक की जाँच की जिसे आप तैनात करते हैं, या कि विक्रेता आपकी रखरखाव अवधि के भीतर सुधार भेजेगा। लाइसेंसिंग वितरण की शर्तें बताती है, जबकि खरीद के फैसले भरोसे से जुड़े होते हैं। दोनों हालतों में लाइसेंस जवाब का सबसे कम सूचनाप्रद हिस्सा है।
क्लाइंट और सेवा को भी अलग रखें। डेस्कटॉप क्लाइंट का ऑडिट साथी के गेटवे कॉन्फ़िगरेशन, उसके पहचान प्रदाता या उसके ऑपरेटरों के खाता हटाने के तरीके के बारे में कुछ नहीं कहता। आप जो भी सबूत जुटाएँ, उसे उस सीमा से मेल खाना चाहिए जिस पर साथी से भरोसा करने को कहा जा रहा है।
चिंता को दस्तावेज़ में बदलें
मंज़ूरी देने वाले से आवश्यकता एक वाक्य में कहने को कहें, फिर उस दस्तावेज़ का नाम बताएँ जो उसे पूरा करेगा। अस्पष्ट आश्वासन ही इन बातचीतों को विचारधारा की बहस में बदलता है।
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework यहाँ एक संकीर्ण कारण से उपयोगी है: यह खरीद की बातचीत को प्रथाओं और आपूर्तिकर्ता संचार की साझा शब्दावली के इर्द-गिर्द रखता है। यह लेबल पर बहस करने के बजाय परिभाषित सबूत माँगने का समर्थन करता है, और यह ऐसा प्रमाणन नहीं है जो कोई विशिष्ट VPN पास करता हो।
ध्यान दें कि बीच का स्तंभ क्या करता है। हर पंक्ति ऐसा दस्तावेज़ माँगती है जो या तो है या नहीं, और यह राय को ऐसी डिलीवरी में बदल देता है जिसे कोई बना या मना कर सकता है।
क्लाइंट को सेवा से अलग रखें
क्लाइंट एप्लिकेशन के लिए सहायता अनुबंध उस सर्वर के बारे में प्रतिबद्धता नहीं है जहाँ आपका ट्रैफ़िक पहुँचता है। सबूत पेश करने से पहले चिह्नित करें कि रास्ते के कौन-से हिस्से साथी चलाता है और कौन-से हिस्से आप उसकी ओर से चलाते हैं। दोनों को मिलाने से ऐसा दस्तावेज़ पैकेट बनता है जो गहरा दिखता है और किसी बात का जवाब नहीं देता।
अगर तैनाती आपकी है, तो साथी को शायद केवल एक पहचान और एक पहुँच नियम पर भरोसा करना होगा, जो आपकी पूरी सॉफ़्टवेयर आपूर्ति श्रृंखला पर भरोसा करने से बहुत छोटी माँग है। अगर तैनाती उसकी है, तो आपका पसंदीदा क्लाइंट अप्रासंगिक हो सकता है और गेटवे कॉन्फ़िगरेशन विषय बन जाता है। दूसरी बैठक से पहले यह तय करना कि आप किस स्थिति में हैं, एक समीक्षा चक्र बचाता है।
फिर उन परिचालन सवालों की जाँच करें जिन पर समीक्षाएँ वास्तव में विफल होती हैं: कौन खाता हटाता है, कितनी जल्दी, और बाद में कौन-सा सबूत मौजूद रहता है। हटाने की प्रक्रिया के बिना सुंदर ढंग से दस्तावेज़ीकृत मूल्यांकन भी एक खुला निष्कर्ष ही रहता है।
बहस से नहीं, फैसले से समाप्त करें
आदान-प्रदान को लिखित परिणाम के साथ समाप्त करें: स्वीकृत संस्करण, उससे जुड़े नियंत्रण, नामित ऑपरेटर, अब भी बाकी सबूत और वह तारीख जिस तक वे देय हैं। जो भी अनसुलझा है, उसे सामान्य स्वीकृति वक्तव्य में समाहित करने के बजाय शर्त के रूप में दर्ज किया जाना चाहिए।
अगर नीति किसी विशिष्ट स्वीकृत उत्पाद का नाम लेती है, तो ऐसी समानांतर व्यवस्था बनाने के बजाय अपवाद मार्ग अपनाएँ जिसे किसी ने अधिकृत नहीं किया। प्रभावशाली तकनीकी तर्क अनुमति नहीं देता, और अनौपचारिक तैनाती ऐसा निष्कर्ष है जो पकड़े जाने की प्रतीक्षा में है।
अगर कोई आवश्यकता वास्तव में पूरी नहीं हो सकती, तो स्वीकृत विकल्प पर जाएँ और बताएँ क्यों। इस अभ्यास का उद्देश्य यह तय करना है कि संगठन किस पर भरोसा कर सकता है, और स्पष्ट ‘ना’ ऐसी मंज़ूरी से बेहतर परिणाम है जिसे बाद में कोई बचा न सके।