लोक क्षेत्र सॉफ़्टवेयर अभियांत्रिकी और प्लेटफ़ॉर्म

लोक मूल्य में इसका महत्व क्यों है

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

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

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

मूल अवधारणाएँ

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

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

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

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

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

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

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

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

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

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

श्रेष्ठ व्यवहार

1. अविभेदित आवश्यकताओं के लिए डिफ़ॉल्ट रूप से ख़रीदें, और निर्माण को उसके लिए आरक्षित रखें जो वास्तव में विशिष्ट है। वेतन-प्रबंधन, ईमेल, और सामान्य केस-प्रबंधन आवश्यकताएँ शायद ही किसी अन्य संगठन की तुलना में इतनी भिन्न हों कि विशेष सॉफ़्टवेयर उचित ठहरे; तभी बनाएँ जब आवश्यकता, पैमाना, या क्षमता को दशकों तक स्वामित्व में रखने और विकसित करने की आवश्यकता बाज़ार जो प्रस्तुत करता है उससे वास्तव में भिन्न हो।
2. यह तय करने से पहले कि कितना तकनीकी ऋण वहन करना है, उसे दृश्यमान बनाएँ। सेवा में प्रत्येक प्रणाली के लिए ज्ञात शॉर्टकट, स्थगित सुधार, और असमर्थित निर्भरताओं का एक रजिस्टर बनाए रखें, जिसकी एक निश्चित चक्र पर समीक्षा हो, ताकि एक और वर्ष ऋण वहन करना एक जानबूझकर लिया गया व्यापार-बंद हो, न कि किसी के भी न देखने का परिणाम।
3. किसी महत्वपूर्ण विरासत प्रणाली से हटने के एकमात्र मार्ग के रूप में कभी भी एकल, अपरिवर्तनीय कटओवर की योजना न बनाएँ। स्ट्रैंग्लर फिग पैटर्न जैसे वृद्धिशील दृष्टिकोणों को प्राथमिकता दें जो हर टुकड़े को परखने, पलटने, और धीरे-धीरे शुरू करने देते हैं; लाखों लोग जिस प्रणाली पर निर्भर हैं उसका बिग-बैंग प्रतिस्थापन वर्षों के जोखिम को एक ही सप्ताहांत में केंद्रित कर देता है, बिना किसी वापसी के रास्ते के यदि कुछ विफल हो।
4. अपने संगठन द्वारा लिखवाए गए स्रोत कोड को उसके द्वारा किराए पर ली गई सेवा नहीं, बल्कि उसके स्वामित्व वाली संपत्ति मानें। अनुबंध के बिंदु पर स्रोत-कोड एस्क्रो या पूर्ण स्वामित्व पर बातचीत करें, किसी विवाद के शुरू होने के बाद नहीं, क्योंकि किसी आपूर्तिकर्ता का आपकी महत्वपूर्ण सेवा के कोड की एकमात्र प्रति रखना डिज़ाइन के रूप में विक्रेता लॉक-इन है।
5. स्रोत कोड को डिफ़ॉल्ट रूप से खुला प्रकाशित करें, और उसे रोकने के लिए एक विशिष्ट औचित्य की माँग करें। निरंतरता से लागू की गई डिफ़ॉल्ट-रूप-से-खुला-स्रोत नीति हर विभाग के विशेष रूप से बनाए गए सॉफ़्टवेयर को एक बार की लागत के बजाय एक साझा अंतर-सरकारी संपत्ति में बदल देती है, और बाहरी विशेषज्ञों को ऐसे सुरक्षा दोष खोजने देती है जिन्हें अकेली आंतरिक टीम चूक जाती।
6. ऐसे सॉफ़्टवेयर अनुबंध लिखें जो पुनरावृत्तीय डिलीवरी को क़ानूनी बनाएँ, न कि केवल तकनीकी रूप से संभव। एक अनुबंध जो केवल हस्ताक्षर के समय सहमत स्थिर विनिर्देश के विरुद्ध भुगतान करता है, किसी टीम को ईमानदार एजाइल अभ्यास और संविदागत अनुपालन के बीच चुनने पर मजबूर करता है; अंत में एक मील के पत्थर के बजाय प्रदर्शित चलते सॉफ़्टवेयर से जुड़े चरणबद्ध वित्तपोषण द्वार का उपयोग करें।
7. आधुनिकीकरण को एक बार की पूँजीगत परियोजना के बजाय एक चल रहे कार्यक्रम के रूप में वित्तपोषित करें। एक बार आधुनिकीकृत और फिर बीस वर्षों के लिए छोड़ी गई विरासत प्रणाली वही जोखिम फिर जमा कर लेती है जिससे उसने शुरुआत की थी; एक सड़क प्राधिकरण जिस तरह पुनः-सतहीकरण के लिए बजट बनाता है उसी तरह निरंतर, वृद्धिशील नवीनीकरण के लिए बजट बनाएँ, न कि एक पीढ़ी में एक बार भव्य प्रतिस्थापन के लिए।
8. वाणिज्यिक सॉफ़्टवेयर ख़रीदते समय भी खुले मानकों और पोर्टेबल डेटा प्रारूपों को चुनें। किसी आपूर्तिकर्ता की प्रणाली को खुले, दस्तावेज़ीकृत प्रारूपों में डेटा संग्रहीत और निर्यात करने की माँग करना स्विचिंग लागत को कम रखता है भले ही सॉफ़्टवेयर स्वयं स्वामित्व वाला हो, और यह लॉक-इन के विरुद्ध हर प्रणाली को खुला-स्रोत बनाने पर ज़ोर देने की तुलना में अक्सर एक अधिक प्राप्त-करने-योग्य निकट-अवधि सुरक्षा उपाय है।
9. पूर्ण दायरे के प्रति प्रतिबद्ध होने से पहले एक न्यूनतम व्यवहार्य उत्पाद बनाएँ और उसे वास्तविक उपयोगकर्ताओं को दिखाएँ। एक वास्तव में न्यूनतम संस्करण जारी करना, फिर जो सीखा गया उस पर पुनरावृत्ति करना, ग़लत धारणाओं को तब पकड़ता है जब वे अभी भी सस्ते में ठीक की जा सकती हैं, न कि पूर्ण-पैमाने की प्रणाली उनके विरुद्ध बन जाने के बाद।
10. आंतरिक अभियांत्रिकी क्षमता को एक बुद्धिमान ख़रीदार बने रहने के लिए पर्याप्त बनाए रखें, भले ही डिलीवरी अनुबंधित हो। किसी लोक निकाय ने जिसने अपनी तकनीकी विशेषज्ञता खोखली कर ली है वह किसी आपूर्तिकर्ता के प्रस्ताव का आकलन नहीं कर सकता, किसी संकटग्रस्त परियोजना के प्रारंभिक चेतावनी संकेत नहीं पकड़ सकता, या लॉक-इन से बाहर निकलने की बातचीत नहीं कर सकता, उसके ख़रीद नियम कागज़ पर जो भी कहें।
11. किसी विरासत प्रणाली के जोखिम प्रोफ़ाइल को उसके उपयोगकर्ता इंटरफ़ेस से पहले सेवानिवृत्त करें। असमर्थित भाषाओं, बिना-पैच अवसंरचना, और अदस्तावेज़ीकृत एकीकरणों को बदलने को प्राथमिकता दें — वे विफलताएँ जो आउटेज और उल्लंघन का कारण बनती हैं — दृश्य आधुनिकीकरण से पहले जो कहीं कम परिचालन जोखिम वहन करता है।
12. डिलीवरी स्वास्थ्य को केवल बजट और अनुसूची विचलन से नहीं, बल्कि अभियांत्रिकी संकेतकों से मापें। तैनाती आवृत्ति, दोष दरें, और सबसे पुराने असंबोधित तकनीकी-ऋण मद की आयु किसी शासन बोर्ड को यह बताती हैं कि क्या कोई कार्यक्रम सफल होगा, कहीं अधिक बताती हैं बनिस्बत इसके कि यह वर्तमान में बजट पर है या नहीं, जो अक्सर बदलने वाला अंतिम संकेतक होता है।

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

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

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

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

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

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

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

