วิศวกรรมซอฟต์แวร์และแพลตฟอร์มของภาครัฐ

ทำไมสิ่งนี้จึงสำคัญต่อคุณค่าสาธารณะ

เกือบทุกบริการสาธารณะที่พลเมืองสัมผัสวันนี้ การจดทะเบียนการเกิด การเรียกร้องสิทธิประโยชน์ การชำระใบเรียกเก็บภาษี การจองวันขึ้นศาล ทำงานบนซอฟต์แวร์ที่ใดที่หนึ่งหลังเคาน์เตอร์หรือหน้าจอ ซอฟต์แวร์นั้นแทบไม่ใช่การซื้อครั้งเดียว มันกลายเป็นส่วนหนึ่งของโครงสร้างพื้นฐานถาวรของรัฐ มักอยู่นานกว่าฝ่ายบริหารที่มอบหมาย ผู้จัดหาที่สร้าง และภาษาโปรแกรมที่วิศวกรของมันได้รับการฝึก หน่วยงานสาธารณะไม่ประสบซอฟต์แวร์อย่างที่ประสบอาคารหรือถนน ที่สภาพของสินทรัพย์มองเห็นได้ ซอฟต์แวร์เสื่อมอย่างมองไม่เห็น และใบเรียกเก็บของการเสื่อมมาถึงหลายปีต่อมาเป็นเหตุฉุกเฉิน

ความตึงเครียดที่ขับเคลื่อนหัวข้อนี้เป็นเชิงโครงสร้าง ซอฟต์แวร์เป็นการวนซ้ำโดยธรรมชาติ ข้อกำหนดชัดขึ้นเมื่อผู้ใช้โต้ตอบกับระบบที่ทำงาน และแนวปฏิบัติวิศวกรรมที่ดีที่สุดคือสร้างบางสิ่งเล็ก เรียนรู้ และปรับ วงจรการจัดซื้อจัดจ้างและความรับผิดชอบสาธารณะ (ดู หัวข้อ 3.7 — การจัดซื้อจัดจ้างภาครัฐและการมอบหมายบริการ) ตรงกันข้าม ถูกสร้างสำหรับงานทุนและสัญญากลาโหม ข้อกำหนดคงที่ การให้รางวัลใหญ่ครั้งเดียว การจ่ายตามหลักชัย และกรณีธุรกิจที่ลงนามหลายปีก่อนการส่งมอบเริ่ม เมื่อสภานิติบัญญัติหรือผู้ตรวจสอบคาดหวังสัญญาราคาคงที่ขอบเขตคงที่และทีมวิศวกรรมต้องเปลี่ยนทิศทางหลังการปล่อยครั้งแรก ความไม่ตรงกันปรากฏเป็นขอบเขตที่คืบ งบประมาณเกิน หรือระบบที่ระบุถูกต้องในปี 2019 และล้าสมัยเมื่อส่งมอบ

แพลตฟอร์มที่แนวปฏิบัติวิศวกรรมของหัวข้อนี้มีไว้สร้าง ระบบอัตลักษณ์ร่วม ทางด่วนการชำระเงิน เครื่องมือจัดการกรณีที่ใช้ซ้ำข้ามกรม เป็นเรื่องของ หัวข้อ 5.1 (ดู หัวข้อ 5.1 — รัฐบาลดิจิทัลและการเปลี่ยนผ่านสู่ดิจิทัล) หัวข้อนี้เกี่ยวกับวินัยของการสร้างและซื้อซอฟต์แวร์ที่ทำให้แพลตฟอร์มดังกล่าวหรือบริการเดี่ยวใดเชื่อถือได้ แทนที่ได้ และเป็นของหน่วยงานสาธารณะที่พึ่งพามัน ไม่ใช่ของผู้จัดหารายใดก็ตามที่บังเอิญเขียนก่อน

แนวคิดหลัก

การตัดสินใจสร้างเทียบกับซื้อ (build-versus-buy decision) คือการเลือกระหว่างการมอบหมายซอฟต์แวร์เฉพาะที่เขียนสำหรับความต้องการขององค์กรเดียวกับการรับซอฟต์แวร์สินค้าโภคภัณฑ์ที่กำหนดค่าได้ซึ่งสร้างไว้แล้วสำหรับตลาดของผู้ซื้อที่คล้ายกัน การซื้อมักถูกกว่าและเสี่ยงน้อยกว่าสำหรับความต้องการที่ไม่โดดเด่นจริง บัญชีเงินเดือน อีเมล การจัดการกรณีมาตรฐาน ขณะที่การสร้างชอบธรรมเฉพาะเมื่อข้อกำหนดต่างพอที่ไม่มีผลิตภัณฑ์ที่กำหนดค่าได้เหมาะ หรือเมื่อขีดความสามารถเองเป็นสินทรัพย์เชิงยุทธศาสตร์ที่องค์กรต้องเป็นเจ้าของและพัฒนา

หนี้ทางเทคนิค (technical debt) เป็นอุปมา ตั้งโดยวิศวกรซอฟต์แวร์ วาร์ด คันนิงแฮม (Ward Cunningham) ในปี 1992 สำหรับต้นทุนสะสมของการเลือกวิธีที่สะดวกในการส่งมอบซอฟต์แวร์ตอนนี้แทนที่วิธีที่ละเอียดกว่าซึ่งจะใช้เวลานานกว่า หนี้ทางเทคนิค เหมือนหนี้ทางการเงิน ไม่ผิดโดยธรรมชาติที่จะรับ ประเด็นของคันนิงแฮมเองคือการส่งมอบโค้ดที่ทำงานได้เร็วและปรับโครงสร้างภายหลังอาจเป็นการตัดสินที่ถูก แต่หนี้ที่ไม่เคยชำระสะสมดอกเบี้ยเป็นการส่งมอบที่ช้าลง ข้อบกพร่องมากขึ้น และความเสี่ยงที่เพิ่มขึ้น และหน่วยงานสาธารณะที่มองหนี้ของตนไม่เห็นตัดสินใจไม่ได้ว่าจะชำระหรือปล่อยให้ทบต้น

