Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Software Businesses

Source Code Escrow 182

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."
This discussion has been archived. No new comments can be posted.

Source Code Escrow

Comments Filter:
  • by Anonymous Coward on Friday December 26, 2003 @03:11AM (#7811442)
    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.
  • by k12linux ( 627320 ) on Friday December 26, 2003 @03:21AM (#7811476)
    The biggest problem I would have with this type of escrow situation is that there is no way to know how clean and maintainable the code is until the original developers are gone. Are there comments, are they meaningful. Is the code easy to follow, or does it look like this [ioccc.org]?

    Will my in-house programmers be able to work with it right away, or will they spend the next 6-9 months just figuring out how it works? Will *anybody* but the original programmer know anything about how it works?

  • Compile-by-escrow? (Score:4, Insightful)

    by LostCluster ( 625375 ) * on Friday December 26, 2003 @03:44AM (#7811535)
    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.
  • by jstockdale ( 258118 ) * on Friday December 26, 2003 @04:08AM (#7811586) Homepage Journal
    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.

  • by belmolis ( 702863 ) <billposer.alum@mit@edu> on Friday December 26, 2003 @04:33AM (#7811639) Homepage
    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.

    This isn't just escrow. You actually got the source along with the executables. That's even better than escrow since you can look it over and change it. It's like purchasing the source without the right to redistribute.

  • by EvilTwinSkippy ( 112490 ) <yoda AT etoyoc DOT com> on Friday December 26, 2003 @04:41AM (#7811652) Homepage Journal
    Except of course that there is no guarentee that the source is in a finished state. What if the company takes the big walk in the middle of a project? What if the company says that the project has met all requirements, yet the code is useless for the intended purpose.

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

  • by Anonymous Coward on Friday December 26, 2003 @05:28AM (#7811725)
    Feeding the middle man?

    In the current open source landscape, the programmer is the one primary not being paid.
  • by bmajik ( 96670 ) <matt@mattevans.org> on Friday December 26, 2003 @05:41AM (#7811740) Homepage Journal
    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.

  • by mib ( 132909 ) <mib@post.com> on Friday December 26, 2003 @07:56AM (#7811915)
    I've seen a lot of people comment that unmaintained source code is not useful. This is a fairly big assumption, and I'd wager few of you have actually been in the situation of losing a mission critical piece of software due to vendor abandonment.

    I have. Several times.

    Even non-compiling source code is very useful, for at least two reasons, and likely many more.

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

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

  • by solprovider ( 628033 ) on Friday December 26, 2003 @11:17AM (#7812311) Homepage
    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.
  • by Pfhreakaz0id ( 82141 ) on Friday December 26, 2003 @11:22AM (#7812340)
    BUT... in my experience, the hardest part of programming is having people who:

    a: understand the company's business and spec. the application. and

    b: Understand the technical stuff to ensure a quality product.

    people who can do a and b together (with the communication skills to boot) tend to get paid pretty well -- like me. Failing that, you have to have people in group a and b who trust each other and communicate well. This means speaking the same first native tounge. No matter how complete the spec, there will be a hundred thousand things not in the spec that are decided by people talking together. Programming a decent size application is mostly communication and management challenges, not coding. This is why outsourcing (in my experience) always costs more than having it done in house, even by an outside consultant who is hired per-hour to sit inside.

An authority is a person who can tell you more about something than you really care to know.

Working...