Microspeak: Escrow(devblogs.microsoft.com)
devblogs.microsoft.com
Microspeak: Escrow
https://devblogs.microsoft.com/oldnewthing/20260217-00/?p=112067
9 comments
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.
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.
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.
Now with LLMs, maybe yes to both solutions?
This sounds like Acceptance testing after Acceptance testing when rally big stakes have already been staked.
I don't think it applies if your company calls itself a startup.
I don't think it applies if your company calls itself a startup.
This would be an interesting pattern for a coding agent or orchestrator.
Isn't this just "release candidate" by another name?
That's the whole Microspeak scheme: rename any generic term into a Microsoft term to encroach claim without sweat. Bunch of mooches.
I'm pretty sure I recall "release candidate" being used in other divisions so it might be Windows division specific terminology. Microsoft is a big place.
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.