ระบบเดิม (legacy system) คือเทคโนโลยี แอปพลิเคชัน หรือแพลตฟอร์มเก่าที่ยังใช้งานอยู่แม้ล้าสมัย มักเพราะการแทนที่แพงหรือเพราะไม่มีใครเหลืออยู่ในองค์กรที่เข้าใจเต็มที่ว่ามันทำอะไร ระบบเดิมคงทนเป็นพิเศษในภาครัฐ ระบบภาษี สิทธิประโยชน์ และประกันสังคมหลักที่เขียนเมื่อหลายทศวรรษก่อนในภาษา เช่น COBOL ภาษาธุรกิจร่วม (Common Business-Oriented Language) ออกแบบในปี 1960 สำหรับการคำนวณด้านการบริหาร ยังประมวลผลธุรกรรมให้พลเมืองหลายล้านคน เพราะระบบทำงานและความรู้เชิงสถาบันที่ต้องการเพื่อปลดมันอย่างปลอดภัยมักเกษียณไปก่อน

การทำซอฟต์แวร์ให้ทันสมัย (software modernization) เป็นคำทั่วไปสำหรับการแปลง เขียนใหม่ หรือย้ายระบบเดิมสู่สถาปัตยกรรม ภาษา หรือแพลตฟอร์มปัจจุบัน การทำซอฟต์แวร์ให้ทันสมัยครอบคลุมสเปกตรัมตั้งแต่การเขียนใหม่ทั้งหมดไปจนถึงตัวเลือกอนุรักษ์นิยมกว่า เช่น การโฮสต์โค้ดเดิมใหม่บนโครงสร้างพื้นฐานสมัยใหม่ และการเลือกระหว่างพวกมันเป็นการตัดสินใจจัดการความเสี่ยงเท่ากับทางเทคนิค

รูปแบบต้นไทรรัด (strangler fig pattern) เป็นแนวทางการทำให้ทันสมัยแบบค่อยเป็นค่อยไป ตั้งชื่อตามเถาวัลย์ที่เติบโตรอบต้นไม้เจ้าบ้านและค่อย ๆ แทนที่มัน ที่ฟังก์ชันใหม่ถูกสร้างควบคู่กับระบบเดิมและทราฟฟิกถูกเปลี่ยนเส้นทางไปที่มันทีละส่วน แทนการแทนที่ทั้งระบบในการเปลี่ยนผ่านครั้งเดียว รูปแบบต้นไทรรัดสำคัญเพราะมันให้ทดสอบ กลับคืน หรือหยุดแต่ละส่วนเพิ่มได้โดยไม่ต้องทำให้ทั้งบริการหยุด ตรงข้ามกับการแทนที่แบบบิ๊กแบงที่ระบบเก่าถูกปิดและระบบใหม่เปิดในช่วงขณะเดียว โดยไม่มีทางกลับหากมีบางอย่างผิด

การผูกติดกับผู้ขาย (vendor lock-in) เกิดขึ้นเมื่อลูกค้าพึ่งพาเทคโนโลยี รูปแบบข้อมูล หรือข้อกำหนดตามสัญญาที่เป็นกรรมสิทธิ์ของผู้จัดหารายเดียวมากจนการเปลี่ยนไปผู้จัดหารายอื่นมีต้นทุนหรือความเสี่ยงสูงเกินรับ การผูกติดกับผู้ขายเป็นอันตรายเฉพาะในซอฟต์แวร์ภาครัฐ เพราะผู้ซื้อเป็นลูกค้าประจำที่มีความสามารถเชิงปฏิบัติจำกัดที่จะเดินจากระบบที่ดำเนินบริการสำคัญ ซึ่งทำให้ตำแหน่งการเจรจาของมันอ่อนลงในทุกการต่ออายุถัดไป

ซอฟต์แวร์เสรีและโอเพนซอร์ส (free and open-source software) คือซอฟต์แวร์ที่แจกจ่ายภายใต้ใบอนุญาตที่ให้ผู้ใช้เสรีภาพที่จะใช้ ศึกษา แก้ไข และแจกจ่ายซ้ำซอร์สโค้ด ซอฟต์แวร์เสรีและโอเพนซอร์สรองรับนโยบายโอเพนซอร์สโดยค่าเริ่มต้น ภายใต้นั้นหน่วยงานสาธารณะตั้งค่าเริ่มต้นที่จะเผยแพร่ซอร์สโค้ดที่ตนมอบหมายเว้นแต่เหตุผลเฉพาะ ความอ่อนไหวด้านความปลอดภัย สิทธิของบุคคลที่สาม ชอบธรรมการกักไว้ เหตุผลมักสรุปเป็น "เงินสาธารณะ โค้ดสาธารณะ" ซอฟต์แวร์ที่จ่ายครั้งเดียวด้วยเงินสาธารณะไม่ควรต้องจ่ายอีก ในเขตอำนาจอื่น โดยหน่วยงานสาธารณะอื่น ที่แก้ปัญหาเดียวกัน

สินค้าสาธารณะดิจิทัล (digital public good) คือซอฟต์แวร์ ข้อมูล หรือเนื้อหาเปิดที่ปล่อยภายใต้ใบอนุญาตเปิด ออกแบบเพื่อช่วยบรรลุวัตถุประสงค์การพัฒนาหรือธรรมาภิบาลสาธารณะแทนผลตอบแทนเชิงพาณิชย์ สินค้าสาธารณะดิจิทัลวางกรอบใหม่การปล่อยโอเพนซอร์สของรัฐบาลหนึ่งเป็นส่วนหนึ่งของโครงสร้างพื้นฐานร่วมที่กว้างกว่าที่รัฐบาลอื่นและองค์กรประชาสังคมดึงใช้ได้โดยตรง ไม่ใช่เพียงท่าทีความโปร่งใสภายใน

