Same product underneath, forked eighteen months ago for the first client and again twice since. Every bug now gets fixed between one and three times depending on whether I remember.
I want one codebase and eventually a product. What is the actual sequence for doing that while three people are using the running versions daily?
The merge is the easy part and it is not your real problem. Your real problem is that they are retainer clients who can ask you for things, and a product cannot be steered by three people who have your phone number and a standing invoice.
Change the relationship first. Move them onto a fixed plan with a request process that has a queue in it, even a crude one. If you skip that step you will finish the merge and immediately have one codebase with three owners, which is worse than three forks because now every request is a conflict.
Check what you signed before you write any of this code. Service agreements very often contain assignment or work-for-hire language that hands the client ownership of what you built for them, and 'I merged your code into a product I now sell to your competitors' is a conversation you want to have before the merge rather than after.
Usually the fix is small - a short amendment, or a licence back to you for the generic parts. Most clients genuinely do not care. But asking afterwards turns a formality into a negotiation where they hold everything.
Asked all three of mine. Two replied 'sure, fine' in one line. The third wanted something for it and we settled on a discount for six months, which was honestly a fair trade for permanently clean ownership.
Size the budget with hours. Count a normal month: how long do you spend replaying the same fix across forks, plus context-switching between three slightly different codebases, plus the bugs that only exist because a fix landed in two of three. Mine was about 9 hours a month, the merge cost roughly 45 hours spread over a quarter, so it paid back in five months and everything after that was profit. If your number is 2 hours a month, do not do this yet.
One codebase, tenant config table, flags for the small slice that is genuinely different. Everything else is a fork you are afraid to delete.
Did a smaller version of this and the thing I would tell past me is that the first cutover is the scary one and it is over in an hour. I spent two weeks writing a settings file per client, tested it against a copy of their database, then swapped one client over on a Friday morning specifically so I would have the day to fix things. It took forty minutes, one thing broke (a report header still said the old company name), and the client never noticed.
@stipend_sam · 6mo ago · 2 replies
Do not attempt a big merge. Pick the fork you like least, diff it against whichever one you want as the base, and classify every single difference into three buckets: configuration, genuinely different behaviour, or accident. In my experience the split is roughly 70% accident, 25% configuration, 5% genuinely different, and the accidents are things like a hardcoded date format and a renamed column that existed for no reason anyone could remember.
Then: accidents get deleted, configuration becomes rows in a per-tenant settings table, real behaviour goes behind a flag. Move that one client onto the base with their flags on, watch it for two weeks, then do the next one. Took me about four months at a few hours a week and nobody noticed a single cutover.
Reply
Report
@goroutine_gil · 6mo ago
The classification pass is worth doing even if you never merge anything. I found two clients running a 'custom' rounding rule that turned out to be the same rule, written twice, differently, one of which had a bug that had been quietly producing wrong totals for a year.
Reply
Report