Ask and company (mostly Ask) recently created CPAN Ratings (use.perl note with comments). It’s a nifty idea: users can add ratings and their experiences with modules on CPAN. It’s to work around the fact that CPAN is unmediated and enormous. Anyone can post anything, a trend I discussed earlier. It’s easy to bash CPAN because there’s a lot of crap on there, but the community has made the decision that putting fewer barriers to module submission is preferable than bottlenecks and either arbitrary decision makers or strict admission policies.
So the ratings are to help give people, particularly newcomers, an impression of the community's thoughts about a module. It's not as helpful for modules that don't have an alternative -- what else are you going to use? But in the various spaces where there's lots of competition (which isn't really, but that's another story) it can be useful.
Of course, of my four modules (Bundles don't count) two of them are in competitive areas: application servers and object/relational mapping tools. I've only got one review so far and it's not very flattering. In fact the first time I read it I felt embarrassed for myself. But it's mostly fair and just points out the need for a rewrite (it's coming!).
With that I started thinking about negative reviews like this: should you be obligated to first bring these concerns up to the author(s)? [1] Yeah, it's more work, but are you interested in helping or tearing down? Users are an integral part of the opensource community, but many of them see their role strictly as consumers rather than consumers and contributors. For the community to thrive and produce great software users have to do both.
On the other hand developers can be highly sensitive to criticism. For this reason I don't think I've ever emailed someone with "I was looking for a tool in this problemspace and didn't choose yours because of x, y and z." You can be as polite as you want to be but many times you'll still get a response of, "Patches welcome" or something much ruder. Those responses do have their places, but not here.
Even if a user's response is uninformed that can provide useful feedback -- why didn't the user realize this earlier? David's comments about the SPOPS documentation are extremely helpful even if they're nonspecific. That tells me I need to focus on making a separation of the docs between users and developers. Not just a quick-start guide but different documents entirely. And while David's sentence about choosing between properties and undefined method calls is incorrect, (they're just two different interfaces to do the same thing), that points out a serious flaw in the docs as well.
So what's the point? I'm not going to speak for anyone else, but as a developer I need to welcome criticism of my software, even general, nonspecific criticism. If the question is answered in the docs then that's okay -- just point them to the docs without any snide RTFM remarks. (Stas Beckman on the mod_perl list is a good example to follow.)
And I'm also going to be better about emailing module authors and telling them what I like/don't like about their interfaces and the different ways that I use them.
[1] I don't think these thoughts apply in this particular case since, after looking through my old emails, I'd had a brief conversation with David about a bug in SPOPS.