公共部門軟體工程與平臺

這為何對公共價值重要

如今,一位公民接觸到的幾乎每一項公共服務——登記出生、申領福利、繳納稅單、預約法庭日期——都在櫃檯或螢幕背後的某處執行著軟體。這套軟體很少是一次性的採購;它變成了國家永久性基礎設施的一部分,常常比委託建造它的政府、建造它的供應商,以及它的工程師所受訓使用的程式語言都存續得更久。一個公共機構不會像體驗一棟建築或一條道路那樣體驗軟體——建築或道路的狀況是可見的;而軟體會不可見地退化,這種衰敗的賬單會在多年之後作為一場緊急事件到來。

驅動本主題的張力是結構性的。軟體天生是迭代性的——需求隨著使用者與一個可運作的系統互動而變得更清晰,而最佳的工程實踐,是先構建一些小東西、從中學習,再加以調整。而相比之下,公共採購與問責週期(見主題3.7——公共採購與委託),是為資本工程與國防合同而建立的:一份固定的規格、一次單一的大額授標、里程碑付款,以及一份在交付開始之前數年就已籤核的商業論證。當一個立法機關或一位審計人員期望的是一份固定價格、固定範圍的合同,而一支工程團隊卻需要在第一次釋出之後改變方向時,這種不匹配便表現為範圍蔓延、預算超支,或一套在2019年被正確地明確規定、卻在交付時早已過時的系統。

本主題這門工程實踐存在的意義所要建立的這些平臺——共享身份系統、支付軌道、跨部門重複使用的個案管理工具——是主題5.1的主題(見主題5.1——數字政府與數字化轉型);本主題講的是構建與購買軟體的學問,它使任何這樣的平臺、或任何單一一項服務,變得可靠、可替換,並歸依賴它的公共機構所擁有,而不是歸恰好最先寫出它的那家供應商所擁有。

核心概念

自建與外購的決策,是在為一個組織的具體需求委託編寫定製軟體、與採用一款已經為一個由相似買家構成的市場而建立的可配置商品軟體之間做出的選擇。對於一項並非真正獨特的需求——薪資、電子郵件、標準的個案管理——外購通常更便宜、風險更低,而自建只有在需求差異大到沒有任何可配置的產品能夠適配、或這項能力本身就是這個組織需要擁有並使其演進的一項戰略資產時才是站得住腳的。

技術債務是軟體工程師沃德·坎寧安在1992年提出的一個比喻,指的是選擇一種權宜的方式來現在就釋出軟體、而非一種本會花費更長時間、更徹底的方式所累積起來的成本。技術債務,與財務債務一樣,並非本質上就是錯的——坎寧安自己的觀點是,快速釋出可用的程式碼、之後再重構,可能是正確的決定——但從未被償還的債務,會以更慢的交付、更多的缺陷,以及不斷上升的風險的形式產生利息,而一個看不見自己債務的公共機構,無法決定是應該償還它,還是任由它累積。

遺留系統是一種舊技術、應用程式或平臺,儘管已經過時,卻仍在被積極使用,常常是因為替換它代價高昂,或是因為這個組織裡已經沒有人完全理解它做了什麼。遺留系統在政府中格外頑固:數十年前用諸如COBOL——通用商業導向語言,於1960年為行政計算而設計——這樣的語言編寫的核心稅務、福利與社會保險系統,至今仍在為數百萬公民處理交易,因為這些系統能用,而安全地淘汰它們所需要的制度知識,常常先於系統本身"退休"了。

軟體現代化是把一套遺留系統轉換、重寫,或遷移到一種當前架構、語言或平臺的統稱。軟體現代化涵蓋一個譜系,從一次完整的重寫,到諸如把同樣的程式碼重新託管在現代基礎設施上等更為保守的選項,而在二者之間的選擇,既是一項風險管理決策,也是一項技術決策。

