Open Core for Governance: Why Trust Must Be Inspectable

If your governance tool asks you to trust it, it has already failed. Governance exists because trust alone is insufficient. The tool that provides governance should be held to the same standard.

That principle drives every decision about what is open source and what is proprietary in GuardSpine. The split is not arbitrary. It follows a single rule: trust must be inspectable. Convenience can be private.

The Split

GuardSpine has eight open-source packages and five proprietary components. Here is exactly what lives where and why.

Open source (Apache 2.0):

• guardspine-spec — the evidence bundle schema definition
• guardspine-kernel — TypeScript implementation of the sealing engine
• guardspine-kernel-py — Python implementation of the sealing engine
• guardspine-verify — offline verification CLI
• codeguard-action — GitHub Action for governed PRs
• guardspine-adapter-webhook — inbound event handling
• guardspine-local-council — local AI review via Ollama
• n8n-nodes-guardspine — workflow automation nodes

Proprietary:

• Enterprise dashboard and analytics
• Team management and RBAC
• Hosted multi-model council service
• Compliance report generation
• SAML/SSO integration

Read those lists again. Notice the pattern?

Every component that creates, verifies, or validates trust is open source. The schema that defines what evidence looks like. The engine that seals it. The tool that verifies it. The action that automates it. All inspectable. All auditable. All forkable.

Every component that makes the system easier to operate at scale is proprietary. Dashboards. Team management. Report formatting. Single sign-on. These are convenience features. They do not affect whether the evidence is trustworthy — they affect whether managing the system is pleasant.

Why This Matters

A governance vendor that asks you to trust a black box is selling you a contradiction.

If I ship you a proprietary evidence bundle format, you have to trust that my sealing algorithm works correctly. You cannot verify it. You cannot audit it. You cannot have your security team review it. You are taking my word for it — which is exactly the problem governance is supposed to solve.

By making the spec, kernels, and verification tool open source, I eliminate that trust dependency. Your security team can read every line of code that touches your evidence. They can verify that SHA-256 is computed correctly. They can confirm that the Merkle chain is constructed properly. They can audit the signature validation logic. They do not need to trust me. They can verify the math themselves.

This is not marketing generosity. This is a structural requirement of building governance software. Any governance product that hides its trust mechanisms behind proprietary code is asking you to accept a trust dependency to solve your trust problem. The logic does not hold.

The Snyk Model

GuardSpine’s open-core approach is not novel. It follows a pattern proven by companies like Snyk and HashiCorp that built massive businesses on open-source foundations.

Snyk’s CLI and vulnerability database are open. The scanning engine you can inspect. The enterprise platform with dashboards, reporting, RBAC, and integrations is where the revenue comes from. Developers trust Snyk because they can see how scanning works. Enterprises pay Snyk because managing scanning at scale requires tooling that goes beyond the CLI.

HashiCorp (before the license change) followed the same pattern with Terraform. The core engine was open source. The state management, collaboration features, and policy engine (Sentinel) were proprietary. Operators trusted Terraform because the engine was transparent. Organizations paid because managing Terraform across fifty teams requires features the CLI does not provide.

GuardSpine applies this exact model to governance. The trust components are the foundation — open, inspectable, free. The convenience components are the business — proprietary, valuable, worth paying for.

What Prevents Vendor Lock-In

A common fear with open-core is that the vendor gradually moves critical features from open to proprietary, creating lock-in through erosion. I have seen this happen. It is a legitimate concern.

GuardSpine has structural protection against this: the evidence bundle format is the product.

If you use GuardSpine and later decide to leave, your evidence bundles remain valid. They are JSON files with a documented schema. The verification tool is open source and will continue to work. Your audit trail is not trapped in a proprietary database — it is a collection of self-contained, self-verifiable files.

You can build your own dashboard on top of those bundles. You can write your own report generator. You can fork the kernel and build your own sealing pipeline. The open-source components are not a demo — they are production software. codeguard-action has 737 tests. The kernels implement the full spec. The verification CLI handles every validation step.

The proprietary components save you time. They do not hold your data hostage.

The Revenue Question

“If the core is free, how do you make money?”

The same way Snyk makes $300M+ in ARR: enterprises pay for the convenience layer.

A startup with five developers can run codeguard-action in their CI pipeline, generate evidence bundles, and verify them with the CLI. They pay nothing. They get governed PRs. They have audit-ready evidence. The trust layer works fully without paying us a dollar.

An enterprise with five hundred developers across thirty repositories needs more. They need a dashboard showing risk trends across the organization. They need RBAC so security engineers can configure policies that developers cannot override. They need SAML integration so access management flows through their existing identity provider. They need compliance reports formatted for their specific regulatory framework.

That is the wedge. The trust layer gets adoption. The convenience layer gets revenue. The trust layer must remain open because governance requires inspectability. The convenience layer can be proprietary because dashboards do not require the same standard of proof.

The Local-First Option

One component deserves special attention: guardspine-local-council. This is the open-source package that lets you run multi-model AI review entirely on your own infrastructure using Ollama.

For teams that cannot send code to external APIs — defense contractors, healthcare systems handling PHI, financial institutions with data residency requirements — the local council is not a convenience feature. It is a trust requirement. Code that cannot leave the building needs a reviewer that lives in the building.

Making the local council open source serves the same principle as the rest of the stack: if you need to verify that your code never left your network, you should be able to read the code that processes it. A proprietary local review tool that promises “your code stays local” asks you to trust that promise. An open-source one lets you verify it.

The Practical Test

Here is how I evaluate whether an open-core split is honest: can a team use the open-source components in production, for real workloads, without hitting artificial limitations designed to force an upgrade?

With GuardSpine, the answer is yes. codeguard-action works on unlimited repositories. The kernels seal unlimited bundles. The verification CLI validates any bundle. There is no “community edition” crippled at ten repos or fifty PRs per month. The open-source tools are complete.

When you outgrow them — when you need dashboards, team management, compliance reports, SSO — you upgrade because the proprietary features save you time, not because the free tools stopped working.

That is the only version of open-core that builds lasting trust. And for a governance product, trust is not optional.

If you want to evaluate the open-source stack or discuss the enterprise tier, book a conversation at cal.com/davidyoussef/guardspine. I will walk you through both sides of the split and help you figure out which one fits your team.