David Chisnall (*Now with 50% more sarcasm!*) on Nostr: I don’t object to ‘if you don’t like it, fork it’ as a response as long as ...

I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:<li>External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.</li><li>Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.</li><li>Internal structure is well documented and modular.</li>

This leads to small projects with loose coupling that can be *done* (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).

A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.