I inherited a library's source code via an escrow process back in the 90s when the vendor went out of business. It was written in C and came with no documentation. It took a while to get the thing to build and understand where all the pieces were, but it wasn't too bad after that initial ramp up. I ended up maintaining that code for many years, doing everything from porting from x.25 to tcp/ip to making changes to the application layer protocol to keep up with industry changes.
My favorite memory was a comment I found buried in an exception handling section of code:
/* We would like to think that this would work well */
All in all, the escrow process was worth it for us as it was a critical piece of functionality that would have been difficult to replace otherwise.
These are a nice way to show larger companies you want to work with that you've made long term considerations for the sustainability of your software. We've brought this sort of thing up later in deal cycles if prospects have concerns over company future. We have contract clauses ready if they want to participate in the code escrow and many are happy to pay to join on as a beneficiary if we shut doors or discontinue our product.
In practice though, code escrows are kind of fraught with issues -- deposited source code that doesn't compile, out of date, etc. It's up to vendors to deposit working materials, as there isn't usually any kind of audit process. I can't imagine the costs and time it would take to pick up a vendor's source code, staff some maintainers, and get them efficient. Enterprise customers are usually shopping by requirements, not underlying tech, so they are likely not even aware of the tech they would need to hire for.
I don't know how others do it, but Dyalog puts everything necessary to build a fully functioning product on each escrow hard disk. So the only other thing necessary is a computer that can connect to the disk. Source: I work at Dyalog.
Does it include a fully bootable OS? Or does it include a libc? Or does it include a compiler and necessary libraries? Does the disk need a specific OS to read it?
I guess I'm asking what happens when you "connect" "a computer" to "the disk".
I wonder if there's a way to do something similar but with a deadman's switch. Escrow is a great solution, but kind of expensive.
On another point:
> in the unlikely event that we become unable to continue to service our customers
Maybe there's a second condition I'm missing here, but becoming unable to continue to service your customers is an incredibly likely event. The only alternatives are losing every single customer or existing as a business until the end of time. I'd put the probability of losing every customer as < 1/100 and of continuing until the end of time at 0. So 99% that this is the outcome. Again, maybe some alternative I'm missing.
"Losing every single customer" doesn't have to be as dramatic or unlikely as you make it sound. Consider the possibility that they could introduce a new product that supersedes the current one and they stop adding new features to the old product, and all customers eventually switch over. The old product has lost all of its customers, but it's just because they switched products. The escrow deal here is for the specific product, Dyalog APL. It wouldn't cover Dyalog NewThing. In this situation, the escrow never pays out.
This used to be somewhat common, before opensource really took off. I worked for 2 different companies in the late 90's early 00's that had everything in escrow as certain customers demanded it.
I recall working on a project a few years ago that had it in place. The end client was a hundred year old company, with bricks and mortar stores, that needed a boring, stable solution that had several key features. They would take only the older version that we built for the escrow, so that if things went sour they had a workign solution that they would have the source-code for that could be given to another company.
On the one hand it was a pain to work towards, as the requirements had little immediate value (new features needed lengthy documentation, lots of features had to be stripped out, long (manual) test checklists, etc) but on the other hand, it got you thinking about how to build software that would need to last longer than the company you're in. Made me realise that feature creep/bloat was what was holding the product back, not the Next Big Thing(tm).
I think the use-case for this is when the customer has not or is unwilling to upgrade from a "working version".
Having the ability to take ownership of that "working version" for their business continuity reasons can be invaluable.
Not sure how reliable this statistic[1] is, but a quick search yielded jQuery still has 11% of the market share. Interestingly, "websites added" > "websites dropped"!!!
PS: I have nothing but praise for jQuery and it's positive impact in the web world. However, given its age, seemed like a good example to illustrate the point.
Yes of course. An escrow is required for many contracts, especially for government subsidiaries. We have a SaaS service (a complex environment including a react front end) and still use an escrow service. A lot of it relies on docker images.
There should be should be a legislation for this - when a closed source software reaches EOL or is abandoned or the company that created it shuts down, the source code of the application should be made public.
The unfortunate counter to that is, "we can't release the source code as significant parts of it are still [used in / IP relevant to] the [maintained / new / upcoming] product".
This is why the third party 'pasc1878 suggests isn't enough - changes to standard practice, and likely to IP laws themselves, are needed too, which are unlikely to happen without regulatory pressure.
Sure, a third-party is required. What I meant is that there should be a law forcing software companies to commit their source code to such kind of third-party services (government or private run) so that closed source code can be open sourced after certain conditions are fulfilled.
I like this option a lot, although, Most companies would unlikely be able to implement something like this, solely on account of third-party dependencies.
Because Dyalog have failed to implement a HTTP->HTTPS redirect. Without this you rely on all your users understanding the difference between HTTP and HTTPS. Most don't and links to the HTTP version of your site will proliferate.
Around $4k to $10k depending on the number of beneficiaries. Each beneficiary enters into their own agreement with your company and NCC group, and then there is an overarching agreement between your company and NCC. There is a cost associated with initial setup between you and NCC, and then each beneficiary pays a bit too (you can pass on this cost to them if you like).
it solves one of the biggest fears against closed software, however nowadays also companies want engineers already to be pretrained in the exactly same area of the topic.
My favorite memory was a comment I found buried in an exception handling section of code: /* We would like to think that this would work well */
All in all, the escrow process was worth it for us as it was a critical piece of functionality that would have been difficult to replace otherwise.