NeilB

We've probably all got one or more modules that we're very thankful for. Maybe you use it again and again. Maybe the fact that it exists saved you from having to write it yourself. Maybe it's such a well-crafted module that you don't need to think about it, but always have it on your tool belt.

Maybe for/on CPAN Day, you could do or organise something related to that module, as a way to say thank you, perhaps to improve it for all of us?

Here are some ideas.

Tell the author

Email the author, either just to say "thank you for Foo::Bar", or if you're feeling more effusive "your module rocks!". Being specific is good, but the email really doesn't have to be very long.

You might think this is a bit tree-huggy, but I can tell you that it's pretty damn good to get an email like that.

Fix a long-standing issue

There are plenty of distributions that have gnarly bugs or feature requests that have been there for a long time. Some of them we all look at and think "yeah, it would be good if someone did that."

If your company uses the module, you could persuade your boss to let you organise a mini hackathon, so a group of you can work together.

Unless it's obvious what needs doing, you should probably discuss your plans with the current maintainer first.

Improve the distribution's test coverage

Use Devel::Cover to check the test coverage, and if it's not 100%, work on the testsuite to move it closer.

It really isn't often that authors get PRs to only add tests, but I bet it's a good change to get.

Make it faster

Check the performance of the module with Devel::NYTProf and see if there are any obvious hotspots you can do something about.

Watch Tim's video about this first, and depending on the nature of your changes, talk to the maintainer as well.

Resolve CPAN Testers failures

Have a look at the distribution's page on MetaCPAN, and see whether there are any failures reported by CPAN Testers. There are many modules which have always worked fine for me, but when I look on MetaCPAN I see a notable percentage of failures.

If you have a CPAN distribution that relies on this one, then those failures might represent failures for your distribution too.

Addressing CPAN Testers failures can sometimes be a pain, since it might need you to track down a machine / VM with the particular operating system. You spend several hours on that, and then it only takes a minute or two to identify the problem and fix it. You're making CPAN more reliable by doing this.

Blog about it

Write about why you like the module, and how you've used it. Maybe show a non-standard use for it, or explain when and why this module is a better choice than some of its competitors.