|XP is just a number|
Re: Losing faith in CPAN - unresponsive module authorsby xdg (Monsignor)
|on Jun 25, 2008 at 17:17 UTC||Need Help??|
A few years ago I wrote about this in Responsibilities of a module author. I think it still holds true today. It would be ideal if authors were more responsive, even to say that a patch or bugfix isn't a priority. Unfortunately, not everyone is. I hope you won't let a few bad experiences color your perceptions.
When I've encountered this in the past, after a few months, if it's a problem I'm really motivated about, I send the author an email asking about the status of the patch. If I don't get a response, I send a similar email once a month or so. (Not a long email -- like two sentences with a link to the RT entry.) In most cases, I've gotten responses back -- usually an apology for being too distracted to work on it.
In other cases, somewhere between three and six months or so, I've offered to release the patch as a dev version if the author would give me co-maintainer rights. And I continue to make that offer every couple months. (That's how I wound up inheriting a number of modules, I'll admit.)
Some people may say that this is too much harassment, but I don't think a 2-sentence email once a month is inappropriate. I'm a "customer" -- albeit for a free product -- and some responsiveness, even to say "I'm not going to fix that" is a reasonable expectation, I think. Obviously, if the author says "go away, I won't fix that" then I wouldn't pursue it, but that hasn't been my experience. Usually authors are just legitimately busy with @life and $job.
If I get no response to any of these emails, then I'll try other ways to contact an author and if that fails, then if I'm still motivitated, that's when I think it's appropriate to appeal to the PAUSE maintainers for co-maintainer rights.
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.