การพัฒนาซอฟต์แวร์แบบคล่องตัว (agile software development) เป็นคำร่มสำหรับแนวทางวนซ้ำในการสร้างซอฟต์แวร์ที่ชอบซอฟต์แวร์ที่ทำงาน การส่งมอบบ่อย และการตอบสนองต่อการเปลี่ยนแปลงเหนือการทำตามแผนคงที่ที่ตกลงล่วงหน้า การพัฒนาซอฟต์แวร์แบบคล่องตัวตรงข้ามกับแบบจำลองน้ำตก แนวทางเชิงลำดับที่ข้อกำหนด การออกแบบ การสร้าง และการทดสอบแต่ละอย่างเสร็จสมบูรณ์ก่อนอย่างถัดไปเริ่ม ความน่าดึงดูดของน้ำตกต่อหน่วยงานสาธารณะคือหลักชัยของมันแมปเรียบร้อยกับสัญญาราคาคงที่และรอบงบประมาณรายปี ซึ่งเป็นเหตุผลที่กฎหมายจัดซื้อจัดจ้างจำนวนมากยังสมมติมัน แม้การส่งมอบคล่องตัวจริง

ผลิตภัณฑ์ที่ใช้ได้ขั้นต่ำ (minimum viable product) คือบริการรุ่นที่เล็กที่สุดที่ปล่อยให้ผู้ใช้จริงเพื่อทดสอบว่าทำงานหรือไม่และเรียนรู้ว่าจะสร้างอะไรต่อ แนวคิดผลิตภัณฑ์ที่ใช้ได้ขั้นต่ำ ปรับเข้าสู่คู่มือบริการดิจิทัลภาครัฐ ให้ทีมวนซ้ำมีวิธีที่ปกป้องได้ในการแสดงสิ่งที่เป็นจริงและทำงานได้แก่ผู้ให้ทุนหรือผู้ตรวจสอบนานก่อนขอบเขตเต็มเสร็จ ตราบเท่าที่กระบวนการความรับผิดชอบยอมรับการปล่อยขั้นต่ำจริงแทนที่จะถือเป็นผลิตภัณฑ์สำเร็จรูปภายใต้ชื่ออื่น

แนวปฏิบัติที่ดี

1. ตั้งค่าเริ่มต้นที่การซื้อสำหรับความต้องการที่ไม่โดดเด่น และสงวนการสร้างสำหรับสิ่งที่โดดเด่นจริง บัญชีเงินเดือน อีเมล และความต้องการการจัดการกรณีทั่วไปแทบไม่ต่างจากองค์กรอื่นพอที่จะชอบธรรมซอฟต์แวร์เฉพาะ สร้างเฉพาะเมื่อข้อกำหนด ขนาด หรือความจำเป็นที่จะเป็นเจ้าของและพัฒนาขีดความสามารถตลอดหลายทศวรรษต่างจากที่ตลาดเสนอจริง
2. ทำให้หนี้ทางเทคนิคมองเห็นได้ก่อนตัดสินใจว่าจะแบกเท่าใด รักษาทะเบียนทางลัดที่ทราบ การแก้ไขที่เลื่อน และการพึ่งพาที่ไม่ได้รับการสนับสนุนสำหรับทุกระบบที่ให้บริการ ทบทวนตามรอบคงที่ เพื่อให้การแบกหนี้อีกหนึ่งปีเป็นการแลกเปลี่ยนโดยจงใจแทนที่ไม่มีใครมอง
3. อย่าวางแผนการเปลี่ยนผ่านครั้งเดียวที่ย้อนกลับไม่ได้เป็นเส้นทางเดียวออกจากระบบเดิมที่สำคัญ ชอบแนวทางค่อยเป็นค่อยไป เช่น รูปแบบต้นไทรรัด ที่ให้ทดสอบ กลับคืน และนำออกใช้ทีละส่วน การแทนที่แบบบิ๊กแบงของระบบที่หลายล้านคนพึ่งพารวมความเสี่ยงหลายปีเข้าสู่สุดสัปดาห์เดียวโดยไม่มีทางกลับหากมีสิ่งล้มเหลว
4. ถือซอร์สโค้ดที่องค์กรของท่านจ่ายให้เขียนเป็นสินทรัพย์ที่เป็นเจ้าของ ไม่ใช่บริการที่เช่า เจรจาการฝากซอร์สโค้ดหรือความเป็นเจ้าของเด็ดขาด ณ จุดทำสัญญา ไม่ใช่หลังข้อพิพาทเริ่ม เพราะผู้จัดหาที่ถือสำเนาเดียวของโค้ดของบริการสำคัญของท่านคือการผูกติดกับผู้ขายโดยการออกแบบ
5. เผยแพร่ซอร์สโค้ดเป็นเปิดโดยค่าเริ่มต้น และต้องการเหตุผลเฉพาะเพื่อกักไว้ นโยบายโอเพนซอร์สโดยค่าเริ่มต้น ใช้อย่างสม่ำเสมอ เปลี่ยนซอฟต์แวร์ที่สร้างเองของทุกกรมเป็นสินทรัพย์ข้ามรัฐบาลร่วมแทนต้นทุนครั้งเดียว และให้ผู้เชี่ยวชาญภายนอกพบข้อบกพร่องด้านความปลอดภัยที่ทีมภายในลำพังจะพลาด
6. เขียนสัญญาซอฟต์แวร์ที่ทำให้การส่งมอบแบบวนซ้ำถูกกฎหมาย ไม่ใช่เพียงเป็นไปได้ทางเทคนิค สัญญาที่จ่ายเฉพาะเทียบกับข้อกำหนดคงที่ที่ตกลงตอนลงนามบังคับให้ทีมเลือกระหว่างแนวปฏิบัติคล่องตัวที่ซื่อตรงกับการปฏิบัติตามสัญญา ใช้ด่านเงินทุนเป็นขั้นที่ผูกกับซอฟต์แวร์ที่ทำงานที่แสดงแล้วแทนหลักชัยเดียวตอนท้าย
7. ให้ทุนการทำให้ทันสมัยเป็นโครงการต่อเนื่อง ไม่ใช่โครงการทุนครั้งเดียว ระบบเดิมที่ทำให้ทันสมัยครั้งเดียวแล้วทิ้งไว้อีกยี่สิบปีสะสมความเสี่ยงเดิมที่มันเริ่มต้น จัดงบสำหรับการต่ออายุแบบค่อยเป็นค่อยไปต่อเนื่องอย่างที่หน่วยงานถนนจัดงบสำหรับการปูผิวใหม่ ไม่ใช่การแทนที่ครั้งใหญ่หนึ่งครั้งต่อรุ่น
8. เลือกมาตรฐานเปิดและรูปแบบข้อมูลที่พกพาได้แม้เมื่อซื้อซอฟต์แวร์เชิงพาณิชย์ การกำหนดให้ระบบของผู้จัดหาเก็บและส่งออกข้อมูลในรูปแบบเปิดที่บันทึกไว้รักษาต้นทุนการเปลี่ยนให้ต่ำ แม้ซอฟต์แวร์เองเป็นกรรมสิทธิ์ และมักเป็นมาตรการป้องกันการผูกติดที่ทำได้จริงระยะใกล้มากกว่าการยืนยันให้ทุกระบบเป็นโอเพนซอร์ส
9. สร้างผลิตภัณฑ์ที่ใช้ได้ขั้นต่ำและแสดงให้ผู้ใช้จริงก่อนผูกพันกับขอบเขตเต็ม การปล่อยรุ่นขั้นต่ำจริง แล้ววนซ้ำตามสิ่งที่เรียนรู้ จับสมมติฐานที่ผิดขณะยังถูกที่จะแก้ แทนที่จะหลังระบบเต็มขนาดถูกสร้างเทียบกับมัน
10. รักษาขีดความสามารถวิศวกรรมภายในให้เพียงพอที่จะเป็นผู้ซื้อที่ชาญฉลาด แม้การส่งมอบจ้างเหมาภายนอก หน่วยงานสาธารณะที่กลวงความเชี่ยวชาญทางเทคนิคของตนประเมินข้อเสนอของผู้จัดหา สังเกตสัญญาณเตือนล่วงหน้าของโครงการที่มีปัญหา หรือเจรจาออกจากการผูกติดไม่ได้ ไม่ว่ากฎการจัดซื้อจัดจ้างของมันพูดอะไรบนกระดาษ
11. ลดโปรไฟล์ความเสี่ยงของระบบเดิมก่อนส่วนติดต่อผู้ใช้ของมัน จัดลำดับความสำคัญการแทนที่ภาษาที่ไม่ได้รับการสนับสนุน โครงสร้างพื้นฐานที่ไม่ได้ปะ และการผสานที่ไม่มีเอกสาร ความล้มเหลวที่ก่อการหยุดทำงานและการละเมิด ก่อนการทำให้ทันสมัยด้านภาพที่แบกความเสี่ยงเชิงปฏิบัติการน้อยกว่ามาก
12. วัดสุขภาพการส่งมอบด้วยตัวชี้วัดวิศวกรรม ไม่ใช่เฉพาะความแปรผันของงบประมาณและกำหนดการ ความถี่การปรับใช้ อัตราข้อบกพร่อง และอายุของรายการหนี้ทางเทคนิคที่ไม่ได้แก้เก่าที่สุดบอกคณะกรรมการธรรมาภิบาลมากกว่าเกี่ยวกับว่าโครงการจะสำเร็จหรือไม่มากกว่าว่ามันอยู่ในงบประมาณปัจจุบัน ซึ่งมักเป็นตัวชี้วัดสุดท้ายที่ขยับ

