Source Escrow, Meet Grumpy IT Guy - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IT Life
12:02 PM
Grumpy IT Guy
Grumpy IT Guy

Source Escrow, Meet Grumpy IT Guy

Today's gripe: The source code escrow service shake-down.

Source code escrow was such a great idea at the time: Buy enterprise software. Sign escrow agreement with third-party company. Software vendor goes out of business. Third party has the source code. We can (maybe) compile it. And miraculously, we will be good to go (also maybe) -- even without support.

But I am ready to ditch.

The last straw was this: Like most companies, ours has an agreement with source code escrow service for ERP. Escrow company gets in touch for "critical message about your escrow."

I get back in touch. They say, sure, we have the code, but do you really, really know that compiling with XYZ toolchain will work? Do you really know? WHY DON'T YOU KNOW!?

[Beware these office offenders: Cubicle Sins: 10 Coworkers Who Drive You Crazy.]

I feel like I have been grabbed and shaken. No, I say. You're right. I don't really know. But we have current code. We know what tools were used to compile. Are you making me crazy for nothing?

No, of course not, says company. Not for nothing! We are making you crazy because ... MONEY!


For a LOW, LOW PRICE, we can remove your fear! We can do a test! For every patch!


But I thought I was already paying you for removing my fear?

No! All we do is escrow the code! Look at your agreement! We are just a drop box.

And it's true. Most escrow companies are just drop boxes for code. It's an additional fee for code compilation services.

But let's get real. Code escrow is the pterodactyl soaring from the age of mainframe into today. By the time you escrow today's code, it has changed. Today's IT looks at value of data, not ERP code. If an ERP vendor goes under, we change ERP and do data export. I don't know anybody who would stick with an ERP solution if the company went under. We need support! We do not want to be in the business of wrenching on our ERP.

My CSO would also not be happy if the company had no official support and regular security patches. Code escrow was created before every bit of useful software connected somewhere to the Internet, and before the days of zero day vulnerability.

No, I changed my mind. Code escrow is not a pterodactyl. It is a Klingon on the butt of IT, a checkbox on ERP purchasing best practices from the old days that just hasn't been taken off yet. We are not expanding use of code escrow. In fact, I'll bet the business in general for code escrow is shrinking.

Thus some bright boy at code escrow company says: Oh, I know! Generate fear! Offer new service! Generate MONEY!

Except you ain't getting me. Or my company.

Avoiding audits and vendor fines isn't enough. Take control of licensing to exact deeper software discounts and match purchasing to actual employee needs. Get the Software Licensing issue of InformationWeek today.

Grumpy IT Guy avoided historic disasters and clueless people while working his way up the IT ranks, but he retained his keen sense of humor. He now leads an IT organization somewhere in America, as part of the FBI's Grump Protection Program. Need advice? Send questions to ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
8/17/2015 | 1:30:28 PM
Re: Source code

I would imagine that if the data is stored in-house, then a data escrow service would not be necessary in the event of vendor failure because the servers are on-premise and owned by the beneficiary

However, if the software application is hosted in the cloud and the data is also stored on 3rd-party servers (ie:Rackspace, AWS, etc) and not co-located, then a SaaS Availability Escrow Agreement along with a data-extraction and verification of the application would be able to provide assurances on 2 levels:

1. That the application would stay accessible and function properly for a time-period adequate enough for the company to transition to a new provider.

2. The data will be available and not lost in the event of vendor failure.


*Disclaimer: I would for an information assurance firm that specializes in Intellectual Property Escrow. If you have any questions feel free to email me at [email protected]


User Rank: Ninja
10/13/2014 | 12:16:06 PM
Re: Source code
>>But, if the provider is startup then there is a chance that the firm might fail.

@Brian, you nailed the 800 lb gorilla in that room. I suspect that is major reason the big players get most of business is just for that reason.

And it is not clear who the winners and losers will be. Our global company perfect example. In late 90's they rolled out BPCS ERP installs to many of our business units, including the one I still work at. About 10 years ago they did study, with heavyweight consultant help, to choose a std ERP solution to replace BPCS, thinking it was a "burning platform". At time, BPCS was under it's original ownership, relatively small player compared to SAP or even JD Edwards. So they narrowed choice down to SAP and MS AX Dynamics. They realized they couldn't afford SAP so AX was chosen.

