aayars has asked for the wisdom of the Perl Monks concerning the following question:


My question is entirely political in nature.

I recently posted a package to the CPAN, which was met with very harsh reviews due mainly to its use of source filters. Although I feel I've addressed the issues raised by reviewers, the negative feedback remains. If I were looking for something on CPAN, I'd probably skip over my own package because of its low rating. I'd give it at least a 3, but I'm clearly biased.

I'm wondering how others have dealt with similar situations? cpanratings allows you to post a comment as an author, and I did so, stating I had made several changes. One person was kind enough to retract their review, but I don't think the other person is going to do the same.

Should I try to publicize my project a bit and try to get more reviews? I don't think there will be many more reviews incoming, since people are probably passing over it now. I would contact the reviewer but I don't see that he's an author of any modules, and I don't know how to get a hold of him.

Not mentioning the project by name, but if you're interested, I'm posting this as my CPAN authors name-- look for the project with a 1-star rating. Always looking for feedback.


Replies are listed 'Best First'.
Re: Dealing with CPAN reviews
by moritz (Cardinal) on Aug 21, 2009 at 08:33 UTC

    First of all aayers: thank you for contributing to CPAN, and please don't let anybody discourage you.

    As the second point I'd like to thank you again for reacting on feedback, even if some of that wasn't formulated very friendly at all. That's not something you can take for granted.

    I think you did well in responding on the review page.

    On the ratings page of one of my modules I found that some ratings disappeared after a while (and after releasing a few new versions), so I don't think it's a doom hanging over your project for long.

    Should I try to publicize my project a bit and try to get more reviews?

    Yes. I recommend starting a small series of blog posts. You can join the Perl Iron Man, the RSS aggregator seems to have lots of readers in the Perl community (at least I got much more feedback on my posts after I joined it), and it's also worthy to get your blog listed on

    Maybe you'll even find some new contributors to your project that way.

    Perl 6 projects - links to (nearly) everything that is Perl 6.
Re: Dealing with CPAN reviews
by cdarke (Prior) on Aug 21, 2009 at 07:40 UTC
    At least you got some reviews...

    I have been fortunate in getting a number of emails from users of my modules. These have always been constructive and are often requests for enhancements, which generally I am happy to implement.

    So check your email regularly (is it me, or has the spam decreased recently?) and always respond. And <insert your favorite quote about critical reviews>.

    Putting your own code out into the wild is a bit like watching your child go to school on the first day. At least modules don't grow into teenagers, or do they....?
      I've heard anecdotal evidence that spam has decreased. If so, it is likely because of the economy. After all spamming is a business.

      We'll get a more definitive answer about what August was like when the State of Spam report comes out next month. Looking at their graph it looks like there was a decline in July.

        I've heard anecdotal evidence that spam has decreased. If so, it is likely because of the economy. After all spamming is a business.
        I think more precisely, spamming is a double-con... the spam business cons con-artists into thinking they can make money by using spam to con some tiny but significant percentage of the public... a lot of the spam I see is clearly targeted at old people ("Top of the morning to you!") who are new to the net but not wised-up yet. I have my doubts that there are a lot of people like this left.

Re: Dealing with CPAN reviews
by andreas1234567 (Vicar) on Aug 21, 2009 at 09:42 UTC
    My experience with CPAN is very much like cdarke's: No ratings, but some inquiries, requests and patches on email, all friendly and helpful. Don't let one bad review ruin your day. There's a lot of people out there that appreciate what you do. For that you get eternal happiness.
    No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
Re: Dealing with CPAN reviews
by Herkum (Parson) on Aug 21, 2009 at 15:13 UTC

    This is one feature that I wished that they removed from CPAN. Reviews don't generate enough traffic to be meaningful and when problems with a module are fixed or addressed ratings are not changed to reflect this.

    A good example is Module::Build, it has a rating of 3. It is currently on revision 0.34 and got reviews as early as revision 0.19( which was in 2003). A person complained about the lack of PREFIX support and gave it a 1 star in 2005! I am sure over the course of 4 years that issue has been addressed but that rating is never going to change.

    Ratings for CPAN modules are more like credit scores but they don't go away after 7 years. They just have no relation to reality, so don't worry about.