คำถามที่ควรหารือกับทีมของท่าน

เรารู้จริงหรือไม่ว่าเราแบกหนี้ทางเทคนิคเท่าใด ทีละระบบ? หน่วยงานสาธารณะส่วนใหญ่ระบุงบประมาณทุนของปีได้แต่ระบุไม่ได้อย่างมั่นใจว่าส่วนใดของระบบซอฟต์แวร์ของตนทำงานบนส่วนประกอบที่ไม่ได้รับการสนับสนุน ตรรกะที่ไม่มีเอกสาร หรือโค้ดที่ไม่มีใครเหลืออยู่ในบุคลากรเข้าใจเต็มที่ ใช้คำถามนี้เพื่อขอให้เจ้าของระบบแต่ละคนในห้องประมาณอย่างซื่อตรงว่ามั่นใจเพียงใดว่าทีมของตนเปลี่ยนระบบสำคัญที่สุดของตนได้อย่างปลอดภัยโดยไม่ทำลายสิ่งที่ไม่มีใครคาด หารือว่าต้องใช้อะไรเพื่อเปลี่ยนค่าประมาณเหล่านั้นเป็นทะเบียนจริง ทบทวนตามรอบคงที่ แทนความรู้ปากต่อปากที่ออกไปเมื่อวิศวกรสำคัญออก พิจารณาด้วยว่าใครตัดสินใจปัจจุบันว่ายอมรับการแบกหนี้ได้เท่าใด และการตัดสินใจนั้นโดยจงใจหรือโดยค่าเริ่มต้น

หากระบบเดิมที่สำคัญที่สุดของเราต้องถูกแทนที่เริ่มวันนี้ เราจะวางแผนการเปลี่ยนผ่านแบบบิ๊กแบงหรือการย้ายแบบค่อยเป็นค่อยไป และทำไม? สัญชาตญาณที่จะแทนที่ระบบเก่าทั้งหมดทีเดียวมักถูกขับเคลื่อนโดยรอบงบประมาณและความสะดวกในการบริหารโครงการแทนความจำเป็นทางเทคนิค และมันรวมความเสี่ยงมหาศาลเข้าสู่ช่วงเวลาเดียว ใช้คำถามนี้เพื่อไล่ดูอย่างเป็นรูปธรรมว่าการย้ายแบบค่อยเป็นค่อยไปแนวต้นไทรรัดของระบบเดิมที่สำคัญที่สุดของท่านจะหน้าตาเป็นอย่างไรจริง ทีละส่วน หารือว่าอะไรกำลังหยุดท่านจากการเลือกเส้นทางนั้นวันนี้ เงินทุนที่จัดโครงสร้างรอบวันเปิดตัวเดียว กระบวนการธรรมาภิบาลที่ต้องการหลักชัยสะอาดเดียว หรือข้อจำกัดทางเทคนิคจริงที่ทำให้การย้ายแบบค่อยเป็นค่อยไปเป็นไปไม่ได้สำหรับระบบนี้