絞殺榕模式是一種漸進式的現代化方式,以一種纏繞在宿主樹周圍、逐漸取代它的藤蔓命名,在這種方式中,新功能與遺留系統並列構建,流量被逐塊重新導向它,而非在一次換約中替換整個系統。絞殺榕模式之所以重要,是因為它讓每一次增量都能被測試、被回滾,或被暫停,而不必讓整項服務停擺——這與一次大爆炸式替換正相反,後者是在單一一個時刻關閉舊系統、開啟新系統,一旦出了問題就沒有回頭路。

供應商鎖定發生在一位客戶變得如此依賴於單一一家供應商的專有技術、資料格式或合同條款,以至於轉向另一家供應商會帶來令人望而卻步的成本或風險。供應商鎖定在公共部門軟體中是一種特有的危險,因為買方是一位重複購買的客戶,卻幾乎沒有實際能力放棄一套正在執行一項關鍵服務的系統,這削弱了它在此後每一次續約時的談判地位。

自由與開源軟體是在一種授予使用者使用、研究、修改與再分發原始碼自由的許可證之下發布的軟體。自由與開源軟體支撐著一項預設開源的政策,依據這項政策,一個公共機構預設公佈自己委託編寫的原始碼,除非某項具體理由——安全敏感性、第三方權利——證成扣留它;其理由通常被總結為"公共資金,公共程式碼":用公共資金支付過一次的軟體,不應該需要在一個不同的轄區、由一個正在解決同一個問題的不同公共機構再次付費。

數字公共物品是在一種開放許可證之下發布的開放軟體、資料或內容,旨在幫助實現一項公共發展或治理目標、而非產生商業回報。數字公共物品把一個政府的開源釋出,重新構建為一整套更廣泛的、其他政府與公民社會組織能夠直接借鑑的共享基礎設施的一部分,而不僅僅是一種內部透明度姿態。

敏捷軟體開發是構建軟體的迭代方式的統稱,偏好可運作的軟體、頻繁的交付,以及對變化的響應,而非遵循一份事先商定的固定計劃。敏捷軟體開發與瀑布模型形成對比,後者是一種順序性方式,需求、設計、構建與測試各自完全完成之後,下一個階段才開始;瀑布模型對公共機構的吸引力,一直在於它的里程碑能夠整齊地對應到一份固定價格合同與一個年度預算週期,這正是為什麼如此多的採購法至今仍然假設它,即便交付實際上是真正敏捷的。

最小可行產品是一項服務能夠被髮布給真實使用者、以檢驗它是否可行、並瞭解接下來應該構建什麼的最小版本。這個最小可行產品概念,被改編進公共部門數字服務的操作手冊之中,給了一支迭代團隊一種站得住腳的方式,能在完整範圍完成很久之前,就向一位資助方或一位審計人員展示一些真實、可運作的東西——前提是問責流程接受一次真正最小化的釋出,而非把它當作換了個名字的成品來對待。

最佳實踐

