Trust but Verify: A Lesson for Software Buyers
The phrase “trust but verify” harkens back to the Ronald Reagan presidency and the final days of the cold war. Relations with the Soviet Union were beginning to thaw and progress was being made to reduce the terrifying number of nuclear weapons that threatened not just both of the superpowers, but the entire human race. Along with a level of trust that each side would honor the agreement, a process for verification was negotiated, and the phrase “trust but verify” came into common usage. This almost sounds like a contradiction in some ways. If you truly trust, then why would you verify?
But in reality, life is complicated. There are many individuals involved in the process of dismantling a missile silo. The people who negotiate the agreement are not the same ones who implement the agreement. And people make mistakes even if they have the best of intentions. So the long version of that expression should read something like “trust people to do what they say, but verify that they didn’t make a mistake doing it.”
Nowhere does this hold truer than with software escrow services. When you license software, you depend on critical applications to run your business that are outside your control. Even with the best and most cordial of business relationships there is still plenty of potential for error. So… trust but verify.
Where exactly does verification fit into the escrow process and how does it work? Let’s start by taking a step back and looking at the escrow process. Software escrow is a way for developers and users to protect what matters to them. Developers want to protect the intellectual property (IP) they’ve developed, and users want to know that the software they’ve licensed will always be there when they need it. In order to make this happen, the developer stores copies of their source code with a neutral trusted third party—such as Iron Mountain— and the user gains access to that source code only in specific circumstances. Typical events that trigger a release include bankruptcy or other situations where the developer can no longer support the software.
In a case where the escrowed software is released, the objective of the user is to get back up and running as soon as possible. This means being able to quickly and easily compile the software, make any changes or fixes that are needed, and roll it out for their use. It is not enough for most of the software to be escrowed; you need to include everything that is required to compile the code efficiently. This can include compile scripts, libraries, and other elements besides the core code. If the developer forgets any of these items, it might be difficult or even impossible to actually compile the software. And this is where verification comes in. With verification, you know that if the need arises, you’ll have the complete source code you need to maintain your critical application.
When the developer deposits the source code with Iron Mountain, we can run a series of verification steps to make sure that the right code is there and everything needed to compile the code is intact. The first step in this process is to extract the files from the escrow deposit and compare them against the list of what is supposed to be included. This verifies that what is supposed to be there is complete. This stage of verification easily catches simple errors of omission and lets you weed out simple errors without any further effort.
The next step is to actually compile the software. This is where any scripts, files or libraries that are missing will become immediately apparent. Unless you have absolutely everything that is needed to build the final product, the compilation will not succeed. Where the first stage tells you that you have everything you think you need, the second stage of compilation tells you whether you actually do have everything you need.
The third and final stage of verification is to actually execute the compiled software. This validates that the correct version of the software was placed in escrow by matching the compiled version with the current available version. Without taking these steps you might wind up with an unpleasant surprise should you ever need to access the software that is being held in escrow. Even in the best of circumstances it is very easy for a mistake to be made unintentionally. All it takes is one missing file or the wrong version of one key file and your escrow is no longer valuable. So trust your development partners, but trust more in your verification. n
Want to learn more? Ask for a free copy of our book “Escrow for Dummies” at
http://digital.ironmountain.com/content/SoftwareEscrowforDummies
John Willoughby is responsible for solutions marketing for Iron Mountain’s Secure Shredding and Technology Escrow Services. John can be reached at john.willoughby@ironmountain.com
