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:

• 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.
• Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
• Internal structure is well documented and modular.

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.