Why you need the source code, even if you will never read it

“I am not a programmer, why do I need the source?” is a fair question. The answer is not that you will read it. It is that holding it removes every failure mode that comes from not holding it.

Four things it buys you

Continuity. Vendors stop responding. Developers change careers, get ill, or simply lose interest in a small maintenance contract. With the source, that is an inconvenience — someone else can pick it up. Without it, your trading stops when their attention does.

Auditability. You can have someone you trust read what the code actually does. Not what the documentation says: what it does. For software that holds API keys and places orders with your money, this is not paranoia.

Negotiating position. A vendor who holds the only copy of your trading system has structural leverage over every future conversation about price and priority. This is not a claim about anyone's character; it is a description of the incentive.

Changeability. Strategies need adjustment. If every parameter change is a support ticket with a lead time, you will stop making changes you should make.

What the refusal tells you

There are legitimate reasons a vendor cannot hand over everything — a licensed third-party component, a shared framework used across clients. Those are specific and they come with a specific explanation.

A blanket refusal usually means one of three things, none of which is good for you: the business model depends on lock-in; the code would not survive review; or the same code is being sold to many clients, in which case see why the bot you bought does not work.

Source alone is not enough

A repository with no documentation and no way to run it is technically a handover and practically useless. What makes it real:

• It runs. A clean checkout, documented dependencies, and a command that starts it on testnet.
• Configuration is separate from code. Parameters in config, secrets in the environment, no magic numbers buried in a strategy file.
• Tests exist. Not full coverage — enough that a future developer can change something and find out whether they broke it.
• A runbook. How to start, stop, check health, read logs, and what each alert means.
• Architecture notes. Which module does what, and why the boundaries are where they are.

That last one costs an afternoon and saves the next developer a week. We write it because we are frequently the next developer on someone else's system, and we know what its absence costs.

The uncomfortable version

Insisting on source code protects you against us as much as against anyone else. That is the point. A working arrangement should not depend on continued goodwill when it can depend on you holding the artefact.

It also disciplines the work. Code that will be handed over and read by someone else gets written differently from code that only its author will ever see — which is a benefit that lands on the client side, quietly, before the handover ever happens.