軟體原始碼託管，也就是把原始碼交給中立的第三方保管（英文稱為 software escrow），回應的是一種完全合理的擔憂：替你打造並維運關鍵系統的供應商收攤了，而你手上留下的，是一個自己離不開、卻又維護不了的東西。託管合約把原始碼寄存在第三方那裡，一旦真的發生這種情況，第三方就把它交付給你。

這種擔憂站得住腳。問題在於這項工具經常被誤解，而兩者之間的落差催生出一種合約：每年都在花錢，真到需要它的那一天卻幫不上忙。

簽約之前該先問的那個不舒服的問題： 如果明天就把程式碼交到你手上，你這邊真的有人跑得起來嗎？一份沒有建置說明、沒有基礎架構定義、沒有它所呼叫的第三方服務憑證、也沒有資料的原始碼託管，不是營運持續計畫。那只是一個資料夾。從來沒有驗證過的託管合約，交付的往往正是這種東西。

軟體原始碼託管涵蓋什麼

這是你、供應商和託管機構三方簽的合約。供應商把資料寄存在託管機構，機構負責保管，而事先約定的交付條件決定你在什麼時候拿到它。

真正值得談判的是交付條件。破產是最明顯、也最容易舉證的一條。但實務上，別的條件更重要：供應商停止維護產品、不再履行支援義務，或者被你的競爭對手併購。觸發條件列得太窄，代表恰好在你最需要資料的那些模糊情境裡，機構會拒絕交付。

託管的內容本身也不該只有原始碼。至少要包含：具體到足以組出一套可執行系統的建置說明、各個相依套件的準確版本、基礎架構設定、外部服務清單以及憑證存放位置的說明，還要有一位寫明姓名的技術窗口。少了這些，原始碼幾乎一文不值。

而且託管內容必須持續更新。簽約時取一份、之後再也沒有換過的副本，只是一份已經沒有人在跑的軟體的精確紀錄。

為什麼多數託管在交付時失效

因為沒有人檢查過。

制式合約是一份法律文件，它預設技術內容沒有問題。託管機構提供的驗證服務分成好幾級，從確認媒體讀得出來，一直到把託管內容真的編譯出來並在乾淨環境裡跑一遍。所謂乾淨環境，指的是一台沒有你們內部設定、也沒有開發人員機器上那些歷史遺留設定的機器。便宜的那一級幾乎什麼都證明不了。昂貴的那一級才是唯一能回答你真正在意的問題的版本。

認真驗證一份託管內容時，常見的結論是：少了一個沒人寫進文件的工具就建置不出來；相依於一個私有套件庫，而這個套件庫會隨供應商一起消失；需要一些從未列出的服務憑證；或者乾脆就是一個比正式環境還舊的版本。

如果你打算為託管付錢，那就為驗證付錢。沒有驗證過的合約轉移的是風險的感覺，而不是風險本身，而兩者的價差，比在最糟的時刻才發現真相的代價小得多。

SaaS 的問題

傳統託管假設軟體會由你自己來跑。對於架在供應商那裡的軟體，這個假設通常並不成立。

拿到一個你一直透過網路使用的平台的原始碼，你依然需要基礎架構、部署工具、維運知識和你自己的資料，而其中大部分並不在託管內容裡。就算整包都齊全，把它立起來也要花上數週，而依賴這套系統的公司往往沒有這幾週時間，因為業務不會因為供應商消失就停下來等你。

這就是為什麼對線上服務真正有用的保護完全是另一副樣子。資料匯出權比程式碼更重要：一項依文件化格式完整匯出資料的合約權利，而且要定期真的行使，而不是停留在承諾上。持續營運承諾，也就是供應商同意在合約終止後仍依約定期限繼續提供服務，買到的是光靠程式碼得不到的移轉時間。一份你真的試過、而且通過驗證的匯出檔，比任何你從沒試過的託管內容都更有價值。

