I'll just take the points in order, easier that way.
1) I wasn't even thinking of smaller projects, but that's a good point. And that's when it's necessary, if the people are persistent, to make it clear what the purpose of the project is and what their desire is and why they don't coincide (and that's a good time to point out, THEN, that it's a volunteer workforce and how much would be required to make the requested changes). If they're difficult, that's when it's time to stop ignoring them. This can also, in some cases, be a chance to make a few dollars by making the changes -- but usually the complainers aren't willing to pony up the cash for what they need.
2) Yes, people bitch - but there are a few points here. First, is your goal to get the projet out there for users? If it's Open/Libre Office, then it is. If you're just writing the program for yourself (which could be one or more developers) and releasing it, thinking, "I find it useful, so others might, too," then that's a case where you may want bug reports and feedback from developers, but not want to create a user community, since that's not at all the purpose of the project.
Second, if the goal is to get users to use it, as with KDE in general, and, in this case, Amarok in particular, then someone on the development team *must* keep in touch with the feelings of users. In this case, I've seen many people bitching over the new GUI in 2.0 and, from what I saw, the new GUI wasn't tested for user feedback. That's a prime example of what I'm talking about. It's a project with a goal of gaining users, but the crew totally ignored the needs of the users. It is common sense that a major GUI change will create a major reaction with users, so it's important to release what you can ahead of time to see how people feel about it compared to the old GUI. I have watched discussions over Amarok, and have seen very few positive comments when it hit 2.0. While it's true haters are more likely to speak up than those who are satisfied, that was still a missed opportunity from the Amarok developers to figure out what end users wanted.
I know it's a pain to maintain two GUIs, but they probably should have given serious consideration to doing that - or to reverting.
Third, yes, I know what hearing all the bitching is like. I used to teach special needs kids, which means nothing is enough for parents and everything is too much from the administration's point of view (where they want to maximize resources) and I write and, as I mentioned, retired from a software company. People love to bitch and some will be helpful when they realize they're listened to and some won't. But the bottom line is if you want people using the project, there's no choice. You have to listen to the "pulse of the public." This can be done through polling or a number of other ways, but if you're trying to market, in any way, then not listening to users is like target shooting with a blindfold.
3) It sounds like your plugin is either for use within an organization or that it has a price on it - in which case one major measure of user satisfaction is if they keep buying it.
4) Overall, and many developers hate it when I bring this up, developers are great engineers, but they're not human engineers. I love developers and the way they think and what it's like being in a room with them, but being the interface between users and a developer team is a special skill, and it's one very few developers have. The problems that I've seen (and this is one of them) is that developers know they're intelligent and think they can do it all, and often do see the user as less intelligent. This leads to them thinking if something is wrong, it *must* be the user.
I spent years working in residential treatment and teaching (before I started my business) and had to learn to deal with all different types of personalities and people with all different kinds of mental strengths in different areas. After leaving there and working with developers, I found that this is something most don't get. They think there's a right and wrong in things like a GUI and since they used logic, they're right. And often the problem is there are many, MANY layers of logic they don't understand, such as learning styles and working styles that mean many people who don't think like a developer - and developers think in several unique styles and just don't understand that most people don't and cannot think in that way.
This leads to different needs and different viewpoints and many times a developer can't understand that users need things done differently than the developers want to do things. This is one reason why Facebook, a company run by developers, while being used by many people, ranks as low, in customer satisfaction as public utilities and monopolies and other companies that people hate. The only reason they have the market is there's no real alternative.