ใครเป็นเจ้าของซอร์สโค้ดของซอฟต์แวร์ที่องค์กรเราจ่ายให้สร้างจริง และเราพิสูจน์ได้หรือไม่? หน่วยงานสาธารณะจำนวนมากค้นพบ เฉพาะเมื่อความสัมพันธ์กับผู้จัดหาเสีย ว่าสัญญาไม่เคยรับประกันความเป็นเจ้าของหรือการฝากโค้ดที่บริการสำคัญของพวกเขาพึ่งพาที่ชัดเจน ใช้คำถามนี้เพื่อดึงสัญญาสำหรับระบบเฉพาะที่สำคัญที่สุดสามระบบของท่านและตรวจสอบเฉพาะเจาะจงว่าแต่ละฉบับพูดอะไรเกี่ยวกับความเป็นเจ้าของโค้ด การฝาก และสิทธิที่จะนำโค้ดไปให้ผู้จัดหารายอื่น หารือว่าจะเกิดอะไรพรุ่งนี้หากผู้จัดหาหลักสำหรับระบบใดระบบหนึ่งในสามนั้นล้มละลายหรือปฏิเสธที่จะดำเนินความสัมพันธ์ต่อ

เรากำลังถอยไปหาซอฟต์แวร์ปิดที่เป็นกรรมสิทธิ์ตามความเคยชินตรงไหน เมื่อแนวทางโอเพนซอร์สโดยค่าเริ่มต้นจะรับใช้เราได้เท่ากันหรือดีกว่า? นโยบายโอเพนซอร์สโดยค่าเริ่มต้นมีอยู่พอดีเพราะหน่วยงานสาธารณะส่วนใหญ่แก้ปัญหาที่ทับซ้อนกันอย่างอิสระ แต่ละแห่งจ่ายต้นทุนเต็มสำหรับซอฟต์แวร์ที่หน่วยงานสาธารณะอื่นสร้างแล้วและแบ่งปันได้ ใช้คำถามนี้เพื่อระบุระบบหนึ่งที่กำลังถูกสร้างหรือระบุ และถามว่ามีของเทียบเท่าอยู่แล้วเป็นโอเพนซอร์สที่อื่นในรัฐบาลหรือไม่ หรือสิ่งที่ท่านกำลังสร้างจะเผยแพร่ให้ผู้อื่นใช้ซ้ำได้อย่างมีประโยชน์หรือไม่ หารือว่าอุปสรรคเฉพาะใด ข้อกังวลด้านความปลอดภัย ความเคยชินการจัดซื้อจัดจ้าง การขาดนโยบายที่ชัดเจน กำลังหยุดการใช้ซ้ำนั้นจริง แทนที่จะสมมติว่ามันไม่เกี่ยวข้องที่นี่

กระบวนการจัดซื้อจัดจ้างและความรับผิดชอบของเราอนุญาตการส่งมอบแบบคล่องตัวที่ซื่อตรงจริงหรือเพียงติดป้ายใหม่ให้หลักชัยน้ำตกเป็นสปรินต์? เป็นเรื่องปกติที่ทีมดำเนินพิธีกรรมที่คล่องตัวในนามขณะยังถูกให้ทุน กำกับ และรายงานเทียบกับข้อกำหนดคงที่ที่ตกลงตอนลงนามสัญญา ซึ่งสร้างรูปแบบความล้มเหลวของน้ำตกทุกอย่างซ้ำภายใต้ป้ายคล่องตัว ใช้คำถามนี้เพื่อสืบโครงการดิจิทัลที่มีชีวิตหนึ่งโครงการจากกรณีธุรกิจผ่านการรายงานธรรมาภิบาลปัจจุบัน และถามว่าโครงสร้างเงินทุนจะทนให้โครงการเปลี่ยนทิศทางตามสิ่งที่การปล่อยแต่เนิ่นจริงสอนหรือไม่ หารือว่าอะไรต้องเปลี่ยนในวิธีที่โครงการได้รับทุนและรายงานเพื่อให้การส่งมอบแบบวนซ้ำเป็นของจริงแทนที่จะเป็นเพียงเครื่องสำอาง (ดู หัวข้อ 3.7 — การจัดซื้อจัดจ้างภาครัฐและการมอบหมายบริการ)

เรามีขีดความสามารถวิศวกรรมภายในเพียงพอที่จะเป็นผู้ซื้อที่ชาญฉลาดของระบบที่เราพึ่งพามากที่สุดหรือไม่? องค์กรที่จ้างเหมาภายนอกวิจารณญาณทางเทคนิคทั้งหมด ไม่ใช่เฉพาะขีดความสามารถการส่งมอบ บอกไม่ได้ว่าข้อเสนอของผู้จัดหามั่นคงหรือไม่ โครงการกำลังมุ่งสู่ปัญหาอย่างเงียบ ๆ หรือไม่ หรือราคาที่เป็นธรรมสำหรับงานคือเท่าใด ใช้คำถามนี้เพื่อถามว่ามีกี่คนในองค์กรของท่านที่ทบทวนข้อเสนอสถาปัตยกรรมทางเทคนิคสำหรับระบบสำคัญที่สุดของท่านได้อย่างน่าเชื่อถือ และตัวเลขนั้นเปลี่ยนอย่างไรในห้าปีที่ผ่านมา หารือว่าต้องใช้อะไรเพื่อสร้างขีดความสามารถนั้นใหม่ที่ที่มันกัดกร่อน และองค์กรของท่านสูญเสียอะไร ในตำแหน่งการเจรจาเท่ากับความเสี่ยงการส่งมอบ ทุกปีที่ผ่านไปโดยไม่มี

ในทางปฏิบัติ: ตัวอย่างคุณค่าสาธารณะ

