Should the private package be a submodule or a registry dependency?

A registry dependency (private npm/PyPI/etc.) ages better than a submodule — versioned, cacheable, and invisible to open-source builds that don't request it.

How do we review paid features 'in public' without leaking roadmap?

Merge dark with neutral naming, and keep marketing-sensitive copy in the private package or behind launch-day config. The code being visible early is usually a non-event in practice.

Does trunk-based development require feature flags?

Effectively yes for anything unfinished or edition-specific — flags are what make merging early safe. Tier flags are the same mechanism pointed at packaging.

Git workflows for open-core businesses: a new perspective

the short answer

The open-core git workflow that holds up is trunk-based development on the public repo, a thin private package for genuinely proprietary modules, and per-tier flag config as the packaging layer. Branches stay short-lived and feature-scoped; nothing about your pricing model lives in git topology.

Git answers 'what changed, when, by whom'. Open-core businesses keep asking it a second question — 'who is this feature for?' — and encoding the answer in branches. The new perspective is a clean separation of concerns: git owns history, a config layer owns packaging, and the two never compete.

Once you see edition branches as a category error, the rest of the workflow follows. It's trunk-based development on the public repo, a thin private package for the genuinely proprietary bits, and per-tier flag config as the packaging layer.

~30%of Fortune 100 companies run open source program offices — open-core vendors increasingly sell to buyers who will read the public repo before they buy.Source: GitHub Octoverse Report, 2022

The day-to-day loop

The working agreement fits on an index card. All work happens in short-lived feature branches off the public main; nothing lives unmerged past a few days. Paid features merge to main behind a flag, defaulted off — code review happens in public, where your contributors are.

The rare proprietary module lives in a private package main imports optionally; its activation is still a flag. Per-tier flag config (tiers.json) is committed and reviewed like code; flipping saas-on for a feature is a one-line PR. And CI builds every tier from every main commit, so 'does the community edition still build?' is never a question.

What changes for contributors and for the business

Contributors get the real codebase, including the honest shape of paid gates — a flag check reads as a fact, not a betrayal. Maintainers stop maintaining a shadow edition. And the business gains an artifact most open-core companies lack: a single reviewable file that states, for every tier, exactly what's enabled. That file answers due-diligence questions, support escalations, and roadmap debates alike.

Companies that have walked the opposite road validate the direction: GitLab merged its community and enterprise codebases back together after years apart, citing development drag. Starting unified is cheaper than re-unifying.

Where tier·dev sits in the workflow

tier·dev is the packaging layer's UI: connect the repo, define tiers, manage flags with descriptions and per-tier values, and generate the config file your CI consumes. Git stays pure history; the matrix stays the single answer to 'who gets what'.

frequently asked

Should the private package be a submodule or a registry dependency?: A registry dependency (private npm/PyPI/etc.) ages better than a submodule — versioned, cacheable, and invisible to open-source builds that don't request it.
How do we review paid features 'in public' without leaking roadmap?: Merge dark with neutral naming, and keep marketing-sensitive copy in the private package or behind launch-day config. The code being visible early is usually a non-event in practice.
Does trunk-based development require feature flags?: Effectively yes for anything unfinished or edition-specific — flags are what make merging early safe. Tier flags are the same mechanism pointed at packaging.

Published June 5, 2026 · Last updated June 16, 2026