Open Source and Escrow
Computer Weekly had an article by Bill Goodwin this week describing some of the problems facing those requiring source code escrow from suppliers. As you'd expect, problems for the customers tend to indicate a variety of problems at the supplier.
Anyone who has worked in a software development organisation knows that the build tools and process are often the most arcane part of the setup. Whether your a small company building internal tools or a major software supplier building shrink-wrapped product the build tools often don't get the care an attention that they deserve. The article in Computer Weekly lists six common problems found in escrow software, taken from a report by escrow specialist NCC Group:
- Software suppliers submitted blank disc, rather than source code
- One software supplier's back-up script contained errors, which was not spotted until escrow verification
- One supplier could not find the source code to submit it
- Personal e-mails and confidential memos, including details of which staff were to face redundancy, have been found on discs sent for escrow
- Discs containing computer games, such as Doom, Duke Nukem, and the Leather Goddesses of Phobos have been sent in for escrow
- Suppliers lock software with a password, then forget the password
Some of these are pretty amusing, but with a little experience it's not difficult to see how they arise. In a previous job I managed the final stages of a y2k compliance project, which included building a copy of some services in miniature, so that we could see how they behaved around the time of the clock rollover and test any remediation. One of those services, which provided facilities to almost every one of the company's customers, could only be rebuilt from source on one particular machine. The setup of that machine was lost in history - where was the source for the libraries that were sitting in /usr/local/lib?
Recently I spoke with some people who thought that by using open source software they were avoiding all of these traps. "The source is available", they say. "We'll just download and build it." In an ideal world things might be this simple, but the reality is so different. The interaction between different open source components can be extremely complex. A Linux distribution like Debian devotes a significant amount of time to ensuring that all of the pieces work together (and not necessarily that they work together well). Companies like Sun spend a huge amount of money and time providing application compatibility so that a change to one component shouldn't impact another. Even if you can build everything you need from source - can you afford to?
As one would expect, this provides a great opportunity for service companies. SpikeSource are working to validate a variety of application stacks, though I don't see any mention of escrow for the components (but they'd be crazy not to do it). Alternatively, there's a great consultancy opportunity for companies like OPENreSOURCE to assist suppliers, customers and even escrow agents in staying both honest and sane.
As a customer, the rule is pretty straightforward: if you care about something enough to consider escrow of the sourcecode, you absolutely must spend the time to ensure that you can take advantage of the service in your hour of need. You have to independently verify that the escrowed materials can be used to produce the end result that you need, and you have to do this regularly. It's just like testing that you can actually restore from your backups (you are testing that, right?).