तकनीकी कर्ज़: मेरी Rust लाइब्रेरी अब CDO बन गई है

तकनीकी कर्ज़: मेरी Rust लाइब्रेरी अब CDO बन गई है

• तकनीकी कर्ज़ पर एक मज़ाक यह है कि अगर तकनीकी कर्ज़ है, तो उस कर्ज़ को संभालने के लिए डेरिवेटिव्स भी होने चाहिए।
• Rust ecosystem ने ऐसा समाधान पैदा किया है जो तकनीकी कर्ज़ को प्रतिभूतिकृत करने जैसा दिखता है।
• उदाहरण के लिए, कोई लाइब्रेरी stuff दूसरी लाइब्रेरी learned-rust-this-way पर निर्भर है, लेकिन learned-rust-this-way के लेखक की रुचि खत्म हो जाती है और समस्याएँ जमा होने लगती हैं।

तकनीकी कर्ज़ की असलियत

• learned-rust-this-way को तकनीकी कर्ज़ माना जाता है, यानी यह सीधे समस्याएँ पैदा नहीं करता, फिर भी यह कर्ज़ है।
• किसी बिंदु पर किसी को पता चलता है कि learned-rust-this-way कर्ज़ है, और मूल लेखक से संपर्क न हो पाने पर इसे RUSTSEC database में जोड़ दिया जाता है।
• RUSTSEC, एक rating agency की तरह, उस कर्ज़ को कबाड़ घोषित कर देता है, और इसके कारण बहुत से लोगों का CI (continuous integration) फेल होने लगता है।

कर्ज़ से निपटने के तरीके

• stuff के maintainer के रूप में, जब उपयोगकर्ता learned-rust-this-way के इस्तेमाल पर समस्या उठाते हैं तो तनाव बढ़ता है और कर्ज़ से निपटने के लिए कदम उठाने का दबाव आता है।
• किसी विकल्प पर जाना एक रास्ता है, लेकिन इस मामले में सभी विकल्प आकर्षक नहीं हैं।
• learned-rust-this-way को fork करने पर भी वही मांगें सामने आती हैं, इसलिए यह सिर्फ़ अस्थायी समाधान है, समस्या का वास्तविक हल नहीं।

जो समाधान वास्तव में काम करता है

• अगर आप उस कोड को अपनी लाइब्रेरी में merge कर देते हैं, तो वही कबाड़ तकनीकी कर्ज़ अचानक ‘AAA’ रेटिंग पा लेता है।
• कोड को आगे छेड़े बिना, merge की बात छिपाकर, और पहले की तरह लाइब्रेरी maintain करते हुए दुनिया चलती रहती है।
• yaml-rust को insta में vendor करके merge करने से, यह insta कोड और yaml-rust का संयुक्त रूप बन गया, और इस तरह तकनीकी कर्ज़ को AAA रेटिंग में अपग्रेड कर दिया गया।

GN⁺ की राय

• यह लेख तकनीकी कर्ज़ की तुलना वित्तीय डेरिवेटिव्स से करके, software development में आने वाली समस्याओं को चतुराई से समझाता है।
• तकनीकी कर्ज़ software development में अक्सर सामने आने वाली समस्या है, और यह लेख डेवलपर्स को इसे प्रबंधित करने के रचनात्मक तरीके सुझाता है।
• Rust ecosystem में RUSTSEC जैसी rating systems डेवलपर्स को लाइब्रेरी की स्थिरता का आकलन करने में मदद कर सकती हैं, लेकिन साथ ही अनावश्यक तनाव भी पैदा कर सकती हैं।
• कोड को merge करके तकनीकी कर्ज़ हल करना एक अस्थायी उपाय हो सकता है; लंबे समय में अधिक टिकाऊ maintenance strategy की ज़रूरत होती है।
• ऐसी स्थिति में community-led maintenance, open source projects की shared maintenance, या लाइब्रेरी के alternative versions खोजने जैसे अलग-अलग समाधानों पर विचार किया जाना चाहिए।

[GN⁺]

Hacker News की राय

