In Can I please have *simple* modules?, I was struck by this comment by Ovid:

Personally, I've sent plenty of bug reports to authors. Sometimes they fix them. Sometimes they ignore them. I've sent plenty of patches to authors. Sometimes they use them. Sometimes they ignore them. Sometimes I've just sent a damned tarball with everything working only to receive no response. In fact, there's one piece of software I use regularly which I've patched locally because I've been waiting over a year for the author to keep his promise to incorporate my patch (I'm not naming the code but I'm pretty annoyed by this).

I've run into this myself, and I know that at least one of the Phalanx projects has similar trouble -- when the author even explicitly agreed up front to have his module reviewed.

I suppose I shouldn't be surprised at this. One downside of using things that are "free as in beer" is that sometimes you get what you pay for, or rather, you don't get what you don't pay for -- and that means support and bug fixes.

An often heard refrain from module authors is "patches welcome". That's a good sentiment -- patches should be welcome -- but that answer doesn't substitute for taking responsibility to fix one's own bugs. The author may really mean "I don't have time to fix that right now, if you can fix it, I'll incorporate it" but without an explicit response that indicates the author intends to fix it "eventually" it sends the message that this is not a module the author cares about keeping up. This is particularly true when patches are submitted and then sit idle. That's fine -- it's free work after all -- but it matters to potential users who are concerned about whether they can depend something over the long term.

(Of course, the hassle of unravelling bug reports can be high and that create a barrier of inertia for fixing it, but that can be addressed in part by encouraging bug submitters to use test-driven bug reports, instead of brushing them off with "patches welcome".)

I think this is part of the reason why some Perl authors only want to rely upon the "core" modules -- there's a minimum committment from the Perl porters to maintain it. That got me thinking about what practices I'd like to see from module authors in general. Here's a beginning list.

Responsibilities of a module author:

• before submitting a module to CPAN: don't release it to CPAN unless you're willing to commit to support, or at least explictly note your intended level of support (including 'none') in the module documentation

• when a bug is reported, whether by email or on RT: always respond to the report if only to give an indicated priority and expected time to fix

• (Addition) when a patch is offered: test the patch and either incorporate the patch or explictly reject it, all within a "reasonably" short period of time

• if an author doesn't have the interest/bandwidth to maintain a module: offer co-maintenance to an interested party to take over or release an update to CPAN that note that module support is ending

Of course, a list of responsibilities may or may not be heeded. Several thoughts occured to me as ways to improve the feedback loop to encourage module maintance. As an old boss described to me, "some people are carrot people, some people are stick people, it's important to know which" -- so I started brainstorming ideas on both sides:

Ideas for improving the author feedback loop:

• money talks -- if some functionality is critical, offer to pay the author a bug bounty to bump the priority over other things

• name and shame -- several variations:

• add negative reviews to cpanratings for modules where the author doesn't respond to bug reports in a reasonable time

• add author reviews in addition to module reviews at cpanratings

• name and fame -- create a new, annual community award (or awards) for "best maintenance" of an existing module and honor a half-dozen people a year or so for their efforts

• count the tickets -- make more distribution statistics from rt readily available, such as number of bug reports outstanding; trend of bug reports opened/closed in last month, quarter, year, etc.; longest open bug report, etc.

What do you think of these ideas? What other suggestions do you have for module-author responsibilities and practices or for how to improve the feedback loop between bug reporters and module authors?

Updates:

• Yes, this should have been about CPAN contributors, not "module authors". Pardon my narrow vocabulary.

• Feedback has made me realize that my meditation drifted from the instigating idea about how module authors deal with patches. I've added a point above about that. I have no problem with module authors not fixing things -- as long as they communicate about it. To me, it should be common courtesy to at least reply to someone who reports a bug, and even more so if someone goes to the trouble to offer a patch. My suggestion around responsibilities also covered recognizing when it's time to turn over the reins to someone more interested in maintaining a module -- and maybe that was really the point I should have made about patches that just sit idle.

• Struck the comment about "not uploading to CPAN" -- it seems to have sparked responses well out of proportion with what I'd intended. (I'm boggled that some people seem to think that guildlines like this could ever be "enforced", but I don't want to distract from the underlying message.) I left the point as explicitly noting the level of support, including 'none'.