對大多數線上服務來說，託管合約是憑慣性買下的錯誤工具，這筆錢花在你已經證明自己讀得懂的定期匯出上更划算。

費用多少，適合誰

託管是一筆按年發生的費用，通常每年從幾百英鎊到幾千英鎊不等，取決於託管內容的份量、受益方數量和驗證等級。驗證另外計費，真正有份量的支出就在這一塊，因此把預算全押在保管費上、卻把驗證省掉，通常是最不划算的分配方式。

它確實適合：一中斷就會讓業務實際受損的系統；規模小到倒閉確有可能的供應商；地端部署或可以自行架設、你也真的跑得起來的軟體；以及主管機關或客戶合約要求必須做的場合。

它比較不適合：反正你也不會自己跑程式碼的線上服務；替代品到處都是的通用系統；以及年費在合約金額裡占比明顯的小型供應商。

最值得先考慮的替代方案，其實就是自己擁有程式碼。如果這是你委託開發的客製專案，就把智慧財產權讓與和每次發版時的儲存庫副本談進合約。這樣連託管機構都不需要了，而我們那篇技術盡職調查指南裡列的重點，正是讓這樣一次交接真的可用的那些重點。

如果還是要買，怎麼讓它管用

不要照單全收制式清單，要把交付觸發條件談下來，除了破產之外，也要把供應商實際上放生產品的情況寫進去。

把託管內容寫在合約本文裡，而不是寫在沒人會看的附件裡：建置說明、基礎架構定義、相依清單、外部服務盤點，以及一位寫明姓名的窗口。

要求按約定的週期更新，或者每個大版本發布時更新，並且要求提供確實更新過的證據。

為託管機構真的把資料建置出來並跑起來的那個驗證等級付費，然後把報告讀完。一次查出問題的驗證，正是在盡它的本分。

另外也要測一下你自己這邊的準備度。如果資料明天就到，你這邊由誰接收，接收之後第一件事要做什麼？沒有內部負責人的託管合約是一張發票，不是一份計畫。我們那篇災難復原指南裡的思路在這裡可以直接套用。

Mecanik 既自己把程式碼寄存進託管，也在軟體開發工作中協助客戶判斷他們到底需不需要託管。多數時候，誠實的答案是：同樣一筆錢，花在通過驗證的備份和清楚的智慧財產權歸屬上，買到的保護更多。

常見問題

什麼是軟體原始碼託管？ 這是客戶、軟體供應商和託管機構之間的三方合約。供應商把原始碼和配套資料寄存在託管機構，當約定條件成立時，機構把它交付給客戶，最常見的條件是供應商破產或停止維護產品。

為什麼託管合約在交付時會失效？ 因為託管內容從來沒有驗證過。常見結論包括：少了沒寫進文件的工具就建置不出來；相依於會隨供應商一起消失的私有套件庫；缺少外部服務的憑證；或者版本比正式環境還舊。只有把託管內容編譯並執行起來的驗證，才回答得了真正的問題。

軟體原始碼託管對 SaaS 有用嗎？ 效果很差。拿到線上平台的原始碼之後，你依然需要基礎架構、部署工具、維運知識和自己的資料，把它立起來還要數週。資料匯出權、合約裡終止後的持續營運期限，以及定期實際測試過的匯出檔，對線上服務的保護比程式碼託管好得多。

軟體原始碼託管要花多少錢？ 通常每年從幾百英鎊到幾千英鎊，取決於託管內容的份量、受益方數量和驗證等級，驗證另外計費。有份量的支出在驗證上，少了驗證的合約轉移的是風險的感覺，而不是風險本身。

託管有替代方案嗎？ 對於你委託開發的客製專案，談下智慧財產權讓與加上每次發版時的儲存庫副本，就完全不再需要託管機構。對於線上服務，一份你真的試著讀過、而且有文件說明的匯出檔，通常比任何你沒試過的託管內容都更值錢。