2/23/2026 at 3:33:39 PM
Escrow used to be something we would see in large Enterprise software contracts. We would need to place the "gold" build of the software and associated source code on CD (or tape, depending on the year) and ship it to a third-party escrow service. Should our company go out of business, now former-customers could access the source through the escrow.It's kind of crazy to think about the process actually working though. The likelihood of a customer being able to recreate the build environment properly and produce a working release of our quite complex software seems low. It would probably be cheaper to putting that effort in to ripping out the solution then trying to patch some bug in a defunct vendor's solution.
by dluxem
2/23/2026 at 4:21:19 PM
This times a thousand!In the years before VMs, containers, and locked dependency manifests, it was essentially impossible to get repeatable builds. There are still a lot of hurdles and gotchas, but we can at least get a rough approximation. The idea that some other pre-2010 dev team was going to be able reliably build your thing from just raw source code, and have it closely resemble the thing you built—it was a delightful fantasy. Escrow was a sales and legal "don't worry we have that eventuality covered!" CYA and emotional de-risking move, not a practical expectation of ability to build from scratch.
by jonathaneunice
2/23/2026 at 6:02:31 PM
IMHO, code escrow isn't really about building the code for a maintenance release, although that might be nice. It's about reading the code to understand the system so you can workaround bugs and limitations and if needed, so you can know what was going on when you migrate to something else.by toast0
2/23/2026 at 5:01:59 PM
Now with LLMs, maybe yes to both solutions?by actionfromafar