รัฐบาลระดับภูมิภาคสมมติ เป็นตัวอย่างเท่านั้น ไม่ได้อธิบายเขตอำนาจจริงใด ดำเนินการเรียกร้องสิทธิประโยชน์ว่างงานผ่านระบบที่เขียนครั้งแรกเมื่อกว่าสามสิบปีก่อน บำรุงรักษาโดยวิศวกรจำนวนที่ลดลงซึ่งเข้าใจภาษาโปรแกรมเดิมของมัน ปริมาณการเรียกร้องเติบโตเกินกว่าที่ผู้ออกแบบระบบคาดมาก การประมวลผลรายคืนล้มเหลวไม่เสร็จก่อนธุรกรรมของเช้าเริ่มมากขึ้น และผู้นำเทคโนโลยีของหน่วยงานเตือนว่าการหยุดทำงานที่ไม่ได้วางแผนซึ่งส่งผลต่อการจ่ายสิทธิประโยชน์ตอนนี้เป็นเรื่องของเมื่อไร ไม่ใช่ถ้า

สัญชาตญาณแรกของหน่วยงานเป็นการตอบสนองแบบดั้งเดิมต่อปัญหาที่รู้สึกเร่งด่วน มอบหมายสัญญาใหญ่ฉบับเดียวเพื่อแทนที่ทั้งระบบด้วยแพลตฟอร์มสมัยใหม่ ระบุเต็มล่วงหน้า ส่งมอบเทียบกับกรอบเวลาสองปีคงที่พร้อมสุดสัปดาห์เปลี่ยนผ่านครั้งเดียวตอนท้าย การทบทวนก่อนนำไปปฏิบัติที่คณะกรรมการตรวจสอบของหน่วยงานมอบหมายยกคำถามยากก่อนสัญญาถูกลงนาม จะเกิดอะไรกับการจ่ายสิทธิประโยชน์ให้ผู้เรียกร้องหลายแสนคนหากระบบใหม่มีข้อบกพร่องที่ค้นพบไม่ได้ในสัปดาห์แรกของการดำเนินงานจริงเต็มขนาด โดยระบบเก่าถูกปลดไปแล้วและไม่มีทางกลับ

หน่วยงานเปลี่ยนเส้นทาง มันรักษาระบบเดิมให้ทำงานเป็นระบบบันทึกและเริ่มสร้างฟังก์ชันรับการเรียกร้องและประเมินคุณสมบัติใหม่ควบคู่ ใช้แนวต้นไทรรัด แต่ละโมดูลใหม่ถูกปล่อยให้เปอร์เซ็นต์เล็กของการเรียกร้องใหม่ก่อน ตรวจสอบเทียบกับผลลัพธ์ขนานของระบบเก่า และขยายเฉพาะเมื่อผลลัพธ์ตรงกัน ภายในสิบแปดเดือน การเรียกร้องใหม่ส่วนใหญ่ผ่านส่วนประกอบสมัยใหม่ขณะที่ระบบเดิมจัดการปริมาณงานคงเหลือที่หดตัว พร้อมความสามารถส่งกรณีเดี่ยวใดกลับไปเส้นทางเก่าหากมีสิ่งดูผิด หน่วยงานยังกำหนด ในทุกสัญญาใหม่ที่ออกสำหรับงานนี้ ว่าหน่วยงานเป็นเจ้าของซอร์สโค้ดและเผยแพร่เป็นโอเพนซอร์สเมื่อการทบทวนความปลอดภัยเสร็จ เพื่อให้รัฐบาลระดับภูมิภาคอื่นที่เผชิญปัญหาเมนเฟรมสูงอายุเดียวกันดัดแปลงส่วนประกอบได้แทนที่จะทำซ้ำการสร้างเดิมจากศูนย์

การแทนที่เต็มรูปแบบของฟังก์ชันคงเหลือสุดท้ายของระบบเดิมใช้เวลาเกือบสี่ปี นานกว่า บนกระดาษ แผนบิ๊กแบงสองปีเดิมสัญญา แต่ไม่มีผู้เรียกร้องรายใดประสบการหยุดทำงานที่ไม่ได้วางแผนระหว่างการเปลี่ยนผ่าน แต่ละส่วนเพิ่มเล็กพอที่จะย้อนกลับได้ภายในชั่วโมงเมื่อพบข้อบกพร่อง และรัฐบาลระดับภูมิภาคเพื่อนบ้านสองแห่งเริ่มดัดแปลงโค้ดการประเมินคุณสมบัติที่หน่วยงานเผยแพร่สำหรับระบบของตนเองภายในปีแรกของการปล่อย

มุมมองสี่ภาคส่วน

รัฐบาลท้องถิ่น

รัฐบาลท้องถิ่นโดยทั่วไปดำเนินระบบเล็กที่ไม่เชื่อมต่อกันจำนวนมากแทนแพลตฟอร์มขนาดระดับชาติหยิบมือเดียว ซึ่งหมายความว่าหนี้ทางเทคนิคสะสมข้ามแอปพลิเคชันที่จัดซื้อแยกและบำรุงรักษาแยกกันหลายตัวแทนที่จะอยู่ในระบบเรือธงที่มองเห็นได้ระบบเดียว หน่วยงานท้องถิ่นโดยทั่วไปมีขีดความสามารถวิศวกรรมภายในน้อยที่สุดของรัฐบาลระดับใด ทำให้กรณีสำหรับการซื้อซอฟต์แวร์สินค้าโภคภัณฑ์ที่กำหนดค่าได้เหนือการสร้างเฉพาะแข็งแรงเป็นพิเศษ และทำให้แพลตฟอร์มร่วมระดับภูมิภาคหรือชาติ เรื่องของหัวข้อ 5.1 (ดู หัวข้อ 5.1 — รัฐบาลดิจิทัลและการเปลี่ยนผ่านสู่ดิจิทัล) เป็นเส้นทางคุณค่าสูงโดยเฉพาะเพื่อหลีกเลี่ยงการที่แต่ละหน่วยงานสร้างขีดความสามารถเดียวกันใหม่แยกกัน

รัฐบาลระดับชาติ