व्यवहार में: एक लोक मूल्य उदाहरण

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

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

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

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

चार क्षेत्रीय दृष्टिकोण

स्थानीय सरकार

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

राष्ट्रीय सरकार

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

सामाजिक क्षेत्र और गैर-लाभकारी संगठन

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

बहुपक्षीय और अंतर्राष्ट्रीय

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

सामान्य विफलता पैटर्न

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

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

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

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

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

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

जाँच-सूची

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

मुख्य स्रोत

• GOV.UK सर्विस स्टैंडर्ड, गवर्नमेंट डिजिटल सर्विस, यूनाइटेड किंगडम — लोक सेवाओं के लिए पुनरावृत्तीय, उपयोगकर्ता-केंद्रित डिलीवरी और खुले मानकों की माँग करने वाला एक राष्ट्रीय डिजिटल-सेवा मानक।
• Office of Management and Budget, Federal Source Code Policy (M-16-21), संयुक्त राज्य अमेरिका — विशेष रूप से विकसित सरकारी सॉफ़्टवेयर के लिए पुनः उपयोग और खुला-स्रोत रिलीज़ पर विचार करने की माँग करने वाली संघीय नीति।
• Free Software Foundation Europe, Public Money, Public Code अभियान — एक यूरोपीय दर्शक वर्ग के लिए विकसित, सार्वजनिक रूप से वित्तपोषित सॉफ़्टवेयर स्रोत कोड को मुक्त और खुला-स्रोत लाइसेंस के तहत जारी करने का तर्क।
• वार्ड कनिंघम, 'The WyCash Portfolio Management System' (OOPSLA 1992 अनुभव रिपोर्ट) — तकनीकी-ऋण रूपक का मूल विवरण।
• Digital Public Goods Alliance — लोक विकास उद्देश्यों की सेवा के लिए डिज़ाइन किए गए खुले सॉफ़्टवेयर, डेटा, और सामग्री के लिए मानक और एक रजिस्ट्री बनाए रखने वाली एक बहु-हितधारक पहल।

संदर्भ

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. 'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/