CPAN candidates for adoption

Following on from a blog post here last year, I've come up with an improved measure for identifying CPAN distributions that are potential candidates for adoption. I've put a list of the top 1000 adoption candidates online, and you can read more about the scoring measure on my blog. What else could I factor into the score?

Update: I've had lots of good feedback, and am working on the next version, which will hopefully have not so many false positives.

I've added a Questhub quest stencil for adopting a module.


Can I add modules to that list? PDF-Template and Excel-Template (and Graph-Template, for that matter) need to be adopted.

Hi Neil

On Adopting a Module, please add that reference to CPAN::Changes::Spec as on the page.

Also, phew! Glad to see none of my modules are on the list. But that's probably because no-one's using them ;-).

A suggestion for additional scoring is add a point for modules that are mentioned in the core documentation. Perhaps one for modules that are included in core.

This came to mind when wondering why Math::TrulyRandom wasn't on the list. It's mentioned in the core documentation for rand. It's also broken in many ways and has no owner. However it has no dependent distributions so ends up with a score of 6 (my estimate). In this particular case I think the correct answer is to patch the core documentation to remove any mention of the module.

Said module brings up another point, which is that arguably the module should go away entirely.

Nice work.

IMHO the scoring should be improved.

The current scoring does not score high, if

- the author releases cosmetic changes
- the author maintains many packages
- the module has no dependents
- the module has a small community

The scoring mechanism doesn't seem to have much of a resolution. Many of those dists don't need adoption at all. One module of mine is in there because it has two wishlist tickets…

Yeah, I was thinking about Test-MockModule when opened that page. And here is it, item 2. Good scoring probably.

Definitely! Some day. But for now I have less-intrusive ways to contribute to perlish opensource.

Author activity may be useful to factor in. I'm quite active, and would rather not see anything of mine listed, for example. It only suggests that I'll receive "May I adopt?" requests to which I'll have to reply. ;)

It already is (to an extent), since inactive authors receive a higher score.

Also, just because an author is active, it doesn't mean that they support all their modules equally - there are quite a few active authors with modules they've not updated for years.

I see one of my module on the list. The one I maintain the most. It is also the most used, and has quite a few open bugs. So it looks like your criteria don't really work.

I think this is a brilliant bit of work, but I think it could do more to distinguish between two goals. Is it trying to identify modules which need adoption or is it a general indicator of the quality of CPAN?

If the goal is identifying modules which need adoption then there should be a qualifying criteria.

I suggest that module which has been released within the last year should not qualify even if its overall score is very high.

As it stands, a module which was released yesterday with a lot of bugs and dependencies could score quite highly.

I have plenty of modules that have not been updated (except for minor cosmetic updates, like getting the changelog into CPAN::Changes::Spec format) in years. However, that doesn't mean I've abandoned them; it more likely means that currently, they do everything I need them to do.

If my needs change in the future, they are likely to get another round of attention; ditto if somebody reports a serious bug. But if everything seems to be working fine, then there's no point gratuitously updating them just so they seem more active.

I imagine there are plenty of other authors in similar situations.

Hash-Util-FieldHash-Compat (which is not mine, but seems a good example) has been sat on version 0.03 for over 5 years; and the changes since 0.01 have been fairly minor. Yet it works well; OX uses it; KiokuDB uses it. If something went wrong with it, I'd be fairly confident of that it would be fixed quickly; not least because its current maintainer is also a maintainer of KiokuDB so has a vested interest in doing so.

Agreed with Toby. I'd increase the weight of # of open bugs (-wishlist) and number of CPANTesters failure reports, and pay less attention to release date.

A metric that took into account the percentage of failures on recent perl versions would be quite useful -- it's definitely a sign that a module has been neglected and needs some love.

It occurs to me that it might be best to rename this list to something like "Modules Which Could Benefit From More Attention". Calling them candidates for adoption is a bit inflammatory, and some authors may get angry when they see their modules on such a list.

But if the list just highlighted modules that could use some live, that could lead top adoption. I for one regularly ask bug reporters for some of my modules to adopt them because I no longer use them (I've not had a great deal of success there though ;)

Leave a comment

About Neil Bowers

user-pic Perl hacker since 1992.