Why we keep client code off hosted repositories
On custody, liability and the difference between convenience and control. What a hosted repository actually commits a client to, and what it costs a company to refuse it.
Early in one of our builds a client asked where their code was. It is a reasonable question and it deserves a precise answer, so I want to give the answer we give and the reasoning behind it, because most software companies would answer it differently and most clients have never thought to ask.
Client code lives on our own machines and on infrastructure we own and control, for the whole of the build. We do not place it on a hosted repository service, which is an online service where a software company stores and manages its source code, and we do not place it on a public cloud. That is written into our terms, and it is the practice on every engagement regardless of its size.
What a hosted repository is, in contractual terms
A hosted repository is a service provided by a third party under that third party’s terms of use. When a software company puts your code on one, the contract that governs the storage of your code is between the software company and the provider. You, the owner of the code, are not a party to that contract, you have almost certainly not read it, and you cannot change it.
That contract will normally contain provisions on four matters that bear directly on your asset. The first is control of the account: the provider can suspend or terminate the account under conditions that it sets, and if it does so the code is unavailable until the matter is resolved between the provider and your supplier. The second is jurisdiction: the terms specify which country’s law governs the contract, and the provider decides where the data is physically held, so a UK business can find its code sitting in a data centre abroad and governed by another country’s law without ever having made that choice. The third is access: the terms describe the circumstances in which the provider, its contractors, or the authorities in its jurisdiction may access the content. The fourth is the use of content to improve the service, which covers telemetry and, in some cases, the training of automated tools. Whether a particular provider excludes private repositories from that, and on what conditions, depends on its current terms, and those terms change from time to time.
I am not suggesting that any particular provider behaves badly. The point is simpler than that. The document that governs what can happen to your code is one you have never seen, and the person who agreed to it is your supplier rather than you.
Custody and ownership are separate promises
Two undertakings are involved in any bespoke build, and they are regularly confused with each other. The first is custody: where the code is held, and who can reach it, while the work is in progress. The second is ownership: whose asset the finished code is, and from what date. A supplier can promise the second while keeping the code on a third-party service throughout the build, and many do. The two promises are independent of each other, and a client who wants both needs both in writing.
Ours are both in writing. The intellectual property in what we build, which is to say the legal ownership of the code, transfers to the client on payment of the final stage. Until that payment it is held by the company, and it is held on the company’s own infrastructure. After it, the client owns the source code, the documentation, and the right to do anything with them, which includes taking them to another supplier.
What refusing hosted services costs us
The decision has a cost, and I would rather state it than pretend otherwise. Source control, backups, code review and release tooling all have to run in-house. That means machines we own, maintain and secure; a backup regime that we have to prove works rather than assume works; and working habits that run against the grain of how most developers now operate, because a large part of the modern tooling assumes a hosted repository and has to be configured differently or replaced. Every new person who works with us has to be shown why we do it this way, and the explanation takes longer than the alternative would.
We prove the backup regime rather than describe it. Every build ends with a timed restore drill: we take the backups to a clean machine, bring the whole system back up from them against the clock, and record how long it took and what, if anything, went wrong. That record is handed to the client together with the source, the documentation and the operator guide, so the client knows that the system can be recovered and how long a recovery takes. A backup that has never been restored from has not been tested, and we would not ask a client to rely on one.
We regard this as a security obligation to the client rather than a preference of ours. The cost sits with us and the protection sits with the client, which is the correct way round for an obligation of that kind.
Four questions for any supplier
If you are having software built, or already have software that someone else built for you, these are the questions I would put to the supplier. The answers should be short.
Where does our code live while you are building it? The answer should name a place: the supplier’s own machines, a named hosted service, or a cloud account. A vague answer usually means a hosted service.
Who else can reach it? The provider of that service, the provider’s subcontractors, and anyone with access to your supplier’s account. Ask for the list.
What happens if you disappear? Illness, insolvency and a suspended account are all possible over the life of a build. You should be able to obtain the current code and documentation without your supplier’s cooperation, and the mechanism for doing so should be agreed before the work starts, not after the problem arises.
When does the code become ours? The answer should be a date or a defined event in the contract, and it should cover the source, the documentation and the right to take them elsewhere.
A supplier who has thought about custody will answer all four without difficulty. A supplier who has not will tend to explain why the question does not matter. The clients who are most affected by the answer are usually the ones who never asked the question, which is why we answer it before we are asked.
Written by the people who do the work at EGM Software. All Insights · Write to the company