[kolpa]

People often forget "copy-on-write". Coupling doesn't have to be permanent. If refactor to create a sahred component, and then you want to modify a shared component to help one client, you can fork it -- it's not worse than simply not having created the shared component in the first place.

[Buttons840]

In my experience people will most likely just hack the shared component by adding awful arbitrary if-statements or other such hacks, rather than fork the shared component. This is the path of least resistance. Once this happens a few times that shared component begins to be seen as a central component and is quite a complicated mess.

[marcosdumay]

Well, after enough settings are added, take a look at your components, and define a clearer 2.0 version of them.

When systems need to use newer functionality, port them to the new components.

I've had a mixed experience with this, but at some point you get the API right, and then it works.

[tedunangst]

People tend not to do this when the original already handles many cases. If half the copied code is dead on arrival, it tends not to be copied.

[usrusr]

But often the fork happens too late, after the first few differences have been creatively shoehorned into the shared code. The resulting mess then tends to live on twice after the fork.

In the end, almost every conceptual way to slice up software can be viable if you are good at whatever you do, and terrible of not.