Re: Dealing with CPAN reviews
by toolic (Bishop) on Aug 21, 2009 at 13:36 UTC
    I can think of a couple ways to counteract the negative review. Firstly, create a list of your module's strengths. Since you only first released it a few months ago (according to the "Changes" file), you must have done some research which led you to believe there are some advantages over other similar modules, such as:
    • Unique methods/functions
    • Convenient methods/functions
    • Optimized for speed/memory/whatever
    • Portable across unix/windoze

    You should mention some of these advantages in the module's POD, instead of down-playing it, as you are currently doing.

    Secondly, consider promoting your code by participating more in on-line forums, such as PerlMonks, if you are not already doing so. For example, answer questions posed by Seekers of Perl Wisdom, and offer your code as a potential solution, where applicable. Demonstrate to the public that your code is indeed valuable by providing concrete examples to solve a problem. I learned about many of the CPAN modules I use today because I saw others posting code here at the Monastery, not by reading a CPAN review.

    By the way, I have seen other authors post reviews of their own modules when they release new versions. It is a good approach.

Re: Dealing with CPAN reviews
by scorpio17 (Canon) on Aug 21, 2009 at 14:01 UTC

    There is a module that I've used for a long time, and I've never had any problems. For a while, it had no reviews. Then one day while checking the docs, I saw that someone had given it a pretty low score, and I was shocked.

    I think you have to keep in mind that when a module does NOT do what someone wants, they complain loudly, but when it works great, no one says anything. It's like working the IT help desk - you only hear from people when they have a problem, when something's broke, etc. No one ever calls up just to say, "thanks! great job!" (although maybe they should!).

    Unfortunately, this makes the ratings system kind of worthless....

    But it also means that when I go looking for modules, I don't care what anyone else thinks - I try it and form my own opinion. All I really care about is if it works for ME. Hopefully others will feel the same.

      Unfortunately, this makes the ratings system kind of worthless....

      I agree with you: negative feedback is easier to give. But I don't think it's worthless. I find it the most valuable.

      When I shop at Amazon for example, I only read the negative reviews. The positive reviews are usually not useful; there is no accounting for taste and passion makes things sound better. Positive reviews tend to be full of emotional, fluffy language which has little specific content but can get you excited to buy something anyway.

      The negative reviews are the most instructive because they tend to be either 1) ill-informed, ignorant, mean-spirited, or 2) cogent and specific with personal/subjective preference often discussed. From either of those I can usually tell more about what I'd think of a product than from the majority of positive reviews.

      There aren't typically enough reviews on CPAN ratings to apply this strategy though. :( Works best with a handful of bad reviews to compare.

Re: Dealing with CPAN reviews
by Porculus (Hermit) on Aug 21, 2009 at 20:47 UTC

    To be honest, I wouldn't worry about it that much.

    I for one never even see CPAN ratings. My interaction with CPAN is all done on the command line.

    If you want people like me to consider your module, the things you should be worrying about are, most important first:

    1. The name. If I can't guess what your module does from its name, I probably won't even glance at it. (Cute names like "Moose" can work, but only if you put the effort into publicity.)
    2. The README. This is the first thing I look at once I've found a promising name. It must contain a clear statement of what the module has to offer. If it doesn't catch my interest, I move on.
    3. The license. There are some nasty surprises on CPAN -- complete modules that can only be used for non-profit purposes, for example. I need to be able to find the license quickly, and it needs to be a standard one -- preferably "same terms as Perl itself".
    4. The POD. If the README looks promising, I read the module's documentation. I'm looking particularly for clear usage examples.
    5. If the documentation doesn't quite convince me that I've found a quality module, but it looks like it might do what I need, I look at the code itself to see whether it looks well written.

    Arbitrary scores from random reviewers don't even figure. I probably don't know those people, and I have no way of judging whether they're qualified to review your code. Why would I care whether they gave it one star or five? Forget Web 2.0-y fluff; it's the meat of the module that matters.

