The only time I ever attempted to engage with the developers of an open source project, the answer was a resounding "NO".
When someone knows what they're on about, it's probably the architecture of our project that doesn't allow us to implement a specific feature; or would make it incredibly difficult to do so. And when you're dealing with even larger projects like Nginx or something, you have to work on it to know if something would work in terms of the project, which is tricky unless you've worked on it extensively.
We've even had a guy who said we shouldn't use LLVM because it's slow (it's not), and he didn't like it. What I'm getting at with this point is that some people suggest ideas that a) change the entire course of the project, or b) are kind of silly and subjective.
TL;DR It's complicated
Also, for me personally, I ignore users: I don't necessarily know if most of them are assholes, but many of them that interact with me are. For example, many have enormous entitlement issues about hand holding around usage, understanding the results the software gives, etc. Just because you managed the arduous feat of getting an email address and typing out a vague 2 line email, that doesn't mean I'm going to spend hours on you when it's clear you couldn't even be arsed to read the (and they do exist!) docs or usage examples. Better yet, people get pissy when you decline to act as their free consultant. And for the vast majority of people that report a bug -- which may or may not so be -- I'd estimate fewer than 10% can produce a competent bug report: version, what happened, what you expected to happen, and shape and structure of the dataset.
I used to be far more helpful but it both takes a lot of time and the weekly raging assholes -- verbal abuse, forceful demands for assistance, complaints that I didn't promptly respond to email -- that contact me really sucked all enthusiasm for working on the project out of me. I'd find a couple hours, make the mistake of reading the project tag in gmail, get upset, and just get discouraged or unmotivated.
The solution was to basically ignore all email unless they're (1) nice, (2) competent, (3) demonstrate effort on their part to find the solution themselves, (4) document the above in the email, and (5) I'm in the mood. Also, in the history of several years of email, I'm confident that fewer than 10 requests offered to pay me. Ask for my consulting rate and you have my attention.
Around the same time, Chromium added a regression where trying to search for text on a long page would fail to work (I can't remember the details, but it was about of equal severity to the Firefox bug.) My bug to them was completely ignored. (It ended up fixed in the next release, but I don't know how-- my bug was never triaged AFAICT and there weren't any dupes AFAICT. Maybe they had a second, private, bug tracker?)
God knows I've disagreed with a lot of Firefox's design decisions recently, but they really did a good job of engaging with their users. At least back in the 4.x timeframe.
My experience, not extensive mind you, is mixed on the matter. The people who make the communication positive gets my attention, even if they so no. Otherwise, I'll still possibly use the project as needed but I don't feel the need to contribute even if I could.
"Contribute or shut up" worded differently may not be an ideal answer but it's an understandable one. Imagine if you were a resource constrained engineer having hundreds of queries and emails a day about certain things users want and then not only have that feature not be something of interest to anyone but that user but also have it be something that isn't even on your road map.
Technology that's general purpose enough (in our case machin e learning/scientific computing) will give you this.
There's a huge delta between say: a resource constrained but heavily used project and a javascript lib that only provides a slightly better basic widget.
It's no excuse for OSS devs to be rude but I hope you can understand what it looks like from our side a bit.
Essentially even when you're asking to contribute a patch, you're requesting that someone maintain some code you wrote for an indefinite span of time.
My experience has been that it's much more productive to say "I can't merge that patch into the core, but here is how it would be implemented as a plugin" and ensure your plugin interface is powerful and stable enough to allow people to do what they want.
That, of course, does not mean we don't say "no" or "not just yet".
Even on my own personal projects I tend to say "not yet" more often than not. Sometimes the feature requested makes sense, but the suggested implementation requires some thoughtful design. I've painted myself into corners far too many times before to fall into that kind of trap. As the Zen of Python says, "never" is often preferable to "right now".