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
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.
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.
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.
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!
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.