1. 預設為未經區分的需求外購,把自建保留給真正獨特的東西。 薪資、電子郵件與一般性個案管理需求,很少與其他任何組織的需求有足夠的差異,以證成定製軟體;只有在需求、規模,或對這項能力數十年擁有權與演進權的需要,真正不同於市場所提供的東西時,才自建。
2. 在決定要攜帶多少技術債務之前,先讓它變得可見。 為每一套正在執行的系統維護一份已知的權宜之計、被推遲的修復,以及不受支援的依賴項的登記冊,按固定週期加以審查,使再攜帶一年債務成為一項刻意的權衡,而非沒有人去看它。
3. 絕不要把一次單一、不可逆的換約,當作擺脫一套關鍵遺留系統的唯一路徑來規劃。 優先選擇諸如絞殺榕模式這樣的漸進式方式,讓每一部分都能被測試、被逆轉,並逐步推出;一次大爆炸式地替換一套數百萬人依賴的系統,會把多年的風險集中到單一一個週末,而一旦出了問題就沒有回頭路。
4. 把你的組織付費編寫的原始碼,當作它所擁有的一項資產,而非租用的一項服務來對待。 在簽約的那一刻、而非一次糾紛已經開始之後,就協商好原始碼託管或徹底的所有權,因為一家掌握著你關鍵服務程式碼唯一副本的供應商,就是被設計出來的供應商鎖定。
5. 預設公佈原始碼為開源,並要求一項具體理由才能扣留它。 一貫地應用一項預設開源政策,能把每一個部門定製構建的軟體,變成一項跨政府的共享資產、而非一項一次性成本,並讓外部專家能夠發現一支內部團隊自己會錯過的安全漏洞。
6. 編寫讓迭代式交付合法化、而不僅僅是在技術上可能的軟體合同。 一份只依據簽約時商定的固定規格才付款的合同,迫使一支團隊在誠實的敏捷實踐與合同合規之間做出選擇;轉而使用與已展示的可運作軟體掛鉤的分階段資金關卡,而非最後的單一里程碑。
7. 把現代化當作一項持續的專案來資助,而非一次性的資本專案。 一套僅僅現代化一次、隨後又被放置二十年的遺留系統,會積累起它最初就有的同樣的風險;要像一個道路管理機構為重新鋪路編列預算那樣,為持續的、漸進式的更新編列預算,而不是每一代人才進行一次的宏大替換。
8. 即便在購買商業軟體時,也選擇開放標準與可移植的資料格式。 要求一家供應商的系統以開放的、有文件記錄的格式儲存與匯出資料,即便軟體本身是專有的,也能保持較低的轉換成本,而這常常是一項比堅持要求每一套系統都是開源的更容易在短期內實現的、防範鎖定的保障措施。
9. 在承諾完整範圍之前,先構建一款最小可行產品,並展示給真實使用者看。 釋出一個真正最小化的版本,再依據學到的東西加以迭代,能在錯誤的假設修復成本仍然低廉時捕捉到它們,而非在一套完整規模的系統已經依據它們構建完成之後。
10. 保持足夠的內部工程能力,使自己成為一位精明的買家,即便交付被外包出去。 一個已經掏空自己技術專業能力的公共機構,無法評估一位供應商的提案、無法發現一個陷入困境專案的早期預警訊號,也無法談出一條脫離鎖定的路徑,無論它的採購規則在紙面上怎麼寫。
11. 在改造一套遺留系統的使用者介面之前,先淘汰它的風險狀況。 優先替換不受支援的語言、未打補丁的基礎設施,以及沒有文件記錄的整合——那些造成宕機與安全漏洞的失敗點——而非運營風險小得多的外觀現代化。
12. 用工程指標、而非僅僅預算與進度差異來衡量交付的健康狀況。 部署頻率、缺陷率,以及最陳舊的未處理技術債務專案的年齡,能比"目前是否在預算之內"——這常常是最後一個變動的指標——更多地告訴一個治理董事會,一項專案是否會成功。

與團隊討論的問題

我們是否真的知道自己逐套系統攜帶著多少技術債務? 大多數公共機構能夠說出自己當年的資本預算,卻無法有信心地說出,自己的軟體資產中有多少執行在不受支援的元件、無文件記錄的邏輯,或沒有任何留任員工完全理解的程式碼之上。用這個問題要求房間裡每一位系統負責人誠實地估計,他們的團隊有多大信心,能夠安全地更改自己最關鍵的系統、而不破壞任何沒有人預料到的東西。討論一下,要把這些估計變成一份真正的登記冊——按固定週期審查、而非隨一位關鍵工程師離職而流失的部落知識——需要什麼。也想一想,目前是誰在決定攜帶多少債務是可以接受的,以及這項決定是刻意的、還是預設的。

如果我們最關鍵的遺留系統從今天開始就需要被替換,我們會規劃一次大爆炸式換約,還是一次漸進式遷移——為什麼? 一次性替換一套舊系統的本能衝動,常常是由預算週期與專案管理便利性所驅動的,而非技術上的必要性,而它把巨大的風險集中到了單一一個時刻。用這個問題具體地梳理一下,你最關鍵的遺留系統的一次絞殺榕式漸進式遷移,一塊一塊地看,實際上會是什麼樣子。討論一下,是什麼阻止了你今天選擇那條路線——圍繞單一一個上線日期構建的資金安排、一個想要一個乾淨利落的里程碑的治理流程,還是一項讓這套系統的漸進式遷移真正不可能的技術約束。

