The Open Core Line: State and Collaboration
Open-source the standard where logic is written; charge for stateful and cross-team work
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 93%
The hardest question in open core is where to draw the paid line. dbt Labs uses a crisp, principled cut rather than a feature-by-feature negotiation: the open-source layer is the guts — where a user describes their business logic — because that is the open standard the ecosystem depends on. The proprietary cloud layer takes everything involving state (stateful interactions) and anything cross-team or structural collaboration. The tell that the line is honest: they are happy to lose deals to their own open-source product.
Origin
Julia Schottenstein describing dbt Labs' open-core model, where dbt Core (data transformation, business logic) is open source and dbt Cloud is the proprietary layer she leads as product.
Core principles
- 01The open standard must be the layer the ecosystem builds against — never charge for that
- 02Stateful interactions are a defensible paid boundary
- 03Cross-team and structural collaboration is where organisations, not individuals, pay
- 04Being happy to lose deals to your own open source proves the line is drawn honestly
- 05Free open-source adoption is a distribution engine, not lost revenue
How to run it
- 1
Identify the guts — the layer where the user expresses intent
Find the core artifact your users author: for dbt, it is where you write your business logic for data transformation. This layer must be open source, because it is the standard your ecosystem needs in order to build.
Pro tip This is also your lowest-friction adoption surface — people can get started without ever talking to sales.
Watch out Charging for the standard kills the ecosystem, and the ecosystem is the distribution advantage.
- 2
Reserve state for the proprietary layer
Anything involving stateful interactions — knowing what ran, when, what changed, what is in production — goes into the paid cloud offering. State is what individuals do not need and organisations cannot live without.
- 3
Reserve cross-team and structural collaboration
Anything that coordinates multiple people or imposes organisational structure is proprietary. A single practitioner running locally does not need it; a company with several teams does, and will pay for it.
Pro tip This line naturally scales price with company size without requiring per-seat gymnastics.
- 4
Supercharge, do not cripple
The paid layer's job is to supercharge the development lifecycle and productionisation of the open-source experience — making people much more successful using the open product. It is never a deliberately degraded open version.
Pro tip State the test out loud: are we happy to lose this deal to our own open source? If yes, the line is honest.
Watch out Crippleware in the open layer breaks the ecosystem trust that made the standard adoptable in the first place.
In the wild
Schottenstein's team builds proprietary software for dbt Cloud. When they lose a deal, they most often lose it to dbt open source — and, in her words, they like it that way and are happy to lose to themselves. The open-source layer creates a flywheel: low friction to start, users talk about it and share it inside and across companies, more companies adopt it with low friction, dbt sees a diverse set of use cases across company sizes and industries, which lets them build a truly horizontal company, and they reinvest into the community and product.
→ 20,000 companies use dbt every single week, which attracts partners to build for dbt, share best practices and build workflows — so standardising on dbt unlocks an integrated data ecosystem. The open-source loss column is the top of the paid funnel.
Common mistakes
Drawing the paid line inside the standard
If the layer your ecosystem builds against is paywalled, the ecosystem never forms, and the ecosystem was the distribution advantage that made open core worth doing.
Treating open-source losses as revenue leakage
Losing to your own open source is evidence the free tier is genuinely useful, which is precisely what drives the adoption flywheel that produces paid customers later.
Negotiating the line feature by feature
Without a principled cut like state and cross-team collaboration, every roadmap item becomes a fresh argument about whether it is free, and the line drifts.
Is it for you?
Best for
Dev tools and infrastructure founders deciding what to open-source and what to charge for, especially where an ecosystem standard is the distribution strategy
Not ideal for
Products with no ecosystem or extensibility surface, and closed enterprise tools sold top-down where free adoption creates no distribution
From the transcript
“so what we think about as leaving for our Cloud offering is we deal with state so stateful interactions and also any kind of cross…”
“we want to supercharge that experience with kind of an open core model and build proprietary software that that makes people much more successful using…”
“when we lose a deal we most often lose it to DBT open source and we like it that way we're we're happy to lose…”
“we now get to see this really diverse set of use cases for DBT across company sizes across Industries and it allows us to build…”
From the episode
M&A, competition, pricing, and investing
Julia Schottenstein (dbt Labs)