Recently, I read a similarly titled blog post:
The title and part of the content resonated with me. Less because of the business cases presented, but much more coming from an architectural / code design perspective.
If you want to focus on a specific scope of a library, you have to say no to many feature requests, even if they are generally speaking good ideas. Sometimes even if it probably will benefit a lot of users. For one it would soften the scope of said library and thus making it harder to understand from the outside. You may no longer be able to rely on your intuitive understanding of the boundaries, because the newly added feature has blurred that boundary. Additionally, once the boundary has been softened, you’re signaling that even more out-of-scope features could potentially be accepted, thus leading to an even harder battle to fight.
Saying no is hard, because people often won’t understand that their feature lies outside of the defined scope, or don’t want to accept that. So you either end up having to defend your position with technical arguments or deal with released emotions following the rejection. Balancing this upfront to show appreciation for the work to emotionally support them, while also being technical enough to be convincing is a hard thing to get right.