- Vendor lock-in और आक्रामक व्यावसायिक प्रथाओं के ख़तरों पर आधारित एक वास्तविक घटना की कहानी
- सार्वजनिक संस्थाएँ अपने मेल सिस्टम को open source आधारित व्यवस्था में माइग्रेट करना चाहती थीं, लेकिन उन्हें सप्लायर के अनुचित कॉन्ट्रैक्ट और निगरानी के संदेह का सामना करना पड़ा
- कॉन्ट्रैक्ट में छिपी शर्तें और एकतरफ़ा संशोधनों ने ग्राहकों के लिए स्वतंत्र रूप से निकलना रोक दिया और प्रबंधन लागत तेज़ी से बढ़ा दी
- निगरानी और ईमेल पढ़े जाने के संकेत वास्तव में सामने आने के बाद भी, संगठनों ने क़ानूनी और नैतिक प्रतिक्रिया के बजाय केवल बढ़ती लागत पर ध्यान दिया
- open source भावना का दावा करने वाली कंपनियों में भी दुरुपयोग के मामले सामने आए, जिससे पूरे उद्योग में भरोसे को नुकसान और नकारात्मक छवि ही बची
लेखक की प्रस्तावना
- यह कहानी वास्तविक अनुभवों पर आधारित है, लेकिन व्यक्तियों और कंपनियों की पहचान की सुरक्षा के लिए तकनीक, विवरण और कुछ संदर्भों को बदला और मिलाया गया है
- इसे IT उद्योग की व्यापक समस्या Vendor lock-in और आक्रामक व्यावसायिक प्रथाओं के एक प्रतिनिधि उदाहरण के रूप में पढ़ने की सलाह दी जाती है
प्रगति – नया मेल सिस्टम अपनाना
- कुछ साल पहले, एक प्रमुख सार्वजनिक संस्था (Agency A) पुराने Exchange मेल सर्वर का उपयोग कर रही थी
- लंबे समय से security updates न होने के कारण जोखिम अधिक था, और open source अपनाने की सिफारिश करने वाला नियम सामने आया
- एक बाहरी vendor ने open source मेल स्टैक आधारित managed service, अपने विस्तारों और enterprise support के साथ देने का प्रस्ताव रखा
- बाज़ार में दिखने वाले समान मूल्य स्तर जैसा होने के बावजूद, वास्तव में दी जा रही सेवा की तुलना में कीमत बहुत ज़्यादा थी
- Agency A के पास पहले से विश्वसनीय infrastructure (multi-datacenter, मज़बूत IP ranges आदि) मौजूद था
- संस्था का अनुरोध था: "इस समाधान का मूल्यांकन करें और उपयुक्त हो तो माइग्रेट करें" (लक्ष्य: लगभग 500 mailboxes और aliases)
पायलट लागू करना और सफल माइग्रेशन
- लेखक ने उस open source स्टैक को non-core environment और कुछ test ग्राहकों पर रियायती कीमत पर लागू किया और 1 साल तक बिना समस्या सत्यापित किया
- design flexibility से संतुष्ट होकर, उन्होंने Agency A को pilot migration की सिफारिश की
- नए सर्वर बनाए गए, शुरुआती प्रतिभागियों के लिए domain configuration के बाद क्रमिक माइग्रेशन किया गया
- MX records switch करने के बाद सब कुछ बिना समस्या स्थिर हो गया, और संगठन की आंतरिक टीम ने भी बिना बड़े मुद्दों के संचालन जारी रखा
चर्चा फैलना और दूसरी संस्था
- Agency B उसी managed service provider की मौजूदा ग्राहक थी
- कुल लागत 1/10 तक घटने, data autonomy मिलने और stability बढ़ने जैसे लाभ देखकर उसने माइग्रेशन में रुचि दिखाई
- लेकिन 5 साल के auto-renewal कॉन्ट्रैक्ट में अभी 2 साल बचे थे, और 6 महीने की advance notice clause के कारण कुछ समय उपलब्ध था
- उस provider की आक्रामक sales policy और प्रतिशोध की आशंका के कारण तैयारी अत्यंत गोपनीय रूप से की गई
- accounts, aliases configuration और test set पूरा होने के बाद, कॉन्ट्रैक्ट termination notice के समय के अनुसार वास्तविक माइग्रेशन की योजना बनाई गई
तीसरी संस्था का आना और अशुभ संकेत
- Agency C भी उसी supplier का उपयोग कर रही थी और उसी open source स्टैक पर माइग्रेट करने की इच्छा दिखा रही थी
- लेखक ने Agency C को अलग quotation दिया, लेकिन Agency B से संबंध का कोई उल्लेख नहीं किया
- प्रक्रिया सामान्य लग रही थी, लेकिन अचानक एक SMS संपर्क आया (संदेश: "ईमेल भेज नहीं पा रहा")
termination में रुकावट और आंतरिक जानकारी लीक होने के संकेत
- Agency B के IT प्रमुख ने बताया कि "termination में समस्या आ गई है, और अंदरूनी exit तैयारी supplier तक पहुँच गई है"
- संस्था की आंतरिक योजना और Agency C के लिए लेखक का quotation भी supplier के पास पहुँच गया
- Agency C को supplier की ओर से यह कहते हुए अनुचित प्रतिस्पर्धा और क़ानूनी धमकी दी गई कि वे "उस software के एकमात्र अधिकृत installer" हैं
- संभावित विवाद के डर से संस्था ने माइग्रेशन योजना छोड़ दी
ईमेल interception का संदेह और परीक्षण
- Agency C में यह पुष्टि हुई कि पुराने बाहरी कॉन्ट्रैक्ट मैनेजर के token-authenticated account को सभी मेल तक पहुँच की अनुमति थी
- उस व्यक्ति ने माना कि उसने supplier को "बताया" था, लेकिन लेखक का उल्लेख करने से इनकार किया
- ईमेल interception की पुष्टि के लिए विदेश में एक परिचित के ज़रिये नकली quotation भेजा गया, और उसके तुरंत बाद supplier ने उसी जानकारी का उल्लेख किया
- इससे ईमेल पढ़े जाने की संभावना बहुत अधिक होने का संकेत मिला
चौंकाने वाली कॉन्ट्रैक्ट शर्तें और supplier की प्रतिक्रिया
- IT टीम ने औपचारिक विरोध किया तो supplier ने कहा कि यह "कॉन्ट्रैक्ट की शर्तों के अनुसार संभव" है, और 2 साल पहले स्वीकार किए गए एकतरफ़ा संशोधनों की ओर इशारा किया
- संशोधित शर्तों के उदाहरण:
- notice period 6 महीने → 12 महीने
- free services को paid में बदला जा सकता है
- "security purpose" के नाम पर webmail के अलावा access block करना (और इसे वास्तव में तुरंत लागू भी किया गया)
- यह सब GDPR लागू होने से पहले के समय में संभव था, जब regulation पर्याप्त मज़बूत नहीं था
कमज़ोर प्रतिक्रिया और अतिरिक्त नुकसान
- लेखक ने fair competition और unrecognized installer विवाद पर सीधे स्पष्टीकरण देने की कोशिश की, लेकिन संपर्क के प्रयासों पर supplier ने कोई जवाब नहीं दिया
- उन्होंने दोनों संस्थाओं को क़ानूनी और नैतिक जाँच की सिफारिश की, लेकिन वास्तव में ध्यान केवल लागत वृद्धि पर गया (पहले free सुविधाओं का paid होना, 30% अतिरिक्त लागत)
- संगठनों ने आंतरिक भ्रष्टाचार या निजी डेटा के उल्लंघन से ज़्यादा केवल बजट बोझ को समस्या माना और बात वहीं समाप्त हो गई
निष्कर्ष और संकेत
- कई साल बाद, ज़िम्मेदार निदेशक सभी बदल चुके थे, और केवल तकनीकी टीम बची, जो पछतावे के साथ अधिक सावधान हो गई
- अंततः मामला एक ज़्यादा सुरक्षित लेकिन कम नवोन्मेषी provider के पास माइग्रेट होने पर समाप्त हुआ
- लेखक इस समस्या को मूल रूप से हल नहीं कर सका
- जब "open source support" का दावा करने वाली कंपनियाँ इस तरह का Vendor lock-in या अनैतिक व्यवहार दिखाती हैं, तो पूरा उद्योग उसका शिकार बनता है
- समस्या का मूल software नहीं, बल्कि उसे संभालने वाले लोगों का रवैया है
1 टिप्पणियां
Hacker News राय
कभी एक अस्थायी IT manager token authentication के ज़रिए email client से लगातार जुड़ा हुआ था, और सभी messages तक उसकी पहुँच बनी हुई थी। यही व्यक्ति पहले उस पक्ष का प्रतिनिधि था जिसने vendor के साथ मूल contract किया था। अनौपचारिक रूप से पूछने पर उसने कहा कि उसने "चेतावनी देने के लिए" संपर्क किया था, इसलिए कोई बड़ी बात नहीं थी। ऐसा व्यवहार सच में बहुत खराब लगता है। कुछ leak कर देना या नियम तोड़ देना, और फिर कहना कि "कुछ खास नहीं था" — ऐसे लोगों की वजह से। मेरे साथ काम करने वाला एक Director भी कई बार ऐसा ही कर चुका है। conference में किसी software के बारे में पता चलते ही तुरंत demo तय कर देता है और contract का प्रस्ताव रखने लगता है। फिर जिन outsourcing vendors को वह जानता है, उन्हें पहले ही काम का वादा कर देता है। बाद में पता चलता है कि उसके पास वास्तव में contract करने का अधिकार ही नहीं था, तब जाकर वह मुझसे संपर्क करता है। product selection की ज़िम्मेदारी मुझे मिलने के बाद भी ऐसा दो बार हुआ। हर बार मैं अलग manager के तहत काम कर रहा था, लेकिन दोनों ने बस यही कहा कि "कोई समस्या नहीं है"। आखिर में Director को बताया गया कि इस तरह काम का वादा करना और contract की तैयारी करना company policy का गंभीर उल्लंघन है। Director ने इसकी परवाह ही नहीं की, क्योंकि उसके हिसाब से यह आंतरिक मामला था और कोई उसे दंडित नहीं कर सकता था। बाद में जब हमने उस product की समीक्षा की, तो वह यह वादा कर रहा था कि "समय के साथ बेहतर हो जाएगा", और company का सारा data सीधे AI में जा रहा था। enterprise data security rules की कोई परवाह नहीं की जा रही थी। तब भी Director ने लापरवाही से कहा, "समस्या क्या है, सब लोग दूसरों का data पढ़ते ही हैं।" अंत में legal team ने दखल देकर AI feature बंद करवा दिया। ऐसे दुर्भावनापूर्ण या लापरवाह सहकर्मियों का सामना करना सच में बहुत मुश्किल होता है, खासकर जब वह आपसे senior हो। वे बस इसे गलती कहकर आगे बढ़ जाते हैं और कोई उन पर कार्रवाई नहीं कर पाता
मैंने Fortune 100 की दो कंपनियों में काम किया है। मैंने कई बार खुलेआम managers को vendors से personal rebate लेते देखा, और यह सब सामने होते हुए भी देखा गया। जब मैंने इसे सार्वजनिक रूप से उठाया, तो मुझे कई meetings में बुलाना बंद कर दिया गया
Director ने जो किया, वह बिल्कुल वैसा ही लगता है जैसा मैंने HR Directors को अक्सर करते देखा है। वे हर 2~3 साल में बिना किसी consultation के महंगे performance review software बदलने के बड़े शौकीन होते हैं। फिर भी आजकल उनका पसंदीदा Lattice कम से कम UX के मामले में ठीक है, लेकिन पहले इस्तेमाल किया गया PeopleSoft सच में बहुत खराब था
अनुरोध सीधा-सादा था: "इस solution का मूल्यांकन करें और उपयुक्त लगे तो migration करें।" लेकिन इसे ठीक से समझने के लिए मुझे कई बार पढ़ना पड़ा। यहाँ solution से मतलब पिछले paragraph में बताए गए vendor के बिना, सिर्फ open source stack था। पहले मुझे लगा कि इसमें vendor भी शामिल है, लेकिन फिर लगातार comparisons होने लगे तो भ्रम पैदा हुआ
मुझे भी यह बात कुछ paragraphs पढ़ने के बाद ही समझ आई
दिलचस्प। मैं तो ठीक वहीं पढ़ना बंद कर दिया था
मुझे लगा यह Oracle की बात हो सकती है। बेशक Oracle ऐसी चीज़ें कहीं ज़्यादा चालाकी से करता है, लेकिन मैं हमेशा लोगों को सलाह देता हूँ कि जहाँ तक हो सके Oracle products से दूर रहें
काश किसी दिन इस कहानी में असली नाम सामने आएँ
लेखक के अनुसार वह company बहुत बार legal action लेती है। इसलिए यह स्वाभाविक है कि वे व्यक्तिगत रूप से sue किए जाने की स्थिति से बचना चाहते हों। यहाँ तक कि उनके अपने directors भी शायद इस company से लड़ना नहीं चाहेंगे
किसी ने कहा था, "उम्मीद है कभी असली नाम सामने आएँगे।" लेकिन जवाब मिला कि "संबंधित लोगों और company की privacy की रक्षा" के लिए इसे anonymous रखा गया है। इससे यह सवाल उठता है कि क्या अब कंपनियों के भी privacy rights हैं, लेकिन मैं इस भावना को समझ सकता हूँ। मैं पहले एक ऐसी company में काम करता था जिसने एक natural disaster के दौरान बिल्कुल अस्वीकार्य काम किया था। जब मैंने इस पर सवाल उठाया, तो दंड मुझे अकेले झेलना पड़ा और बाकी सहकर्मी चुपचाप सहते रहे। आखिरकार मुझे पहला मौका मिलते ही नौकरी छोड़नी पड़ी। यह लगभग 20 साल पुरानी बात है, लेकिन आज भी उस घटना को लिखित रूप में दर्ज करना आसान नहीं है। इतने साल बीत जाने के बाद लगता है कि अब उसका क्या मतलब है, और company का leadership भी बदल चुका है, नाम भी बदल चुका है, तो बचा ही क्या है। इसलिए मेरे blog पर एक dead-man's switch है जो कई कंपनियों की बुरी हरकतें अपने-आप सार्वजनिक कर देगा, लेकिन फिर भी लगता है कि उसे देखकर भी क्या बदल जाएगा। शायद बस गुस्सा ही आए या सब बेकार लगे। इसके बावजूद, मैं HN पर हमेशा असली नाम उजागर करने की बात करने वालों में से हूँ, इसलिए अंत में मैं खुद भी विरोधाभासी हूँ
दुर्भाग्य से वे EU में हैं, जहाँ कानूनी और सांस्कृतिक रूप से शायद अभिव्यक्ति की स्वतंत्रता को उतना महत्व नहीं दिया जाता
यह व्यक्ति सच में किसी "minefield" जैसे माहौल में काम करता लगता है। हर कदम पर समस्या फट सकती है, और सामने शक्तिशाली विरोधी हैं संबंधित लिंक
हो सकता है मैं timeline या संबंधित पक्षों को लेकर भ्रमित हूँ, लेकिन जब कहा गया कि "इस company ने अपनी managed version और proprietary features जोड़कर product का प्रस्ताव रखा", तो सवाल उठता है कि क्या उसे सच में open source कहा जा सकता है
ऐसे projects बहुत हैं। उदाहरण के लिए Gitlab का open source Community Edition भी है, और paid Premium, Ultimate editions भी हैं
यह एक तरह से "कानून के शब्दों का पालन" करने जैसा मामला है। Europe के कानूनों में, खासकर European देशों के national laws में, public sector में open source के उपयोग को कई बार अनिवार्य किया जाता है। इसके पीछे interoperability सुनिश्चित करना, vendor lock-in से बचना, digital sovereignty, और "public money = public code" जैसे सिद्धांत होते हैं। किसी और के server पर open source चलाने से तकनीकी रूप से नियम का पालन हो जाता है, लेकिन open source अपनाने के असली कारण, खासकर vendor lock-in से बचने की भावना को देखें, तो यह स्थिति कुछ हास्यास्पद लगती है
contract के fine print को हमेशा बहुत ध्यान से पढ़कर ही sign करना चाहिए। यह सामान्य consumer contracts पर भी लागू होता है, लेकिन business contracts में तो यह अनिवार्य है
छोटे business contracts भी इसका अपवाद नहीं हैं। जिस non-profit में मैं board member हूँ, वहाँ staff office copier lease के लिए options देख रहा था और contract लेकर आया। उन्होंने कहा कि सब review हो चुका है, बस sign कर दीजिए, लेकिन clauses सच में चौंकाने वाले थे। उदाहरण के लिए, अगर हम किसी भी कारण से cancel करें — यहाँ तक कि तब भी जब दूसरी party contract पूरा न करे — तो हमें बाकी पूरी contract राशि तुरंत चुकानी होगी। lease structure ऐसा था कि machine की पूरी कीमत monthly payments में वसूल ली जाती थी, लेकिन ownership vendor के पास ही रहती थी। यानी cancel करने पर भी machine vendor की और पैसा पूरा हमारा। legal dispute होने पर भी lawyer fees पूरी हमारी। मैंने साफ कह दिया कि मैं यह कभी मंज़ूर नहीं करूँगा, और staff लगभग एक साल तक मुझसे नाराज़ रहा क्योंकि दूसरी जगहों पर लोग ऐसे contracts sign कर देते हैं
यह सलाह दी जाती है कि fine print तक ध्यान से पढ़ो, लेकिन सच कहें तो इस लेख को देखकर लगता है कि कई बार उससे भी कोई फ़ायदा नहीं होता। contract terms "एकतरफ़ा" बदल दिए जाते हैं और संबंधित पक्ष को बताया भी नहीं जाता। IT industry में यह लगभग रोज़मर्रा की बात है। आपने signed contract का fine print कितना भी देख लिया हो, वह बाद में बदल चुका होता है, इसलिए सब बेकार हो जाता है। आजकल अगर terms change होने पर email notification मिल जाए तो खुद को lucky समझिए। रवैया यही रहता है कि अगर आप सहमत नहीं हैं तो कर क्या लेंगे। अगर कोई lawyer न हो तो लोग कहेंगे कि यह illegal है, लेकिन courts ने इसे ठीक से रोका नहीं, इसलिए यह चलता रहता है
contract की व्याख्या, review में लगने वाला समय और मेहनत, और गलत समझने का जोखिम — इन सबको भी लागत का हिस्सा मानना चाहिए। इस तरह देखें तो कई contracts ऐसे होते हैं जिन्हें करना ही बेहतर नहीं होता
मैं जानना चाहूँगा कि "unilateral modification clause" व्यवहार में कैसे काम करती है। अगर fine print पसंद न आए तो क्या आपको तुरंत 6 महीने पहले notice देकर terminate करना पड़ता है?
मैं ID.me का signup contract पढ़कर चौंक गया था। उसमें "स्वेच्छा से" citizenship rights छोड़ने जैसी बात थी। इसलिए मैं इसका इस्तेमाल नहीं करना चाहता। लेकिन IRS.gov में login करने का और कोई तरीका नहीं है। YouTube देखने के लिए Google account चाहिए। parents group chat में रहने के लिए WhatsApp के Meta terms मानने पड़ते हैं। ऐसे मामले खत्म ही नहीं होते
मैं legal expert नहीं हूँ, लेकिन मुझे लगता है कि emails पढ़ना और उसी के आधार पर कार्रवाई करना जिस उद्देश्य से किया गया, वह खुद स्पष्ट रूप से illegal था, इसलिए contract भी अमान्य होना चाहिए
खासकर अगर यह कोई government agency थी, तो यह सच में चौंकाने वाली बात है। अगर कोई outsourcing vendor email server में चुपके से backdoor डाल दे और emails की जासूसी करे, तो वहाँ corruption से लेकर foreign intelligence activity तक कुछ भी हो सकता है। अगर यह America में होता, तो FBI या CIA ऐसे vendor मामले को पूरी तरह साफ कर देती
सही है। समस्या यह है कि अगर आप termination करते हैं, तो आपको court में एक बेहद hostile पक्ष का सामना करना पड़ेगा, और वे पूरी कोशिश करेंगे कि आपसे और पैसा वसूला जाए। कुछ organizations ethics से ज़्यादा safety को महत्व देती हैं, इसलिए वे अतिरिक्त लागत सह लेती हैं। दूसरी तरफ़, कुछ companies unfair patent lawsuits या unreasonable contract clauses को खत्म कराने के लिए लड़ती भी हैं। यह संगठन स्पष्ट रूप से उस तरह का नहीं था
यह legal advice नहीं है, लेकिन मुझे लगता है कि ऐसी चीज़ों में लोगों को चेतावनी देने के लिए असली नाम सार्वजनिक करना ज़रूरी है
मुझे लगता है HN पर बहुत से लोगों ने ऐसा कुछ झेला होगा। एक बार हम चुपचाप system shutdown की तैयारी कर रहे थे, और हमारी company तथा partner company के बीच codebase shared था। हमारे एक developer ने commit में "Reversing Migration Script" जैसा कुछ लिख दिया, और एक घंटे से भी कम समय में दोनों कंपनियों के CEOs के बीच बड़ा टकराव शुरू हो गया। बाद में पता चला कि दूसरी company इस तरह के शब्दों को code में real time में monitor कर रही थी, और जैसे ही उन्हें shutdown की आहट मिली, उन्होंने तुरंत action लिया। जबकि contract के तहत term ख़त्म होने से पहले termination पूरी तरह legal था, इसलिए अपने-आप में इसमें कुछ असामान्य नहीं था। इस monitoring का पता हमें बाद में चला, और company के अंदर यह witch hunt भी शुरू हो गई कि "जासूस कौन है"। यह सच में बहुत कठिन अनुभव था। अब लगता है कि इस तरह का psychopath-level व्यवहार सामान्य हो गया है। शायद मैं ही पुराने ज़माने का सीधा-सादा इंसान हूँ, इसलिए यह भी समझ आता है कि इतनी कंपनियाँ सिर्फ 20s उम्र के लोगों को ही क्यों रखना चाहती हैं /आधा मज़ाक
अगर आप साझा कर सकें कि वे monitoring तकनीकी रूप से कैसे कर रहे थे, तो अच्छा होगा। ऐसे मामलों से सीखना उपयोगी है
जहाँ monitoring होने की संभावना हो, वहाँ जानबूझकर बहुत आसानी से trigger होने वाले variable names डालने चाहिए। पुरानी NSA वाली jokes की तरह
इसे "सच्ची घटना पर आधारित horror story" कहा गया है, लेकिन जिज्ञासा है कि क्या यह वास्तव में सच है। अगर details भी सच हों, तो यह और दिलचस्प होगा