Answer to: How to organize multiple customized projects around a shared and evolving codebase?

Each of those dozens of repos should have clear ownership: owned by Team-A, or B, or shared. If you own it, then you need only coordinate within your own team. recommendations on how to organize collaboration Sharing code is good: we get new feature benefits. Sharing code is bad: your developer's edit can crash my microservice. In the latter case, we want edits from Team-A to anticipate objections from Team-B, to avoid stepping on B's toes. One way to accomplish that is by ensuring each PR pull request code review needs sign-off by both A and B developers. A better / faster / supplementary approach is to ensure that everyone runs automated unit tests written by A folks and also tests written by B folks. Since it's automated, the communication turnaround is much faster than the PR process, which also has a role to play. It's likely that some of the tests will appear in A-owned or B-owned repositories, and then the editing team will read / execute those "foreign" test suites. This implies that, in addition to the usual SemVer 1.2.3 version numbering, you will need "rc1", "rc2" release candidate versions which foreign repos can easily pull in. This should give a developer on the editing team some confidence in their proposed edits, prior to inviting members of the other team to review and approve their edits.