The hardest part for me is actually saying no, because it's never that black/white. I might work on it later because I want to help. I might stumble into a use case where I now need this feature and then do it. Someone might make a PR. But each "open ended issue" is still bandwidth, brain capacity, effort.
However, you are correct about that "using bandwidth" thing.
If we publish something, then I think it behooves us to make it clear what users/adopters of our work can expect from us.
I tend to use the MIT license ("You can do what you want, but don't come crying to me."). I also make every effort to make the project as understandable and well-documented as possible. I appreciate feedback, and apply it, if I deem it fitting.
I have only had one project "go viral," so to speak. It's a fairly big deal, nowadays. It was taken over by a new team, and they had very little trouble getting up to speed on it, because of the quality of the code and documentation. Thousands of folks around the world, use it every day. It's become a fairly vital infrastructure component, for a certain demographic.
The best thing I ever did, with that project, was get the hell away from it, as soon as I was confident the new team was good.
The “calm and respectful” part is important. I can be right ornery, and learned, the hard way, that OS projects are more fragile than commercial ones, so enemies can do a lot of damage.
I have written software for a fairly … pithy … demographic, and have dealt with feedback that would make many FOSS authors hide under their standing desks, whimpering.