The Pitfalls of 'Fork Yourself' in FOSS
Whether it's a feature suggestion or a pull request optimizing some code path you are very likely to see response similar to "nah, thanks, it's fine as is". This is often followed by "if you don't like it you are free to create a fork". And don't get me wrong, community contributions are liabilities the main maintainers team will have to keep supporting in the future. However, rejecting input without discussion, understanding the contributor's reasoning, or explaining your own perspective is unhelpful. Instead, clearly state if the suggested change doesn't fit your current priorities. Leaving the issue open for other users to see can encourage their support and potentially shift your focus if there's enough interest. If the contributor follows this advice and creates a fork, they will then have to keep rebasing against the main project to receive bug fixes and other improvements. Furthermore, that fork is likely not easily discoverable by other users. This can lead to the same issue being raised multiple times within the main project. It's not an easy problem to tackle. We certainly can't blindly accept every feature request and pull request. However, for projects with a significant user base, considering the implications of this "fork fiesta" is crucial.