• सबसे लोकप्रिय YAML parser के लेखक ने अचानक प्रोजेक्ट छोड़ दिया और उसे deprecated तथा unmaintained के रूप में चिह्नित कर दिया। यह बिना किसी चेतावनी या किसी दूसरे maintainer को नामित किए किया गया, और पैकेज अभी भी काम कर रहा है, लेकिन 4000 से अधिक दूसरे crates में इस्तेमाल होता है, इसलिए audit और auto-update tools unmaintained crate के उपयोग पर चेतावनी देंगे।
• CDO संक्षेप को लेकर उलझन में पड़े लोगों के लिए, अनुमान है कि इसका मतलब 'collateralized debt obligation' है। क्योंकि 'collateralized' शब्द कई बार इस्तेमाल किया गया था।
• अगर कोड का कोई vulnerable path किसी external library से execute या access नहीं किया जा सकता, तो वह एक सुरक्षित code path बन जाता है। Libraries को vendor करना कोड पर attack करने के tools उपलब्ध कराता है, और अगर आपकी अपनी library के लिए test coverage पर्याप्त है, तो आप vendored library पर code coverage tools चला सकते हैं। Vendored library को modify करना चुनौतीपूर्ण हो सकता है, लेकिन जिन हिस्सों की ज़रूरत नहीं है उन्हें हटाना अपेक्षाकृत आसान हो सकता है। बेशक, यह vendored library की संरचना पर निर्भर करता है।
• एक पूर्व quant analyst और वर्तमान economist ने लेखक की इस बात के लिए सराहना की कि उसने 'Collateralized Debt Obligation' शब्द का सही उपयोग किया। वह 'technical debt' पर एक लेख लिखना चाहते हैं, क्योंकि उनके अनुसार 'debt' का रूपक इस अवधारणा पर ठीक से फिट नहीं बैठता। 'high-viscosity code' शायद बेहतर अभिव्यक्ति हो सकती है। कोड को नई सुविधाओं के अनुसार आसानी से बदला नहीं जा सकता, इसलिए वह ऐसे महसूस होता है मानो उसमें उच्च inductance हो।
• 'junk tech debt' के अचानक 'AAA' rating पा लेने पर, लेखक का मतलब शायद यह है कि vendor किए जाने से पहले और बाद में वही कोड बेहतर debt rating नहीं पा सकता। लेकिन यह सिर्फ कोड के अपने मूल्य को देखता है और पूरे value proposition के सबसे महत्वपूर्ण हिस्से को नज़रअंदाज़ करता है। कोड को vendor करने वाला maintainer अब उस कोड का मालिक होता है, और किसी dead project से कोड को vendor करने वाला active maintainer उस कोड का मूल्य बढ़ा देता है, क्योंकि अब एक इंसान मौजूद है जो issues का जवाब दे सकता है, pull requests की समीक्षा कर सकता है और bugs ठीक कर सकता है।
• JS npm ecosystem में भी यही पैटर्न देखा गया है। Npm audit मुख्यतः security issues के बारे में बढ़ा-चढ़ाकर चेतावनी देता है, और जब तक license अनुमति देता है, users से मिलने वाली बेहूदा समस्याओं से बच निकलने के सबसे भरोसेमंद तरीकों में से एक यही है।
• yaml-rust को fork करके pure Rust में फिर से लिखकर yaml-rust2 बनाना सौभाग्यशाली रहा। यह fork YAML test suite को पूरी तरह pass करता है और benchmarks में बेहतर performance भी दिखाता है। Migration भी आसान लगती है। आखिरकार, समस्या फिर भी बनी रहती है: हम अभी भी ऐसे दूसरे लोगों पर निर्भर हैं जो फिलहाल मुफ्त में श्रम दे रहे हैं, लेकिन इस बात की कोई गारंटी नहीं कि वे हमेशा ऐसा करते रहेंगे।
• अगर source-based package manager registry द्वारा प्रकाशित packages के maintenance को ज़बरदस्ती अपने हाथ में लेने का कानूनी अधिकार लागू नहीं कर सकता, तो उसे भयानक समस्याओं का सामना करना पड़ेगा: neglect, malicious changes, malicious removal, impersonation आदि। जिन packages को community के लिए पर्याप्त महत्वपूर्ण माना जाता है, उनके लिए registry entry को मूल मालिक के हाथ से लेकर उसे fork में बदलने का कोई तरीका होना चाहिए।
• अगर कोड काम करता है और सालों से करता आया है, तो unmaintained होने से क्या फ़र्क पड़ता है? अगर उसे ठीक करने की ज़रूरत नहीं है और आप उसकी सीमाएँ व क्षमताएँ जानते हैं, तो यह समस्या नहीं है। कोड अपने आप खराब नहीं होता। दशकों पुराने कोड को vendor करने या integrate करने में पहले भी कई बार कोई समस्या नहीं हुई।
• Dependencies को vendor करना ही समाधान है। पिछले 20 वर्षों से लगभग हर उस dependency के लिए यह किया गया है जो 'completed' हो चुकी है और जिसका development व maintenance धीमा पड़ गया है।