Re: Dealing with CPAN reviews
by ikegami (Patriarch) on Aug 21, 2009 at 17:32 UTC
    I can't help you with the issue at hand, but I want to point out an error that the following is wrong:

    ctime is the Unix timestamp representing the object's creation time. OP sets this when saving an object for the first time.

    "c" stands for "change", not "creation". It's the time of the last status change

    The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.).

    $ touch a $ perl -MFile::stat -wle'print "".localtime( stat("a")->ctime )' Fri Aug 21 13:31:40 2009 $ sleep 2 $ perl -MFile::stat -wle'print "".localtime( stat("a")->ctime )' Fri Aug 21 13:31:40 2009 $ chmod go= a $ perl -MFile::stat -wle'print "".localtime( stat("a")->ctime )' Fri Aug 21 13:32:25 2009

    Also, the module name is awful, and I have no idea what the module does after reading the Description and Synopsis.

Re: Dealing with CPAN reviews
by clp (Friar) on Aug 21, 2009 at 16:43 UTC
    Thanks for contributing to CPAN, and for asking this question on PerlMonks. I've learned about a few resources from the other responses.

    Here are some factors I consider when looking at CPAN.

    I look at reviews before choosing a module, and appreciate intelligent comments and responses that help me to choose among several different modules. As stated elsewhere, the review section is often empty.

    Your CPAN module includes a significant amount of code and documentation - docs are a plus.

    You have been updating it recently, several times in the last few weeks - recent activity is a plus.

    You responded to the negative review with a specific comment to one criticism. However, you did not address the second criticism (many dependencies). Your INSTALL note mentions the fact that there are many dependencies. Perhaps you should also mention it in your review comment, so anyone reading the reviews will see the issues raised and your responses.

    Another idea is to provide a link from your review comment to the section in your documentation that describes your use of other modules and why you did that (rather than writing a long and detailed review comment that merely repeats data listed elsewhere in the package documentation).

      Man, I gotta tell ya.. If I looked for review before choosing a module.. I would have missed out on a TON of amazing stuff!!! Most important thing for me is the documentation. If it sucks, if it's porrly documented, I make a vommity face and keep looking.. Unfortunately there are some old dinosaurs out there that are so so documented.. like PDF::API2.. which I think is... uck.. just look at the docs.. so sad.. this is such a nice module... :-)
Re: Dealing with CPAN reviews
by Burak (Chaplain) on Aug 21, 2009 at 14:20 UTC
    Oh, there are several issues for the ratings system. For example: if you happen to have a module that some cargo cult follower does not like because the framework he/she uses dropped using it, you'll get a nonsense review with a single star rating. Or maybe the person is just an idiot and downvotes your module because does not like you. I'm glad to not have any of these idiots to rate my modules (yet!). However, if this is the case, then the other sane people will usually rate your module and with multiple stars :)

    On the other hand, as people mentioned before, if you get a valid criticism you can try to fix the issue to resolve the reviewers concerns. I see that one of the reviewers deleted the review for example. As for the open source world, you need to wait for a response. I got a response from one of my bug reports in RT after 3 years for example :)
Re: Dealing with CPAN reviews
by whakka (Hermit) on Aug 21, 2009 at 17:16 UTC
    May I suggest:

    If you (not OP - you!) care about this issue the best thing you can do *right now* is go review at least 5 modules you use regularly or are of particular importance to one of your projects. At least give a rating and a paragraph explaining it, it doesn't have to be extremely detailed.

    The fact is ratings are displayed prominently on search.cpan regardless of how many have rated, or how sensible or old it is. There's also no system in place to weight ratings based on the % of people who find it useful. The best thing to do is up the review counts and drown out the "noise" of non-sensible/old reviews.