รัฐบาลระดับชาติคือที่ที่ระบบเดิมที่เก่าที่สุดและมีผลสืบเนื่องมากที่สุดมักอยู่ ภาษีหลัก ประกันสังคม และการบริหารสิทธิประโยชน์ เพราะระบบเหล่านี้มักเป็นหนึ่งในความพยายามทำให้เป็นคอมพิวเตอร์ขนาดใหญ่ครั้งแรกในรัฐบาลและตอนนี้แบกเดิมพันสูงที่สุดสำหรับความล้มเหลวในการทำให้ทันสมัยใด รัฐบาลระดับชาติโดยทั่วไปมีขีดความสามารถเชิงพาณิชย์และวิศวกรรมเฉพาะทางที่จะดำเนินโครงการทำให้ทันสมัยแบบค่อยเป็นค่อยไปจริงและเจรจาความเป็นเจ้าของโค้ดจริงเข้าในสัญญาของตน และโดยปกติเป็นรัฐบาลระดับที่อยู่ในฐานะดีที่สุดที่จะกำหนดนโยบายโอเพนซอร์สโดยค่าเริ่มต้นด้วยขนาดที่หนุนหลังพอจะทำให้การใช้ซ้ำข้ามรัฐบาลเกิดขึ้นจริง

ภาคสังคมและองค์กรไม่แสวงหากำไร

องค์กรไม่แสวงหากำไรและองค์กรการกุศลแทบไม่สร้างแพลตฟอร์มเฉพาะขนาดใหญ่เอง แต่บ่อยครั้งอยู่ปลายรับของซอฟต์แวร์ที่ผู้ให้ทุนรัฐบาลมอบหมายหรือบังคับ พอร์ทัลรายงาน ระบบการจัดการกรณีที่เงินอุดหนุนหรือสัญญากำหนดให้พวกเขาใช้ โดยมีอิทธิพลต่อการออกแบบ หนี้ทางเทคนิค หรือผู้ขายน้อย องค์กรภาคสังคมที่พึ่งระบบที่รัฐบาลกำหนดสืบทอดรูปแบบความล้มเหลวของระบบนั้นโดยไม่สืบทอดอำนาจต่อรองใดที่จะแก้ ซึ่งเป็นเหตุผลอีกข้อหนึ่งที่ความสัมพันธ์ด้านเงินทุนบนฐานผลลัพธ์ต้องคำนึงถึงภาระเชิงปฏิบัติการของเทคโนโลยีที่ถูกกำหนด (ดู หัวข้อ 3.7 — การจัดซื้อจัดจ้างภาครัฐและการมอบหมายบริการ) ไม่ใช่เฉพาะมาตรวัดผลลัพธ์เอง

ระดับพหุภาคีและระหว่างประเทศ

องค์กรพหุภาคีและหน่วยงานพัฒนาส่งเสริมซอฟต์แวร์ที่สร้างสำหรับการบริหารสาธารณะของประเทศหนึ่งมากขึ้นเป็นสินค้าสาธารณะดิจิทัลที่ใช้ซ้ำได้ซึ่งประเทศอื่นดัดแปลงได้ แทนที่แต่ละรัฐบาลมอบหมายระบบเทียบเท่าจากผู้จัดหาเอกชนด้วยต้นทุนเต็ม ความเสี่ยงที่โดดเด่นที่นี่คือสินค้าสาธารณะดิจิทัลที่สร้างสำหรับบริบททางกฎหมายและการบริหารของประเทศหนึ่งอาจถูกรับที่อื่นโดยการดัดแปลงน้อยเกินไป นำเข้าสมมติฐาน เรื่องอัตลักษณ์ คุณสมบัติ หรือกระบวนการ ที่ถ่ายโอนไม่ได้จริง คำสัญญาของโครงสร้างพื้นฐานเปิดร่วมเป็นของจริง แต่เฉพาะที่ซึ่งขีดความสามารถการดัดแปลงในท้องถิ่นจริงมาพร้อมโค้ด

รูปแบบความล้มเหลวที่พบบ่อย

การเปลี่ยนผ่านแบบบิ๊กแบงที่ล้มเหลวเมื่อเปิดใช้จริง ระบบเดิมที่สำคัญถูกแทนที่ในการเปลี่ยนผ่านครั้งเดียวที่ย้อนกลับไม่ได้หลังการพัฒนาหลายปีโดยไม่มีการเผชิญการผลิตสดเลย และข้อบกพร่องที่ปรากฏเฉพาะในขนาดจริงหรือในกรณีขอบที่ไม่มีใครทดสอบโผล่ขึ้นในวันแรกของการดำเนินงานเต็มรูปแบบ โดยไม่มีทางกลับไปสู่ระบบเก่าเพราะมันถูกปลดไปแล้ว ต้นทุนวัดเป็นการจ่ายที่พลาด บริการที่ถูกปฏิเสธ หรือการหยุดทำงานที่ส่งผลต่อพลเมืองที่ระบบมีไว้รับใช้พอดี ในช่วงเวลาที่แย่ที่สุด ช่วงเวลาที่ทุกคนพึ่งพาตัวแทนที่ทำงาน

การสะสมหนี้ทางเทคนิคอย่างเงียบ ๆ แรงกดดันกำหนดเวลาชนะข้อโต้แย้งต่อเวลาที่ต้องการเพื่อแก้ทางลัดที่ทราบซ้ำแล้วซ้ำเล่า และแต่ละการเลื่อนปกป้องได้เป็นรายข้อ จนหนี้สะสมทำให้การเปลี่ยนแปลงเล็กก็แพงและเสี่ยงอย่างไม่สมส่วน ต้นทุนปรากฏหลายปีต่อมาเป็นระบบที่ไม่มีใครแก้ไขได้อย่างปลอดภัย กำลังคนที่หยุดพยายามทำสิ่งใดนอกจากการปะที่เร่งด่วนที่สุดอย่างเงียบ ๆ และโครงการทำให้ทันสมัยในที่สุดที่ใหญ่และแพงกว่าการต่ออายุต่อเนื่องที่เล็กกว่าจะเป็นมาก

การผูกติดกับผู้ขายที่เข้าใจผิดว่าเป็นเสถียรภาพ หน่วยงานสาธารณะต่อสัญญาของผู้จัดหารายเดียวกันซ้ำ ๆ เพราะการเปลี่ยนดูรบกวนเกินกว่าจะพยายาม โดยไม่เคยทดสอบว่าต้นทุนการเปลี่ยนจริงจะเป็นเท่าใด หรือเจรจาความเป็นเจ้าของโค้ดและรูปแบบข้อมูลเปิดที่จะรักษาต้นทุนเหล่านั้นให้จัดการได้ ต้นทุนคือตำแหน่งการเจรจาด้านราคาและข้อกำหนดที่อ่อนลงถาวร ค้นพบเมื่อคุณภาพบริการของผู้จัดหาลดลงหรือราคาสูงขึ้นและหน่วยงานสาธารณะพบว่าไม่มีทางเลือกที่น่าเชื่อถือ

