Two words get used as if they meant the same thing. They do not. Conflating them is how clients end up with neither.
The short version
Open-source is a property of code: a license that lets you read, modify, redistribute, and run a piece of software on your own terms. It is a legal and technical condition.
Transparency is a property of an engagement: receipts you can inspect, decisions you can trace, claims you can falsify, dependencies you can name. It is an operational and behavioural condition.
A project can be fully open-source and still opaque in practice — the code is public, but nobody can tell what is actually running, who decided what, or which version of which model produced which output. A project can be fully closed-source and still genuinely transparent — proprietary code, but every decision, dependency, cost, and falsifier is in a ledger the client owns.
These two axes are independent. Treating them as the same thing lets vendors substitute one for the other when only one is convenient.
Where SWU draws each line
We do not promise everything we build will be open-source. We promise everything we build will be transparent. The two commitments are different in kind.
On open-source. Where a high-quality open-source tool exists for the job, we use it and we say so. Where the open-source option is materially worse than the closed alternative for the client's actual use case, we say that too, and we pick the better tool. The license is one input to the build decision, not the only one. What we will not do is ship a "we use open-source" line in the deliverable when the load-bearing component of the system is a closed vendor API that the client has no way to inspect, replace, or audit.
On transparency. Every engagement ships with a ledger the client owns. The ledger contains the dependency list (what, what it costs, how to replace it), the decision log (what we changed, when, and why), the evidence classes on every non-trivial claim, and the falsifier on every artifact (Class C — observable in the engagement's own ledger). The ledger is not a deliverable on top of the deliverable. It is the spine the deliverable hangs on. Without it, you do not have the deliverable — you have an unverifiable artifact.
That is the distinction in one line: open-source is about the code; transparency is about the receipts.
Why this matters more than it used to
The current wave of tools makes the difference sharper. A closed model behind an API can be the right call for a job — and it can also be the dependency that makes the whole system opaque if nobody writes down which version of which model produced which output on which date.
Open-source models on local infrastructure can be the right call for a job — and they can also be opaque if the prompts, the data, and the orchestration are scattered across three notebooks nobody can re-run.
Open-source is not a substitute for receipts. Receipts are not a substitute for an inspectable license when the client needs to fork. You need both judgements made independently, on the merits, for the specific engagement.
The two questions to ask any vendor
We use these on intake calls. They take less than two minutes between them.
- Of the components in this build, which are open-source, which are closed, and what is the migration path off each closed one?
- Show me the ledger entry where a decision was changed, and walk me through who decided, when, and on what evidence.
A vendor who can only answer the first question well has confused open-source with transparency. A vendor who can only answer the second one well has confused transparency with openness. You want both answered separately, in plain language.
What the ledger looks like in practice
A ledger is not a tool. It is a file the client owns, structured so a fresh reader can reconstruct what happened without asking us. Every entry has a date, an author, a class of evidence (A through F, plus U for unverified), and where the artifact lives. Decisions that were reversed are not deleted — they sit next to the reversal so the reader can see the path, not just the endpoint (Class E — the convention comes from scientific practice; we treat consultancy work the same way).
If you ever need to audit the engagement, fire us, or hand it to a different team — the ledger is what makes that fast instead of fraught. That is the point.
The honest framing
We are not the most open-source-heavy shop you will find, and we are not trying to be. We build systems where the client can answer, in their own words, what is running, why, what it costs, and how to leave. Sometimes that means open-source. Sometimes a closed component with a named replacement and a tested export. It always means receipts.