Re: Dealing with CPAN reviews
by Anonymous Monk on Aug 21, 2009 at 06:48 UTC

    As I've never written a CPAN module I cannot give you any advice on the "process", however, as a recent convert to perl and an avid supporter I'd like to offer my experience as a CPAN hunter....

    If I search for a module the MOST important thing in determining between two modules is the last update / version. The one with the latest updates usually gets the first try. Call me fickle, but there is something that draws me towards actively maintained modules.

    Also, as I tend to code for Winblows so having an Activestate PPMx clinches it for me.

    Hope this helps.
      I agree with Anonymous monk, if theres a PPM included I'll usually give it a very good try - even it that means it has a few teething problems getting it to do what I want. And I also look at a modules release history.

      I think its a bit unfortunate that the CPAN rating system hasn't had the usage it was meant to get. I'd say of all the people using CPAN modules, less than 1% of them have made a review on a module. As a result, I usually find myself trolling the monestary when I'm looking for reviews and commments on a module.

      @aayars > stick with it, true genius often gets critised unfairly...

      So one should release an update every few months consisting of a change to Changes:

      2009-08-21 — Still works find

      Seriously though, a module that has gone through numerous updates even if none of them are particularly recent is also a good sign.

Re: Dealing with CPAN reviews
by aayars (Acolyte) on Aug 21, 2009 at 19:40 UTC
    Thanks to each of you for taking the time to reply. Lots of wisdom here, you've definitely given me some food for thought, and helped me identify areas which I still need to work on. I'm glad I asked!
      I didn't even realize there were reviews until I read this post. I look for clear examples and documentation, and whether it does what I want. Then I try it. That's it. Of course, I always try all the modules that could work for me.
Re: Dealing with CPAN reviews
by Anonymous Monk on Aug 21, 2009 at 17:11 UTC
    The worse thing is when potential employers review your CPAN reviews and because some idiot, who obviously has a vendetta, wrote you a nasty review, your work doesn't look as impressive.

    Really, CPAN reviews can do a lot of damage. I have some reviews that are many years old and are no longer applicable since I have updated my modules, but the reviews STICK AROUND, despite trying to contact the reviewers in the hopes that they could either update or retract their past reviews. I never could reach them and so it seems that I am stuck with the crazy and negative reviews.

    After a while, you just realize that the reviews mean squat. Sure, they can be helpful in determining whether you will give a particular module a whirl, but they should all be taken with a grain of salt. It would be nice if there were a disclaimer on CPANratings indicating this.

Re: Dealing with CPAN reviews
by leocharre (Priest) on Aug 25, 2009 at 15:23 UTC

    That happened to me too!

    I had the most revolting reviews of some module.. And I looked at the reviews... And I looked at the module.. and I though.. WTF? It's not so bad?!

    So here's what I did.

    I contacted the reviewers one by one.
    Asked them about why, and what I could do to make it better. I even offered to remove the module off cpan!

    And you know what?

    One person responded to me and said.. That when they wrote the review, my module had no code and did nothing- and looked like a placeholder. (I don't remember that, but.. )
    So they re-reviewed my module! :-)

    The other person said something similar and posted some notes to the same effect as another reviewer.

    So.. If you get scathing reviews in cpan... Understand why- if you cannot understand- contact the authors and *ASK* them what they suggest should be done. You might learn something! And it's all about that- about peer review and growing and learning and .. A scathing review is a possible opportunity to improve your skills as a coder/developer.

    I dunno.. It's tough. Come to think about it.. I've only gotten bad reviews.. hahaha.. But at the same time.. I have a couple of modules that people use a lot and even write me to thank me about! PDF::OCR2 and WordPress::XMLRPC - but no reviews! :-).. ahh.. it's all good.