how to manage open-source and saas codebases without headaches
the short answer: don't split the codebase. keep one repository, name your offerings as tiers (open-source, saas), express every paid difference as a feature flag with per-tier values, and generate the config each build reads. the moment you fork or maintain an enterprise branch, every future fix costs you twice.
why two codebases happen by accident
nobody plans to maintain two codebases. it starts with one private commit — a billing integration, a pro dashboard — that can't live in the public repo. a private fork appears 'temporarily'. six months later the fork has its own ci, its own bugfixes, and a merge from upstream is a half-day of conflict surgery.
the structural mistake is encoding a business question (who gets this feature?) in a version-control mechanism (which branch is this commit on?). git is brilliant at history and terrible at product packaging. branches answer 'what changed', not 'who is this for'.
the single-repo workflow, step by step
the workflow that scales is boring on purpose: one repo, explicit tiers, flags as data.
- define your tiers as names, not branches — open-source, saas, pro. they describe distributions of the same code.
- for every feature that differs, create a boolean flag (PRO_DASHBOARD_ENABLED) with a default and per-tier overrides.
- generate one config file per tier — json or yaml — and commit it. the build for each tier reads its own block.
- gate code paths with a one-line check. the open-source build hits the same line and simply resolves to false.
- review flag changes like code: the config diff is the release note for what each tier gains or loses.
what about code that truly can't be public?
most 'saas-only' code can ship dark — present in the repo, disabled by flag. for the small remainder (proprietary algorithms, partner integrations under nda), keep a thin private package that the saas build depends on, behind the same flag. the open-source build never imports it. that's one private module, not a private fork of the whole product.
teams that adopt this split report a calmer cadence: contributors work against the real codebase, the saas deploy is just a flag-resolved build of main, and 'which version has that fix' stops being a question — every version has it.
where tier·dev fits
tier·dev is the bookkeeping layer for exactly this workflow: connect the github repo, define the tiers, manage the flags in a matrix, and copy generated json/yaml/code snippets into the repo. no runtime sdk, no vendor call in your hot path — the config is yours, committed in git like everything else.
see this on your own repo
tier·dev turns the open-source / saas difference into per-tier feature flags — one repo, generated config, no sdk.
faq
- should i ever fork for an enterprise edition?
- almost never. a fork doubles maintenance forever in exchange for short-term convenience. a private add-on package plus per-tier flags covers the genuine secrecy cases with a fraction of the cost.
- do feature flags slow the open-source build down?
- no — values resolve from a committed config file at build or boot time. there's no network call and no third-party dependency in the open-source distribution.
- how do i stop contributors enabling paid features?
- you don't need to — and that honesty is a feature. anyone can flip a local flag; what they can't do is use your hosted infrastructure, support, and updates. open-core companies have shipped this way for years.