我們的組織付費構建的軟體的原始碼,實際上歸誰所有,我們能證明嗎? 許多公共機構只有在與一家供應商的關係惡化之後,才會發現合同從未確保過它們關鍵服務所依賴的程式碼的明確所有權或託管。用這個問題拿出你三套最重要的定製系統的合同,具體核查每一份合同關於程式碼所有權、託管,以及把程式碼轉交給另一家供應商的權利怎麼說。討論一下,如果這三套系統中任何一套的主要供應商明天倒閉、或拒絕繼續這段關係,會發生什麼。

我們在哪些地方出於習慣預設使用封閉、專有的軟體,而一種預設開源的方式本可以同樣好、甚至更好地服務於我們? 預設開源政策存在的意義,恰恰是因為大多數公共機構獨立解決著相互重疊的問題,各自支付另一個公共機構早已構建、本可共享的軟體的全部成本。用這個問題識別出一套目前正在構建或明確規定的系統,追問一個等價物是否已經作為開源軟體存在於政府別處,或者你正在構建的這個東西,是否可以有用地被髮布出去,供其他人重複使用。討論一下究竟是什麼具體障礙——安全顧慮、採購習慣、缺乏明確的政策——阻止了這種複用,而不要假設它在這裡不適用。

我們的採購與問責流程,是否真的允許誠實的敏捷交付,還是僅僅把瀑布式里程碑重新貼上了衝刺的標籤? 一支團隊一邊執行著名義上敏捷的儀式,一邊仍然依據合同簽約時商定的固定規格獲得資金、被治理並接受彙報,這種情況很常見,這在敏捷的標籤之下重現了每一種瀑布式失敗模式。用這個問題追溯一項正在進行的數字專案,從它的商業論證到它當前的治理彙報,追問這套資金結構,是否能容忍這項專案依據一次真正的早期釋出所學到的東西而改變方向。討論一下,要讓迭代式交付變得真實、而非表面文章,這項專案的資金與彙報方式需要做出什麼改變(見主題3.7——公共採購與委託)。

我們是否擁有足夠的內部工程能力,能夠成為我們最依賴的那些系統的一位精明買家? 一個不僅外包了自己的交付能力、也外包了自己全部技術判斷力的組織,無法判斷一位供應商的提案是否合理、一個專案是否正在悄悄走向麻煩,或者這項工作的公平價格實際上是多少。用這個問題追問一下,你的組織中有多少人能夠可信地評審一份針對你最重要系統的技術架構提案,以及這個數字在過去五年裡如何變化。討論一下,在這項能力已經流失的地方,要重建它需要什麼,以及每多一年沒有這項能力,你的組織在談判地位與交付風險上都損失了什麼。

實踐中的公共價值案例

一個虛構的區域政府——僅用於說明,不描述任何真實轄區——透過一套三十多年前首次編寫的系統處理失業福利申請,由數量不斷減少、理解其原始程式語言的工程師維護。申請量早已遠遠超出了這套系統設計者所預期的水平,夜間處理批次日益無法在早晨的交易開始之前完成,而這個機構的技術領導層警告說,一次影響福利支付的計劃外中斷,如今只是時間問題,而非會不會發生的問題。

該機構最初的本能反應,是針對一個感覺緊迫的問題所做出的常規回應:委託一份單一的大型合同,用一套現代平臺替換整個系統,提前完整地明確規定,依據一份固定的兩年時間表交付,末尾有一個換約週末。該機構審計委員會委託進行的一次實施前審查,在合同簽署之前提出了一個尖銳的問題:如果新系統在其第一週的全面、實時運營中出現了一項未被發現的缺陷,而舊系統早已被淘汰、無法回頭,那麼數十萬申請人的福利支付會發生什麼。