ความคล่องตัวแบบเครื่องสำอาง ทีมส่งมอบรับพิธีกรรมที่คล่องตัว การประชุมยืน สปรินต์ แบ็กล็อก ขณะที่สัญญา เงินทุน และโครงสร้างธรรมาภิบาลพื้นฐานยังสมมติข้อกำหนดคงที่และหลักชัยไป/ไม่ไปเดียว ดังนั้นทีมรายงานความเร็วสปรินต์ขณะส่งมอบเทียบกับแผนน้ำตกจริงข้างใต้ ต้นทุนคือไม่มีประโยชน์จริงของความคล่องตัว ข้อมูลป้อนกลับผู้ใช้แต่เนิ่นที่เปลี่ยนทิศทาง ความเสี่ยงที่ปรากฏเร็ว ที่เกิดขึ้น ขณะที่ภาพของแนวปฏิบัติสมัยใหม่ทำให้ความแข็งตัวพื้นฐานยากขึ้นสำหรับหน่วยกำกับดูแลที่จะเห็นและท้าทาย

นโยบายโอเพนซอร์สโดยไม่มีแผนค้ำจุน หน่วยงานสาธารณะเผยแพร่ซอร์สโค้ดเพื่อสนองนโยบายโอเพนซอร์สโดยค่าเริ่มต้นแต่ถือการปล่อยเป็นขั้นตอนปฏิบัติตามข้อกำหนดครั้งเดียว โดยไม่จัดสรรทรัพยากรสำหรับการทบทวนการมีส่วนร่วมภายนอก การปะช่องโหว่ หรือการบำรุงรักษาเอกสาร ต้นทุนคือคลังที่เผยแพร่ซึ่งดูเปิดแต่ทำงานเป็นทางตันที่ไม่ได้บำรุงรักษา ซึ่งทำลายความไว้วางใจในโครงการโอเพนซอร์สโดยค่าเริ่มต้นที่กว้างกว่ามากกว่าการไม่เผยแพร่เลย

แบบจำลองวุฒิภาวะ

รายการตรวจสอบ

• สำรวจหนี้ทางเทคนิคของทุกระบบสำคัญและทบทวนทะเบียนตามรอบคงที่
• ใช้กรอบการสร้างเทียบกับซื้อที่บันทึกไว้ก่อนผูกพันกับซอฟต์แวร์ใหม่ที่สำคัญใด ๆ
• สำหรับการแทนที่ระบบเดิมใด ๆ ตั้งค่าเริ่มต้นที่วิธีย้ายแบบค่อยเป็นค่อยไปและต้องการเหตุผลชัดแจ้งสำหรับการเปลี่ยนผ่านแบบบิ๊กแบง
• ยืนยันข้อกำหนดความเป็นเจ้าของหรือการฝากซอร์สโค้ดในทุกสัญญาซอฟต์แวร์ก่อนลงนาม
• เผยแพร่ซอร์สโค้ดภายใต้นโยบายโอเพนซอร์สโดยค่าเริ่มต้น พร้อมกระบวนการยกเว้นที่บันทึกไว้
• จัดสรรทรัพยากรการบำรุงรักษาต่อเนื่องสำหรับทุกคลังที่เผยแพร่ภายใต้นโยบายนั้น ไม่ใช่เฉพาะการปล่อยครั้งแรก
• ต้องการรูปแบบข้อมูลเปิดที่บันทึกไว้แม้ซอฟต์แวร์พื้นฐานเป็นกรรมสิทธิ์
• จัดโครงสร้างด่านเงินทุนรอบซอฟต์แวร์ที่ทำงานที่แสดงแล้วแทนหลักชัยข้อกำหนดคงที่เดียว
• สร้างและทดสอบผลิตภัณฑ์ที่ใช้ได้ขั้นต่ำกับผู้ใช้จริงก่อนผูกพันกับขอบเขตเต็ม
• ติดตามความถี่การปรับใช้ อัตราข้อบกพร่อง และหนี้ทางเทคนิคที่คงค้างเป็นตัวชี้วัดธรรมาภิบาลถาวร
• ประเมินขีดความสามารถวิศวกรรมภายในเทียบกับสิ่งที่ต้องการเพื่อเป็นผู้ซื้อที่ชาญฉลาด และปิดช่องว่างที่ระบุ
• จัดลำดับความสำคัญโครงสร้างพื้นฐานที่ไม่ได้รับการสนับสนุนและการผสานที่ไม่มีเอกสารก่อนการทำให้ทันสมัยแบบเครื่องสำอาง

แหล่งข้อมูลสำคัญ

• GOV.UK Service Standard, Government Digital Service, United Kingdom — มาตรฐานบริการดิจิทัลระดับชาติที่ต้องการการส่งมอบแบบวนซ้ำ ผู้ใช้เป็นศูนย์กลาง และมาตรฐานเปิดสำหรับบริการสาธารณะ
• Office of Management and Budget, Federal Source Code Policy (M-16-21), United States — นโยบายสหพันธ์ที่กำหนดให้หน่วยงานพิจารณาการใช้ซ้ำและการปล่อยโอเพนซอร์สสำหรับซอฟต์แวร์รัฐบาลที่พัฒนาเฉพาะ
• Free Software Foundation Europe, Public Money, Public Code campaign — เหตุผล พัฒนาสำหรับผู้ฟังยุโรป สำหรับการปล่อยซอร์สโค้ดซอฟต์แวร์ที่ได้รับทุนสาธารณะภายใต้ใบอนุญาตเสรีและโอเพนซอร์ส
• Ward Cunningham, "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — ถ้อยแถลงต้นฉบับของอุปมาหนี้ทางเทคนิค
• 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/