Who actually builds "open source"?
- Perspective
- Open Source
- Trust
A public repository is one of the most reassuring artifacts in software. You can read the commits, watch the issues, see the pull requests land. It feels like proof — not just that the code is good, but that a community stands behind it. For software that guards your most confidential documents, that feeling is worth examining, because it quietly bundles two very different claims into one.
The first claim is transparency of process: the work happens in the open, where anyone can watch. The second is collaborative development: many independent people actually build and maintain the thing. The first does not imply the second. A repository can be perfectly public and still be the work of a single person.
The label hides a narrower story
Look closely at many widely-starred "open" projects and the contributor graph tells a quieter story than the star count: one founder writing the overwhelming majority of the commits, perhaps a colleague or two, and — increasingly — an AI coding agent committing alongside them. External contributions over a full year often round to zero. The public is watching; the public is not building.
Stars measure distribution and goodwill, not engineering leverage or a bench of maintainers who would keep the project alive if the founder moved on. None of this makes those projects bad — plenty of excellent software is built exactly this way. The problem is the inference a buyer is invited to make: that "open" means "battle-tested by a crowd," "audited by many eyes," "resilient because the community owns it." For most projects, that crowd does not exist. The openness is real; the community is a marketing surface.
Ask what openness delivers you
So the better question isn't "is it open?" It's what does this openness actually deliver me? If the answer is "you could read the code," be honest about whether you — or anyone you trust — ever will. The "many eyes" only audit when many eyes are actually looking, and for a niche confidential-document tool, they rarely are. A public repo is a credibility signal. It is not, by itself, an assurance.
Verifiable, not just visible
We'd rather give you the assurance directly. We don't ask you to trust a star count or assume a community has vetted our code. We ask you to verify — on the things that matter most.
Our tamper-evident audit trail is hash-chained and externally anchored, and it is built to be recomputed and checked independently: mutate or forge a single record and the chain fails the check, no faith required. Our codebase carries roughly as many lines of tests as of source, exercised on every change — because in a product like this, untested code is a risk. And for buyers who genuinely want to read the code, we offer source review under NDA — the same model serious enterprise procurement already uses.
Transparency of process is a real virtue. But it's a means, not the end. The end is a product you can hold accountable — by running its checks yourself, not by counting its contributors. Ask what openness delivers you. Then ask for that, directly.