|The stupid question is the question not asked|
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:
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:
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?
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.