(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

• have explicitly assigned copyright from the author(s)
• are treated much the same as CORE modules
• but are not delivered within CORE

(kinda like the "javax" namespace in Java).

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:

• don't knowingly violate anyone else's copyright or license terms
• graciously accept the thanks of users who've found your contribution useful
• patiently listen to user's suggestions and bug reports, and help as best you can

The first is the law, and the last 2 are simply good manners. Imposing more on contributors is likely to send them to the exits, or off to SourceForge or elsewhere.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.