程式碼交在光碟裡，封存二十年，沒有人再打開。
這不是意外，這是廠商壟斷的基礎建設。
政府花了幾千萬委託廠商開發一套系統。合約到期，驗收完成，廠商交出一張光碟——裡面是程式碼。光碟被收進倉庫，從此沒有人再打開它。
五年後要換廠商了。新廠商問：現有系統的程式架構是什麼？用了哪些技術？資料庫怎麼設計的？
沒有人知道。光碟還在倉庫裡，但沒有人知道是哪一張，也沒有人知道怎麼跑起來。
所以新廠商有兩個選擇：一、從頭重寫，成本高風險大。二、繼續找舊廠商，因為只有他們知道系統長什麼樣子。
這個問題不是沒有人想過，國際上有幾種機制試圖解決它：
| 機制 | 做了什麼 | 沒做到什麼 |
|---|---|---|
| Source Code Escrow （程式碼託管） |
由中立第三方保管程式碼快照，廠商倒閉或違約時釋出給政府 | 靜態快照、沒有版本歷史；只保護政府，不開放給競爭廠商；目的是業務持續，不是促進競爭 |
| Public Code （公共程式） |
政府直接將程式碼開源，所有人都可以用 | 廠商抗拒（智財疑慮）；政治阻力大；台灣目前連 git 管理都未建立，直接跳到開源是跳層 |
| 美國 DFARS 技術資料存取 | 允許第三方在 NDA 前提下存取技術資料 | 明確排除競爭廠商，只給非競爭的顧問用——方向和我們需要的完全相反 |
三種機制都有用，但都沒有解決核心問題：讓想來競爭的新廠商，在投標前能合法了解現有系統。
不要直接跳到完全開源，也不要繼續光碟封存。在這兩者之間，有一個中間地帶：
改變程式碼交付方式
驗收時，廠商不再交光碟或 ZIP，改為把程式碼提交到政府托管的私有 git repository。政府擁有這個 repo，有完整的版本歷史。
預設封閉，但可申請存取
Repo 預設為私有，不公開。但在簽署切結書的前提下，特定外部人士可以申請讀取權限。
兩種存取目的
目前設計的兩種合理使用情境：
切結聲明：「我是未來可能投標的廠商。我申請閱讀現有程式架構，僅用於了解系統現況和準備投標，不另做他用，不重製，不散布。」
切結聲明：「我申請閱讀程式碼以進行弱點掃描。所有發現的弱點將全數回報給機關和現有廠商，不另做他用。」
打破資訊壟斷。 目前新廠商不敢投標，部分原因是不知道現有系統有多複雜、有多少技術債。能先讀到程式碼，風險就可以被評估，投標意願自然提高。
降低換廠商的實際門檻。 機關選擇換廠商時，最大的障礙之一是「新廠商不熟悉現有系統」。如果競標前就能讀到程式碼，這個障礙大幅降低。
建立程式碼管理的基礎。 光碟驗收是個混亂的實務，版本無從追溯，歷史無從回顧。git 交付本身就是一個管理改善，和開不開源無關。
給廠商保留的彈性。 切結書保護了廠商的著作權，現有程式碼不會被直接抄走或公開，降低廠商的抗拒。比強制開源政治阻力小很多。
評審偏好的問題依然存在。 就算新廠商拿到程式碼、準備好了，評審仍可能因為「公司規模不夠大」而不選他們。資訊不對稱只是壟斷的一個來源，採購評審文化是另一個。
誰來建和維運這個平台？ 各部會不會互相管，不可能有中央單位強制各機關建。最合理的路徑可能是參考新加坡 GovTech 的 SHIP-HATS（政府統一托管的 GitLab），但這需要數發部有足夠的執行力，目前不確定。
需要修改驗收標準，不需要動採購法。 好消息是，把「交光碟」改成「提交 git repo」不一定要修採購法，可能只要修驗收規範和契約範本。但仍需要某個有權力的單位推動。
調查顯示，各元素分別存在於不同國家，但把它們組合成「以促進競爭為目的的限制存取機制」，目前沒有任何國家實施過（截至 2026 年 6 月）。
最接近的：新加坡 SHIP-HATS（強制 git 交付，但不開放競爭廠商）；美國 SHARE IT Act（repo 管理，但只開放給其他政府機關）；美國 DFARS（NDA 存取，但明確排除競爭廠商）。
這個問題——廠商鎖定、程式碼封存、新廠商無法進入——在各國政府都存在，只是被不同形式的問題遮蓋。這個中間路徑可能對其他國家也適用。