the hidden cost of manual code branching for open-source and saas
a long-lived branch separating your open-source and saas editions costs you four ways: every fix is paid twice, the editions drift until merges become projects, releases serialize behind a sync step, and the knowledge of how to reconcile the branches concentrates in one or two people. none of these appear in week one — all of them compound.
cost 1: every fix ships twice (or doesn't)
the day-to-day tax is the double fix: patch main, then cherry-pick to the edition branch, resolve the conflicts, re-review, re-test. under deadline pressure the second half gets deferred, and deferred backports are how a known, fixed bug ships to one of your editions. your users don't experience 'we fixed it on the other branch' as fixed.
cost 2: drift turns merges into projects
divergence compounds because each unresolved difference makes the next merge harder, which makes merging less attractive, which increases divergence. teams describe the end state the same way: a merge that was an hour in january is a sprint in october, and someone proposes 'just rewriting the enterprise bits' — which is how you end up budgeting a quarter for standing still.
costs 3 and 4: serialized releases, concentrated knowledge
release day on a branched product has a critical path through the sync: rebase or merge the edition branch, fix what broke, re-run the matrix. that step is rarely automated because it needs judgment — which is also why it concentrates in whoever did it last. the branch becomes a bus-factor-one system at the exact center of your release process.
- symptom check: prs labeled 'backport', a release checklist step named 'sync', and one engineer everyone pings about the enterprise branch.
- each symptom is reasonable alone; together they're the signature of packaging-by-branch.
the alternative ledger
the flags-in-one-repo model has costs too — flag checks in code, config to manage, discipline to retire stale flags. but they're linear, visible, and shared: a flag check is reviewed once, a config file diffs cleanly, and the matrix is readable by the whole team. you're trading compounding hidden costs for flat explicit ones, which is nearly always the right trade.
tier·dev exists to make the explicit costs smaller still: the tier/flag matrix is the system of record, and the per-tier config your builds read is generated, not hand-edited.
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
- our branch is only six months old — too late already?
- no, six months is early. port the divergent features behind flags one at a time and retire the branch incrementally; most teams clear it in a few sprints without freezing features.
- isn't branch maintenance just part of professional git use?
- short-lived branches, absolutely. the costs here are specific to long-lived divergence between editions — a packaging concern git was never meant to carry.
- how do i make the cost visible to leadership?
- count one month of backport prs, conflict-resolution hours, and sync steps, then annualize. the number is usually persuasive on its own.