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

In a situation with this constraint The 2 groups are from differents organization. there can be a point where the DRY principle hinders your teams more than they will benefit from it. When one team needs an urgent change for their project, but for the other team this change is too much effort or their project has other priorities, this can too easily lead to delays and conflicts. Hence, copying certain repositories and having each team maintaining their own fork should be definitely considered as an option - something you try to avoid for a single team. But with the resources of two teams it can be less effort to let each team maintain their own version than trying to sync the development of two different projects artificially. Of course, that does not mean you should fork every single repo. If you can establish an ownership for certain services, similar to what Hans-Martin Mosner wrote, you may keep shared services existing in only one version line, where all customization is done by a small, maintainable amount of parameters and configuration options. The ownership might be placed at a sub-team with developers from both organizations, at least for the period while the collaboration lasts. Unfortunately, services which depend on the structure of domain objects are IMHO not good candidates for staying shared when this structure differs from one project to another. In my experience, services which are independent from that structure have better chances to be developed in an unforked manner. In the end, only you can decide which services to fork and which one not, and which ones may be redesigned to make them reusable across different projects.