Slashdot Mirror
Source Code Escrow
Makarand writes "According to this article in The Economic Times (India) Software companies in India
are embracing the trend where source code for the software being bought or sold
is
kept safe with an escrow agent
with carefully drafted agreements. This allows
the buyer to get hold of the source code in cases where software was licensed from a
start-up which has now folded or a breach of contract regarding the maintenance services
that were agreed upon can be proven. The source code is automatically released
upon the occurrence of any of the events mentioned in the escrow agreement and the
buyer will be able to study the source code and continue to provide support services
for the software bought without relying on the employees of the software supplier."
not just something that happens in India ... I put source into escrow as part, of a contract at least 15 years ago, and it certainly wasn;t a new idea then
Then you're truly fucked.
If the developer goes out of business, getting the source code by itself is almost always useless: almost no single customer will have the resources to maintain and extend it. Source code is only cost effective if there is a community of users and developers, and that requires releasing the code under an open source license ahead of time.
(For the same reason, Microsoft source code isn't their crown jewels, as they always claim: even if people got access to it, they couldn't develop and maintain it anyway. The main reason Microsoft doesn't want their sources released is probably marketing--the "Coca Cola Secret Formula" gimmick--and the probably embarrassing state of it.)
Another problem with source code escrow agreements is that people don't know whether the code deposited with the agent will even compile or be complete. And the agents themselves disappear or misplace code.
At least they mentioned documents and manuals related to the code. However, even with that, one thing that's over looked is the build system / environment. For any project interesting enough to put in code escrow, the build /cms system used is probably necessary.
Also, i wonder if these agreements are just the tip revisions of a bunch of files ? If so, you'd lose the incredible documentation provided by SCM changelogs. And if the SCM database is held in escrow, what if the software licensee doesn't have a valid license for the SCM system the code was developed with ? What if the SCM / build tools provider goes under, or has some problem ?
It'd be interesting to actually read one of the documents. The legal nonsense just to buy a house is absurd enough.. imagine trying to write a legal document that basically gives you a guarantee that you can survive without some random software company in India.
My opinions are my own, and do not necessarily represent those of my employer.
If I was a software supplier, I would certainly agree to somthing like this - there simply is no downside. For one, I can usually put the "source" in escrow but no-one really know if it's enough for someone to move forward.
Also, if the company goes into bankruptcy, the bankruptcy judge may have some reasons to intervene in such agreements.
An escrow contract simply does not compete with true open source software.
Source code escrow is a very old idea. I used it at my last job when in a situation where the two parties had not had a great relationship.
The trouble with the code escrow is that, of course, if the relationship (or the programmers' company) goes to hell then the buyer of the code will have a big lump of code that may or may not be obfuscated. It's questionable whether the code can be completed at all, let alone brought to market in a reasonable time period.
Another problem is that the escrow company we used charged fees for receiving the source code discs in the mail, additional fees if you actually wanted them to insert them in a computer and report what files existed, and exorbitant fees if you had the nerve to want them to compile and link the files. I don't know if they even offered the ability to run the resulting application to see what happened (i.e. to see whether the developer sent you the source for your project, or sent you the source for gcc running on a Sun 3).
It seems like a market opportunity for an IT-oriented company that has spare cycles, if any of those exist. Could be a nice sideline business. Advertising should be pretty easy; we had a hard time even finding the one (not very good) escrow service that we used.
I'd love to see a patch to SourceForge which allows a lawfirm to use an RFC protocol to validate access to the escrow.
--
make install -not war
Open source. Feeding no one. and no one. and no one still. Then your programmers die from lack of food.
Some of the early source code escrow companies themselves went bust. You need a software escrow agent that's likely to be around for decades. There are still companies offering software escrow services, but it's a minor business.
Iron Mountain has a software escrow business, and they offer some stories of software released from escrow. The most common situation is bankruptcy of a supplier.
Programmers don't need food. That's what Caffeine and Beer were invented for, to keep legions of coders alive.
There could be. Lawyers have consultants who help them with all sorts of stuff, including software. It wouldn't be so hard to have an expert verify the source code by compiling and comparing it against the binary software released.
"I assumed blithely that there were no elves out there in the darkness"
One way to assure that the customer is getting binaries that corrispond to the source in escrow would be to have the code given to the escrow company by the vendor, and then have the client pick up the binary directly from the escrow company... therefore delivering binaries that don't match the code would be impossible. Of course, the vendor should do they test-complies against the escrow's compiler to assure they work, but once there's a "release" the code is locked away at the escrow and the client gets the resulting binary with no room for monkey business on the way there.
Programmers don't need food. That's what Caffeine and Beer were invented for, to keep legions of coders alive.
Ok, who's gonna be the first one to make some caffeinated beer? I might vote for you in the next overlord election!
Ok, who's gonna be the first one to make some caffeinated beer?
.com bubble. I think they were the first to sell caffeinated beer...
It's been around a while - I remember hearing about Rethink Beer back during the height of the
Outsourcing to India, worrying about receiving proper code, escrow. All seem to be symptoms of the perverted view corporations have taken when viewing source code and programming as neither science nor art, but just another commodity. The problem is, that we're not talking corn or soy beans here, we're talking about a system designed for a particular reason. Anyone that has gone through a proper programming education (not that I'm claming to have done so, I'm in the middle of my undergrad career at Stanford but am considering CS) would be horrified at this approach. But it seems that many businesses are content not with how well a chunk of code is designed, but whether or not it functioned.
Code escrow is just another deluded side of this, a result of management types thinking CS is just "coding" and disregarding the quality of their product.
Quality, Functionality, Low Price. Pick two of the three.
Thinking that you're going to get _any_ use out of the cheapest functional code once it has been taken out of context (and probably not properly documented, or readable) is lunacy.
**AA: a bunch of mindless jerks who'll be the first against the wall when the revolution comes
There are a number of factors that determine how useful the source code is to a client, including:
It seems to me that source escrow could be made more useful if the escrow agent not only compiled the binary supplied to the client, as the parent suggests, but also studied the source and issued a report on factors like the above. This would allow potential purchasers to assess the risk that they were taking. This could affect the choice of software and possibly pricing - some buyers might be willing to pay more for software with lower risk, or might be willing to buy riskier software at a lower price on the theory that they could estimate what it would cost them to deal with less useful source if it came to that. And since many of the same factors tend to be correlated with code quality, a positive report on this front would also give some confidence in the quality of the program. Obviously open source provides the maximum protection, but if that is not an option, a system like this would seem to be helpful.
I had the lead for my former company's purchase of a customized Learning Management System. My employer was a privately held retail chain which could barely keep the configuration straight on our POS, and had already replayed the whole custom software development death march several times. But the lawers insisted that we obtain a "Source Code Escrow" for our $250k LMS purchase. I asked them under what conceivable circumstances they thought we would actually put together a team to take the code back into development, or even to create the build environment for debugging (and recursion testing, rinse, wash, repeat). I escalated to VPs, who basically said "Gotta have Source Code Escrow" while having no clue what would really be involved. So we paid for and got it. The LMS company indeed went belly up during the dotcom bust and we abandoned their product for an off the shelf system from a more stable vendor. But they still have the right to dig that old code out of escrow should they desire!
----- Indecision is the key to flexibility.
We were a medium large company with a package we wanted developed. For reasons I wasn't in on it wasn't being done in-house. The big concern was the small shop we were considering hiring going belly-up halfway through, or just as bad not being responsive to future maintenance issues or possible further development.
So I suggested escrow and it reassured the right folks in the right offices and the outside developer was also agreeable. So the next week our lawyers wrote something everybody was happy with and the contract was given and the project went ahead. A month or so later along with delivery of the application we got the code we'd paid for, our coders looked it over and liked the internals, it passed our QA, all good.
Later we paid for some bells and whistles to be added by the original developer. I also know our coders made some trivial changes to the cosmetic side. Beyond that it's probably still running pretty much as-was.
The escrow bit was really there to reassure folks; it sounded good and responsible to the folks nervous about hiring a small shop. In reality it probably would have cost us more in legal fees and meeting time (plus come-up-to-speed time for the coders) to rescue & reuse the escrowed code then just sending out the contract again or doing it in-house. But as administrative grease it worked fine.
Oh, Open Source? First off that company didn't think that way (insurance/HMO-type folks) so that battle would have been twice as tough as escrow was. Furthermore as the code was intended to touch our partners/owners/clients letting it free could have freaked them out too. These days at least they'd have heard of the OS though might still be hard to sell on actually implementing it (it'd publicize their internal data structures or something.)
Would I do it again? Sure in that kind of butt-covering situation. In an adversarial situation, particularly one possibly turning such early on, it'd be far too easy to poison (the benefits could never outweigh the costs of that sort of disaster anyhow).
I'd also not go with escrow alone for something big and complex and vital, too hard for someone else to pick up. In that situation either we'd bring it in-house, make damn sure of the developers, or perhaps require our interests being protected with our own team actively involved and vetting it.
But used it once, to good effect, yes.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
These are very real possibilities. They are also common outcomes in IT projects of years past. A source escro is mostly an agreement between a finished software vendor and a client. Between a company and a sub-contractor it's simply CYA. (And not a very good form at that.)
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Another problem with source code escrow agreements is that people don't know whether the code deposited with the agent will even compile or be complete
Escrow is just like software, its goodness or badness varies with the people involved. Nearly two decades ago I worked at a medium sized company that sold equipment to the phone company. Everything went into version control. Source code, documentation, compilers, libraries, tools, config files, etc. Developers produced a release candidate, passed along CRCs of all files to QA. QA wiped a PC's hard drive, grabbed the candidate from version control, built it for themselves, and verified the CRCs matched. QA only tested what they built for themselves. When a candidate was approved and released to the phone company that release was also sent to the escrow company designated by the phone company. And of course checklists documented the process above.
This comes up time and time again. There is an underlying assumption which is often voiced that there is a substantial quality difference between US code and Indian code.
This is usually bolstered with stuff like "art" and "quality", and "design".
Do you know what the difference between the illegal immigrant house painter that does cash-only jobs and the US programmer that holds your view point is ?
One of them is a pretentious asshole, and may have invested more heavily in formal education.
If people wanted "design" and "quality" and "art", nobody would buy Kia's. South Korea and Taiwan wouldn't have booming economies, and 95% of the clothes you wear wouldn't be made by children in malaysia.
But, as it turns out, by and large nobody gives a crap about those, or, they've made the determination that outsourced ultra cheap labour does the job acceptably well given the cost incurred.
Programming is no different. It's not like 50 years of American software engineering has produced an obelisk of invincible bug free code. No, we had Y2k, Windows 95, and a US vs Metric bug in a satellite.
Coding for Coding's sake is not a national treasure, it is not an art form, and really, it has nothing tod o with making money. IS/IT are a COST CENTER. Hiring programmers does NOT SELL SHOES. It does NOT SAVE LIVES. Everybody should be looking to save money on software development unlesss their business is software development! Otherwise it is an expense and subject to the inhouse vs outsourced discussion, just like any other expense!
Now, if your point had been "it's a shortsighted view to think you'll come out financially ahead by outsourcing software development to indian labor instead of using off the shelf stuff or using US based consultants", then you'd have an argument. But instead it smacks of idolization of the US intellect and the programmers-guild mentality so prevalent in the US/unix world.
My opinions are my own, and do not necessarily represent those of my employer.
It is always difficult to foresee what will happen to a computer-based system.
In 1989-1990 I was involved in a project that implemented a system that would have to be maintained for at least 10 (preferably 15) years.
The project was related to a mobile telephone network that predated GSM.
The people deciding the hardware and software platform chose the Digital Equipment Corporation VAX running VMS. Furthermore, a couple of Compaq PCs were used, running MS-DOS and using some very special cards in ISA slots.
In hindsight, what can we see:
- Digital Equipment Corporation no longer exists
- the VAX line was replaced by the Alpha
- which is being discontinued as well
- VMS I don't know, is it still maintained?
- MS-DOS isn't used by anybody anymore
- PCs with ISA slots are now very hard to get
- but fortunately: the network for which this was all developed was taken out of production after about 5 years, to be replaced by GSM.
I thing to sit out its entire 15-year maintenance would have been kind of tricky. Maybe with proper monitoring of end-of-sale announcments and buying some spares at the right time, it could have been pulled off.
The one downside I can think of is that it offers your customers an incentive to drive you out of business...
When programmers were rare, when the ability to develop digital solutions to real problems was an uncommon skill -- then software was science and art. However, today, programmers are a dime a dozen (at least in the states, overseas they're closer to three cents per bakers dozen) Software is now a tool to do a particular job.
When shopping for a tool, I don't look at how beautiful it is, or how elegant. Does it do the job I need it to do, and is it effective at doing so.
Software is the same way. Does this particular piece of software do the job that it's intended to do so, does it do it in an efficient manner that does not affect productivity or security in a negative fashion.
I honestly do not care how elegantly or clean the code is written, or that if I gave you four weeks of additional development time you could slim down the code by removing a few extraneous lines here and there. It quite simply does not matter.
This is why American programmers are failing when it comes to foreign competition. They view themselves as computer scientists -- or worse, digital artists of a sort -- and demand exorbant salaries for a job that someone shoved through two years of tech school can accomplish.
I am a network engineer -- I design and maintain telecommunications systems. I know that in a heartbeat there is probably someone out there that could snatch my job away from me at a moment's notice and for a significant paycut.
If American programmers would realize the same -- and accept the lower salaries that the global market is pushing on them -- then they may have a chance to compete.
I have. Several times.
Even non-compiling source code is very useful, for at least two reasons, and likely many more.
Interoperability/data extraction
Chances are if your software is abandoned, you're migrating to something else. Getting that data out of your old system is a lot easier if you can see the code that put it in there, as is writing a compatible system.
Maintenance by Reverse Engineering
Just seeing how things works allows you to extend the life of software by working around and fixing new problems. A good example is some abandonware we had that was locked by license key to a fixed hostid. A trawl through the source code would have allowed us to reverse engineer a license key generator and easily move the system to a new host. (In the end we had to fix this with judicious use of LD_PRELOAD and fake gethostid() and hostname() calls, but making a new license key would have been much nicer.)
From a business point of view, I'd like all software to be licensed under a source escrow arrangement.
- mib
It doesn't work well.
The main type of disaster (from the perspective of the user) is that the company forgets about business - concentrates on raising their share price or getting bought rather than on their product and customers - and is then bought.
This does not trigger the excrow.
THe companies that effectively fail are also bought, for not very much, and invariably by a company which has its own product in the area of work and wishes to recoup the cost of buying these new (and disgruntled) customers by selling them that product.
So the escrow doesn't trigger, the code is kept secret, support goes away, and the business and healthcare implications of a forced change of software and file formats are not avoided.
Open Source software and the development model that comes with it offer an alternative, and I would say are a necessary although not of themselves sufficient condition for stable satisfactory medical record software to be provided for periods approaching the duration of patients, doctors, Practice, hospitals (100, 30, 200, 300 years)
In the US there is the interesting and FOIA public domained VistA software for hsopitals, with the WorldVista not-for-profit interested in assisting anyone else to roll it out.
The UK NHS is currently in the process of procuring a large-scale computerisation of hospitals and data-spine to soak everyone's medical records into, and I suspect various aspects of previous efforts will repeat themselves. I place no reliance in escrow in avoiding trouble with this. Nor do I think FLOSS is a panacea, but I am convinced our chances would be better.
Not a rhetorical question.
My own personal experience--and of course I'm rendering myself vulnerable to remarks about the competence and professionalism of the companies I've worked at--it is that it is very, very, very rare for any source code depository that is not in active daily or near-daily use to be current, or even consistent enough to build. I don't say it can't be done. I just question, in practice, how often it _is_ done.
a) I've worked at a company that made a big deal of sending all their source to "secure offsite storage." What this meant in practice was labelling diskettes (this was a while ago) and sending them to this company. When, finally, an occasion arose to retrieve some of this source, it transpired that the company simply stored them--and had no way of finding or retrieving a particular diskette, even if you knew which diskette you needed and could tell them exactly what it said on the label.
b) Another company was developing a software product under contract to a company I worked at. We were supposed get the source to each and every version they released to us. In practice, most of the time any particular source archive they sent to us would not build or did not match the binaries. (This could, of course, gone undetected if we had simply been filing the archives away instead of actually trying to build from them).
"How to Do Nothing," kids activities, back in print!
about 20 years ago. We used some software written by Arthur Andersen called "Lexicon" and "Base V". This was software that we used to develop all of our applications, and the source to these products was kept in escrow. One day A.A. decided they didn't want to maintain these products any more, and we got the code from escrow. The code was written in Basic Assembly Language, but we were able to maintain it ourselves with no problem. This was fortunate, because absolutely everything we ran depended on this software.
Escrow is an old idea, but a very good one.
Please do not compare programming to engineering.
Engineers have one best method for accomplishing something. There may be several valid alternatives, but the difference between the alternatives can be measured.
Programming is still an art. Forget all the hype. Scientific analisys of various algorithms is very useful, but rarely affect real world solutions. First a business manager makes the primary decision about which technology to use. Not only does the manager have no knowledge of the technologies, this decision often contradicts the advice if the technical advisors. Then a project manager cuts the work into pieces and assigns them to porgrammers. Again, the knowledge of what pieces ahould be grouped for one programmer is ignored. And the assignment starts with the manager's favorite programmer taking the interesting pieces, regardless of the programmer's skill level or suitability. Then the programmers do their thing, which usually involves getting high on caffeine and using the mystical energy to conduct the thoughts of higher powers into electronic form.
---
American programmers vs. others:
I talked to a German programmer. After currency exchanges, she was making less than half what an American with her skill level would make, but she may have had a better standard of living.
I talked to a company that has outsourced some of their work to India. The big problem is that the work returns to exactly meet their specifications. American programmers translate business needs into code. The Indian programmers translate specifications into code. If those specifications are wrong, then the code is wrong. And the specifications are always wrong because programming is an art and requires flexibility during the coding process. This company solved this issue by adding a translation layer of managers and programmers between the specification writers and the outsourced programmers.
American programmers are arrogant individualists. This is good. They will tell you when a proposal is stupid. They will suggest better ways. The employable ones will still do the work when management insists on using the worst technology with even worse algorithms, but at least management knows they are being stupid. (Not that it matters after the project fails; the programmers usually still get the blame.)
No one shoved through two years of tech school can produce an application that is as fast, usable, and useful as an experienced business analyst/programmer. And much of that experience is still concentrated in the US. (I have friends from around the world, but they work here. Guess where Torvalds lives now?)
Disclaimer: I am not suggesting that all American programmers are better than all non-American programmers. Just suggesting that Americans have arrogance that has proven useful for programmers.
Yes, I know I am proving your point about American programmers. But we are worth the price. My customers insisted I raise my rate this year, and I was already in the 3-digit hourly. There may not be anybody in the world who could replace me.
I spend my life entertaining my brain.
However, this happened in the U.S. (the buyer was German, but had a large presence in the U.S.) If a U.S. company tries to enforce an escrow agreement against an Indian vendor, I'm not sure how that would work.
When the companies of one nation have their software written by another nation, it is like teaching people from another family to make a living, rather than teaching members of your own family.
Code written by Indian programmers will find its way into programs that are owned by Indian companies. The Indian companies will eventually compete against the companies who paid to have the software written.
Having source code in escrow misses the point. The point is that arms-length management of coding just doesn't work. It doesn't work even if done inside one company. Arms-length, detached management may seem to work in the short term, but there are numerous failures over time. So, if you think you need source code escrow, already something has gone wrong with your management.
For many business applications, the biggest intellectual challenge in producing code that is enduringly useful is in the communicating and management, not strictly in the coding itself.
I'm not the only person who thinks this. See comment #7812340: "Programming a decent size application is mostly communication and management challenges, not coding."
The article referenced by Slashdot, in the India Times magazine Economic Times, is an advertisement for a point of view, as is the Slashdot story. The real purpose of the article is to sell US and UK companies on the idea that the Indian company should be allowed to own the source code of the programs that it writes. Here is a quote from the article:
'Similarly Sanjay Deshmukh, business development director, Business Objects, states: "The customer who gets the source code, if the stipulated events occur, has only limited rights and can use the same only for support related activities. The customer cannot make commercial use of the same by reproducing it." '
Note that the recommended "stipulated events" are unlikely to occur without a VERY costly legal battle waged in two nations. Here is a quote:
'Subash Menon, president and CEO, Subex Systems, says, "The customer has to establish that they are unable to obtain support from Subex, causes could range from bankruptcy or discontinuation of that software product." Subex Systems has entered into such agreements only for its customers in North America.'
What are the chances that Mr. Menon will ever agree that he can't support software written by his own company? Zero. So, escrow is just a tax on the uninformed. If Mr. Menon goes bankrupt, what are the chances that his valuable interests will not be sold to another company? Zero again. Even if Mr. Menon and his employees all die in some terrible accident, Subex Systems will live on as a legal entity, because there is money in making it do so.
As a small software vendor, I've used escrow a number of times to solve the problem of 'what if you go out of business?', when selling packged products. In this 'shrink-wrap' context, it is very appropriate. The customer is getting the benefit of the lower prices associated with repeat/volume sales of a packaged product, and needs some kind of solid assurance that they will not be screwed if a small shop goes out of biz, is bought/merged, etc, since the SW will be used to run the customer's business.
In contrast, we always gave the code to customers in custom jobs / work-for-hire situations, so escrow wasn't an issue.
Most of the Indian shops are explicitly work-for hire -- custom jobs writen for internal apps or apps that the customer will be selling as packaged products. In this case, I would NEVER EVEN CONSIDER letting them keep the code. If they continue to discuss it for more than about two minutes, the conversation is over and we're down the street to their competitors. Period.
That is just my attitude based on the principle of the thing -- we are buying custom code and it is ours. Add to that my experience with at least one Indian shop. They were to produce code for a specific module with a well specified interface to other modules. After several months of back-and-forth, a piece of work that looked good (UI) was produced, but it had bugs. Attempting to integrate it without source code would have been impossible. As it was, once we really examined the source, we rejected the project and trashed the code. We rewrote it outselves in less than a month with a new hire fronm MIT with 2 years experience.
Would I ty outsourcing to India again? Yes, with the right circumstances and even more tightly defined specs (heck with their 'dedicated project managers' and consultants), and frequent intermideate source code review.
But, it is my considerd opinion that any manager that agrees to let those guys hang onto code, even with escrow, is seriously breaching his or her duty to protect the company and its employees.
I've developed and sold several products where I or my company have licensed them to a corporation. Each time the source code and environment had to be held in escrow with certain release conditions.
The most common was if I were to be out-of-commision or unreachable (at my choice of contact mechanisms) for more than two weeks.
The conditions and location have been generally very open to negotiation. For example, I added certain clauses and contact mechanisms to the standard software one, but I also removed some other restrictions because I didn't feel they were needed. As long as the contingency is covered, everybody is happy. It was a bit scary the first time for me, because I'm entrusting my leverage (excluding my skill and domain knowledge, which actually is the far greater leverage) to faceless lawyers, but I now rely on escrow as an advantage. It sooths the fears of the corporates.
Absolutely, anyone can build from an escrowed source. If the developer wants them to be able to.
We sell software. Fairly specialised software to a small number of customers. We put the code into escrow for a number of reasons. One is so that if we go out of business our customers aren't completely screwed. They can get together and use either some of their in-house developers or an external developer and have the code maintained. An added bonus is that it makes the customers happy to have that safety net.
(Another advantage is that the code escrow company also acts as an additional off-site backup for our code tree. Should something go horribly wrong and our development sites were to all be destroyed by an earthquake there'd still be yet another copy of the development tree at the code escrow company. And the code escrow company is a lot cheaper than most off-site data backup agencies...)
We cut each build from a CVS tree that contains all the source and configuration information. Immediately after a release build is done, we burn the CVS tree to CD. If it passes all the QA, we ship the CD to the escrow company.
Anyone with perl and a C++ compiler can build the full application from that CD. So, in our case, every escrowed source release can be retrieved and rebuilt (and the escrow company specialises in code escrow, and has for many years, so they're pretty good at version and media tracking).
If I were doing it again I'd create the build environment around Vesta rather than CVS, so guaranteeing that it can be rebuilt from archives to a bit-identical binary at any time, but Vesta wasn't really stable for production use when we started this project.
So code escrow works for us, but we (the software developer) are actively using it, rather than doing so grudgingly because a customer requires it, and that may not be the usual case. But it could be improved massively, by updating to newer technology. I don't want to have to ship CDs - I want to rsync or scp data. In fact, there's a lot to be said for giving the source not only to the escrow company, but also giving it (encrypted) to every customer, and giving the password to another escrow company that didn't need to do anything more than have an arrangement to release a password to each of our customers if we were to go under. There's a potential market there.
What's the advantage of having a code escrow company do this, rather than just having in our contract the commitment to release source if we go bust? Simple - many of the ways in which we could go bust, as a small company, could involve everyone involved being dead, or could involve legal action that ties all our assets up in court for years. In either case the escrow company can release the data as an independent third party.
(And why don't we "just open source our code" as many here suggest? It just doesn't work that way in the particular section of business we're in. In some fields it can work, in others it doesn't. We're in one where it doesn't. It's not that we're an anti-open-source company - just the opposite, we release a few open-source packages, and have a policy of going open-source with in-house tools where they'd be of broader value.)