A simple "negative module recommendation" would be too simplistic to be useful, I think. It would be much more valuable to know why you don't care for a module.

The problem is that nontrivial modules often need to balance multiple competing objectives: speed, scalability, robustness, battle hardening, simplicity of API, debuggability, flexibility, etc. (I'm intentionally only listing dimensions that have caused me to reject a module.) As a result, it's not always about good vs bad; sometimes, it's a matter of matching a module to your situation.

So, for example, I write code for a variety of situations:

• production code that I and others will be re-reading and maintaining for some time, some of which is for occasional tasks and some of which will be run repeatedly with huge amounts of aggregate data
• support code that somebody else might read but mostly will be behind the scenes and maintained only by me
• one-off programs to do simple maintenance or analysis operations on some short-lived input
• experimental programs just to see if some idea or other will pan out

That is certainly not an exhaustive list of scenarios, but it's still representative enough to demonstrate that a module that is perfect for one situation might be completely unsuitable for another. For example, there's nothing wrong with using regular expressions to parse HTML or XML if you're only using it on files with known formatting, or if you'll be able to figure out immediately if it gets it wrong. If another module uses a more robust parsing mechanism, then of course you would use that module instead -- unless it were slower, more complicated to use, or worse in some other way that mattered to you more for the task at hand.

Which is not to say that I disagree with the whole idea of negative ratings, just that a blanket "this module sucks" is not likely to be as helpful as some additional information. Alternatives would be:

• Rate the module on a whole range of dimensions
• Record negative ratings, but require the rater to submit the reason or reasons
• Restrict negative ratings to suggestions of alternatives, preferably with reasons why each alternative is superior

In some cases, a blanket negative rating is appropriate, if there are better modules out there in all dimensions, or if the module has some fundamental flaw (eg incorrect behavior on common input) that would cause you to recommend never using the module in any circumstance.