After that decision, BPCS was sold to SSA (a bigger software holding company) and then a few years later Infor bought SSA. Now Infor ranks #3 last I heard, behind SAP and Oracle. So not quite the burning platform they predicted.

But the Oracle's of the world are scary enough. They own so many different ERP solutions, you always wonder when they will cut you off at the knees by discontinuing one and trying to move you to "Fusion" (or whatever they call their flagship now). Even AX and Microsoft is a little scary to me, that is not a native MS system or technology. Some little company in Denmark wrote it, targeting Oracle database. When MS bought, they made sure it ran on SQL Server but pretty much leave the part of business to standalone. If they ever spun that business back off, would AX give you a warm and fuzzy with vendor size of the Denmark HQ?

I think SAP gets many of their Fortune 500 clients strictly because they offer most clarity of product and very low risk of not being there in future.

I can't imagine being a startup cloud ERP vendor and trying to convince customers to buy. S C A R Y!
User Rank: Ninja
10/12/2014 | 4:53:55 PM
Re: Source code
Extremely interesting points, @Terry. What about data escrow services in both environments that house data in-house and/or the cloud? Data is the driver behind the value that ERP solutions create. If the provider is a large provider then there isn't a lot of risk for the provider to go bankrupt. But, if the provider is startup then there is a chance that the firm might fail. 
User Rank: Author
10/10/2014 | 4:17:13 PM
Fear sells
The dropbox analogy is pretty good, Grump. I suspect the fear sells, especially if it is not a lot of $. Or maybe others have seen your POV....?
User Rank: Ninja
10/10/2014 | 2:05:44 PM
Source code
Source code is one of my pet peeves also but for entirely different reason than GITG talks about. When I first started IT work in 1985, you always got source code when you bought ERP. And you usually had people like me who could customize it to the business and support it. The source code was in major business languages in common use like COBOL and RPG supported by vendor who had nothing to do with ERP vendor.

The exception was the source code in the security part of system, where they implemented code to prevent you from changing hardware without getting new "keys" from the ERP vendor so the software would work on new hardware. That forced you to pay annual maintenence or repurchase software again when changing hardware. I never did understand why these ERP vendors felt entitled to be paid again just because you changed hardware. Upgrading to new release is one thing, running same code on other hardware is not reason for them to cash in again. But they got away with it, giving them that steady stream of maintenance revenue forever.

But that wasn't enough for them. They wanted that lucrative action of customizing and deploying for companies that bought it. So they began using proprietary programming languages and compilers, limiting the pool of IT people who could work on it to them and their partners. The ones who still used "normal" programming languages just started withholding all source code. For legacy customers that had customized, they agreed to sell you rights to have this source code to support your customizations. This money is in addition to what you payed for the ERP itself, and it wasn't cheap.

The escrow GITG is talking about had to be for code to the security parts you never got. That gave you some protection in case vendor went belly up and your hardware upgrade introduced a major change, at least you could change/compile and keep going. An example of that is when IBM AS400 went from 32 bit CISC to 64 bit RISC systems. Programs had to be recompiled in most cases. So your ERP vendor had to send you new compiled security programs you didn't have code for. If vendor gone, you were 100% DOA.

These source escrow vendors may or may not have been any help in that situation. If simple recompile, sure. If any code needed to be refactored for any reason, probably not.

GITG is right, in long run if your ERP vendor goes belly up, you will find another solution. But it can take a long time to switch, especially if you have customizations.

So in the short run, which could be 1-3 years, you better have some protection to change hardware until you get to new ERP. And only access to source code can do that. But that still no guarantee, depends on how they lock their software to a piece of hardware, the generation of a key/license. If that algorithm is not in your source code, you are DOA no matter what. Well, unless you are really good at hacking hashing routines....
The State of Chatbots: Pandemic Edition
Jessica Davis, Senior Editor, Enterprise Apps,  9/10/2020
Deloitte on Cloud, the Edge, and Enterprise Expectations
Joao-Pierre S. Ruth, Senior Writer,  9/14/2020
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
White Papers
Register for InformationWeek Newsletters
2020 State of DevOps Report
2020 State of DevOps Report
Download this report today to learn more about the key tools and technologies being utilized, and how organizations deal with the cultural and process changes that DevOps brings. The report also examines the barriers organizations face, as well as the rewards from DevOps including faster application delivery, higher quality products, and quicker recovery from errors in production.
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Flash Poll