該機構改變了方向。它保留了遺留系統作為記錄系統,並開始使用一種絞殺榕方式,在它旁邊構建新的申請受理與資格評估功能:每一個新模組首先只被釋出給一小部分新申請,依據舊系統的並行輸出加以核實,只有在結果匹配之後才加以擴充套件。十八個月之內,大多數新申請都透過了現代元件執行,而原始系統處理著不斷縮減的剩餘案件量,並保留著如果任何一個具體案例看起來有問題,就能把它路由回舊路徑的能力。該機構還在為這項工作發出的每一份新合同中要求,原始碼歸該機構所有,並在安全審查完成後作為開源釋出,使面臨同樣老舊大型機問題的其他區域政府,能夠改編這些元件,而不必從零開始重複同樣的構建。

遺留系統最後剩餘功能的完全替換,花了將近四年——在紙面上,比最初兩年的大爆炸式計劃所承諾的更長。但沒有任何一位申請人在過渡期間經歷過一次計劃外的中斷,每一次增量的規模都足夠小,一旦發現缺陷就能在幾個小時內回滾,而兩個相鄰的區域政府,在該機構釋出的資格評估程式碼釋出的第一年之內,就開始為自己的系統改編它。

四種部門視角

地方政府

地方政府通常執行著大量較小、互不相連的系統,而非少數幾個國家規模的平臺,這意味著技術債務是在許多分別採購、分別維護的應用程式中積累起來的,而非集中在一個可見的旗艦系統之中。地方政府通常擁有所有政府層級中最薄弱的內部工程能力,這使得購買可配置商品軟體、而非定製構建的理由格外充分,也使得共享的區域或國家平臺——主題5.1的主題(見主題5.1——數字政府與數字化轉型)——成為一條避免每個地方政府各自重複構建同一項能力的格外有價值的路徑。

國家政府

國家政府通常是最古老、後果最嚴重的遺留系統所在之處——核心稅務、社會保險與福利行政——因為這些常常是政府最早的大規模計算化努力之一,如今任何一次現代化失敗都承擔著最高的利害關係。國家政府通常擁有執行一項真正漸進式現代化專案、並在自己的合同中談成真正程式碼所有權的專業商業與工程能力,它通常也是最適合設定一項預設開源政策的政府層級,因為它擁有足夠的規模,能真正讓跨政府的複用發生。

社會部門與非營利組織

非營利組織與慈善機構很少自己構建大型定製平臺,但它們常常是由一個政府資助方委託或強制要求使用的軟體的接受端——一個彙報門戶、一份撥款或合同要求它們使用的個案管理系統——對其設計、技術債務或供應商幾乎沒有影響力。一個依賴一套政府強制要求系統的社會部門組織,繼承了這套系統的失敗模式,卻沒有繼承任何修復它們的槓桿,這是基於成果的資金關係需要考慮強制性技術的運營負擔、而非僅僅是成果指標本身的又一個原因(見主題3.7——公共採購與委託)。

多邊與國際

多邊機構與發展機構越來越多地把為一個國家公共行政構建的軟體,推廣為一項其他國家可以改編的可重複使用數字公共物品,而不是讓每一個政府各自從頭以全部成本委託一套等價系統給一家俬營供應商。這裡特有的風險是,一項為一個國家的法律與行政情境構建的數字公共物品,可能在其他地方以太少的改編就被採納,輸入了一些實際上並不能遷移的假設——關於身份、資格,或流程。共享、開放基礎設施的承諾是真實的,但只有當真正的本地改編能力與程式碼相伴而行時才成立。

常見失敗模式

在上線時失敗的大爆炸式換約。 一套關鍵遺留系統,在多年的開發之後、沒有任何實時生產環境暴露的情況下,透過一次單一、不可逆的換約被替換,而一個只在真實規模下、或在一個沒有人測試過的邊緣情形中才會出現的缺陷,在全面運營的第一天就浮現出來,而由於舊系統早已被淘汰,沒有回頭路可走。這項代價以漏付的款項、被拒絕的服務,或恰恰影響這套系統存在意義所要服務的公民的中斷來衡量,而且是在最糟糕的時刻——每個人都在依賴這個替代方案能夠正常工作的那個時刻。

