|Problems? Is your data what you think it is?|
(For discussion purposes, I'm assuming "module authors" eq "CPAN contributors")
Its Thanksgiving weekend here in the USA. I suggest you immerse yourself in the spirit of the holiday and simply give thanks to all the CPAN contributors, minor, major, orphaning, or otherwise. After all, they've given you the source!. If you have an issue the author won't fix, then swallow hard, fixup a version for yourself and your friends, respect the author's copyright and/or license terms (if any), and move on.
CPAN is what it is. Accept it. If you don't like the fact that a module author doesn't snap to attention everytime you think you've found a bug, or want a new feature, TS. If you want immediate support for everything, you probably need to ditch Perl and head for VB and/or C#, and pony up the $$$/min for MSFT's 900 number. Even Linux doesn't have the kind of response you're demanding, unless you pony up $$$ for Red Hat/SUSE/etc. support contracts.
And be thankful CPAN isn't SourceForge...now there's a real cemetary! At least everything on CPAN usually has actual, "for real and truly" code, that worked sometime, somewhere (tho I have recently seen a few modules posted with major "THIS DOESN'T WORK YET" disclaimers - not just for minor features but for the whole bundle - which seems a bit out of scope for CPAN, but what the heck...)
As for offering remuneration, my experience indicates its pretty pointless. The amount offered is usually just a token relative to the effort. While I'm sure many CPAN contributors would like to get paid for their efforts, most are just scratching itches, or hoping for a little ego stroke, and/or maybe feel the need to give back to the community from which they've taken so much.
Awards ? IMHO, handing out a few chachkis to a select few contributors isn't likely to make a difference.
Ratings ? There's already some ratings on CPAN...but most people don't even bother with them. For that matter, many (most?) folks don't seem to use CPAN directly much anymore, but use PPM's from ActiveState (or elsewhere), so rating won't likely accomplish much except permitting a few cranky users to badmouth an author simply because the author rejected a patch.
As to the suggestion for a "community branch": it would likely violate any copyrights attached to the hijacked, er, "branched" code, so you'd need to get explicit author agreement or assignment of copyright. Of course, CPAN could decide to change the posting policies to require copyright assignment so a module could be "nationalized" whenever someone bitches about not getting their pet feature patched in. At which point, I suspect a lot of CPAN contributors will be clicking the PAUSE "Delete" link shortly thereafter...I know I will. The upside, of course, is all the extra free space that will be freed up on the CPAN servers and mirrors !
E.g., over the past year, some (very few) folks on the DBI maillists have 'turfed for some feature additions to DBI that many of us consider laughable. Under your "branching rule", the 'turfers just need to get a couple likeminded folks to complain about it, and voila! we get a "community branch" of DBI. Not a happy situation...
One possible solution might be to create a secondary classification akin to CORE, for modules which
Asking module authors nicely for such permission to move their module into the "approved" list would likely meet with more cooperation than the "3 cranks complain and you're nationalized" rule, or enforcing a CPAN policy of "sure, you can post here, but once you do, we own it.".
Otherwise, in direct response to the OP Subject: Responsibilities of a module author: