The Problem With Source Code Escrow

12/07/2017 02:58 pm ET

Source code is a collection of computer commands and comments written in a programming language, like Java, C or Swift. When compiled, the raw source code is then no longer human readable but runs very efficiently. Because compiled code isn’t easily disassembled, people cannot create their own versions of the software.

That Was Then

Once upon a time, organizations needed a copy of source code, in case a software vendor went out of business. Software vendors didn’t want to give up source code, but no one can ever guarantee they won’t go out of business. So much like putting funds into an account in a real estate deal, this allowed organizations to trust that they could get access to source for mission critical apps in the event that the software vendor went under. I remember working with one such organization back in the 90s.

Source code escrowing was common in large organizations that relied on software. And back then, a simple tool could be used to build software. An IDE compiled a piece of software and then customers received a copy of it that they paid for. Then 2 or 3 years later, you’d send them an update to the software. Maybe a couple of patches in the middle to resolve bugs with the software.

This Is Now

Then software developers started relying on plug-ins, modules, SDKs, other software, etc. Then you needed an artifact solution, such as Artifactory, build automation such as Jenkins, Maven, maybe database versioning and certain versions of actual third party coding tools or SDKs that didn’t work with others, so you ended up with a number of different tools required to install a computer that can actually build, or compile a version of your software.

And then came the cloud. Many an organization will kick off a build process in a tool like Jira. But servers to reduce the compile time can come online in an environment like AWS. And automated QA checks, security scans, and updates can kick in, leveraging third party APIs and services, many of which have high barriers of entry to purchase.

Putting Humpty Dumpty Back Together

In a modern build train, it’s not uncommon to have 5 pieces of software interacting with 3 or 4 cloud solutions. You can still ask for source code escrow when negotiating contracts. And if a vendor is willing to provide it, then great. But ask yourself what you’re actually getting. Could you, if needed, compile and open software from scratch based on what you’re getting from a vendor. Or would you need to create 5 servers, find 20 random tools that may or may not be included in the project, and maybe reverse engineer how to hook it all together?

Companies don’t often just disappear like they did once upon a time. There’s also a lot more options – and many a tool are interchangeable with their competition. These days, there’s likely to always be someone willing to rescue a company to get ahold of their code, or another company willing to take on an ecosystem, or just build an importer, even if doing so will cost extra.

Maybe it would be easier when negotiating contracts to require that software be open sourced in the event that the project goes dead. At least then a community can attempt to simplify it rather than just one of the former customers who may or may not have any engineers on staff that are capable of taking over the code.

This post was published on the now-closed HuffPost Contributor platform. Contributors control their own work and posted freely to our site. If you need to flag this entry as abusive, send us an email.
CONVERSATIONS