沉默的技術債務累積。 截止日期的壓力,反覆戰勝了修復已知權宜之計所需要的時間這一論點,而每一次推遲單獨看都是站得住腳的,直到累積起來的債務讓即便是一個小小的改變也變得代價不成比例、風險不成比例。這項代價在多年之後浮現,變成一套沒有人能夠安全修改的系統、一支已經悄悄不再嘗試任何東西、只處理最緊急補丁的員工隊伍,以及一個最終比持續的、較小規模的更新原本會需要的規模大得多、代價高得多的現代化專案。

把供應商鎖定誤認為穩定。 一個公共機構反覆續簽同一家供應商的合同,因為轉換看起來太具破壞性、以至於不敢嘗試,卻從未檢驗過真正的轉換成本會是多少,也從未協商過能讓這些成本保持可控的程式碼所有權與開放資料格式。這項代價是一種在價格與條款上被永久削弱的談判地位,只有當這家供應商的服務質量下滑、或它的定價上漲,而這個公共機構發現自己沒有任何可信的替代方案時才會被發現。

表面上的敏捷。 一支交付團隊採用了敏捷儀式——站會、衝刺、待辦事項清單——而底層的合同、資金與治理結構仍然假設著一份固定規格與一個單一的通過/不通過里程碑,於是這支團隊彙報著衝刺速度,而實際上卻在依據一份底層的瀑布式計劃交付。這項代價是,敏捷真正的收益——早期使用者反饋改變方向、風險被及早暴露——沒有一項真正實現,而現代實踐的外觀,卻讓監督機構更難看清並質疑底層的僵化。

沒有維護計劃的開源政策。 一個公共機構為滿足一項預設開源政策而釋出了原始碼,卻把這次釋出當作一次性的合規步驟,沒有為審查外部貢獻、修補漏洞,或維護文件配置任何資源。這項代價是,一個已釋出的程式碼倉庫看起來是開放的,實際上卻是一個無人維護的死衚衕,這對更廣泛的預設開源專案的信任所造成的損害,比一開始就從不釋出還要大。

成熟度模型

檢查清單

• 盤點每一套關鍵系統的技術債務,並按固定週期審查這份登記冊。
• 在承諾任何重大新軟體之前,應用一套有據可查的自建與外購框架。
• 對於任何遺留系統替換,預設採用漸進式遷移方法,並要求為大爆炸式換約提供明確的理由。
• 在簽約之前,確認每一份軟體合同中的原始碼所有權或託管條款。
• 依據一項預設開源政策公佈原始碼,並配有一套有據可查的例外流程。
• 為在這項政策之下發布的每一個程式碼倉庫配置持續維護的資源,而不僅僅是它最初的釋出。
• 即便底層軟體是專有的,也要求開放的、有文件記錄的資料格式。
• 圍繞已展示的可運作軟體、而非單一一個固定規格的里程碑來構建資金關卡。
• 在承諾完整範圍之前,先與真實使用者構建並測試一款最小可行產品。
• 把部署頻率、缺陷率與未處理的技術債務,當作常設的治理指標來追蹤。
• 依據成為一位精明買家所需要的東西,評估內部工程能力,並彌合已識別出的缺口。
• 在外觀現代化之前,優先處理不受支援的基礎設施與無文件記錄的整合。

關鍵資料來源

• 英國《GOV.UK服務標準》,政府數字服務局——一項國家數字服務標準,要求為公共服務提供迭代式、以使用者為中心的交付與開放標準。
• 美國行政管理和預算局,《聯邦原始碼政策》(M-16-21)——要求各機構為定製開發的政府軟體考慮複用與開源釋出的聯邦政策。
• 歐洲自由軟體基金會,《公共資金,公共程式碼》運動——為面向歐洲受眾開發的、把公共資助軟體的原始碼在自由與開源許可證之下發布的理由。
• 沃德·坎寧安,《WyCash投資組合管理系統》(1992年OOPSLA經驗報告)——技術債務這一比喻的原始表述。
• 數字公共物品聯盟——一項多方利益相關者倡議,維護著為服務公共發展目標而設計的開放軟體、資料與內容的標準與登記冊。

參考文獻

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/