in reply to How does one choose among modules?

I've dealt with the same problem many times, and for what it's worth my main criteria are:

  1. Does it have a reasonable API?

    Can I subclass it? Can I clone it? Can I mock it with T:M:O? Will my eyes burn when I call its constructor?

  2. Is its documentation coherent?

    Incoherent or missing documentation often points to bad engineering habits, and you don't want to poison your codebase unnecessarily.

  3. Does it pass all its tests and install happily in my several different environments?

    You may only need to deploy it under Ubuntu Marbly Muskrat now, but what if you become an expert in this only to find that it doesn't work on your new client's XServe? (Some things are worth patching and so on, but it's still a big fat demerit.)

  4. Does it have a clean CPANTS profile?

    For the above reason, but with more variety.

  5. Is it actively maintained?

    This isn't universally important, but for a module that does something in a changing environment (e.g. parsing PDFs) or in an infinitely complex problem area (e.g. object-relational mapping) it means a lot if people are working to make the module better. Extra points for fast bug turnaround and for multiple people working together on it; the former means your patches will probably be used, the latter means the code has a better chance of being readable (should the need arise).

  6. Is it in core?

    Even if it's slightly worse, I like the convenience of a core module. But if it's a lot worse, forget it and make the first test in your suite do a bunch of use_ok()'s.

  7. Do people hate it?

    This is completely subjective, but still: ask your local guru or list whether anyone specifically advises against it, and why. There are some widely-used modules that have fundamental design flaws that will really hurt you if you need to grow something big on top of them.

Google searches (especially on PerlMonks) factor in if there's something tricky about the module, in which case I'm mostly concerned with how people explain it and advocate for/against it. I've never factored in Google code searches before, but it's an interesting idea and I might do that the next time the problem comes up.

Replies are listed 'Best First'.
Re^2: How does one choose among modules?
by mr_mischief (Monsignor) on Oct 09, 2007 at 19:42 UTC
    As for actively maintained modules, you're right. If all the bugs are out and the module has the complete feature set intended by the authors, there's no reason to rate the module down for not being updated recently.

    The rest of your points I'll not mention specifically because I have no disagreement nor comments to expand on your reasoning.

    What would you think of a web page with a table listing ratings for all of these things for all of, say, the PDF tool sets? I'm not sure that's the ultimate solution that I'm looking for, but it's one of the ideas that comes to mind. Of course, one might want empirical measures present separately from subjective ones or given more weight, but those are implementation details.

[reply]
      For things that are (nearly) objective I think it would be cool to have such a chart, and not just for "competing" modules. Say, everything to do with PDF:
      1. CPANTS pass/fail rate
      2. Most recent version
      3. Rate of new version releases
      4. Pod::Coverage result (or similar)
      5. Perl::Critic result (violation by severity?
      6. ...and so on...

      All nicely sortable or course. But excluding anything you can't back up objectively, so no "five stars from me" type of stuff.

      In fact it might be really cool to do that for all of CPAN and let you sort/filter/etc on it.... but I'm not volunteering, too busy myself these days.
[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations