in reply to Re: Responsibilities of a module author
in thread Responsibilities of a module author

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.

Please go back and re-read the quote that got me started on this meditation. Perhaps I got off track in the meditation itself, but the issue that I find frustrating is less about CPAN contributors not fixing things when they break but about not even bothering to maintain things when others in the community offer help.

You're absolutely right that the code is there and it can be forked off. But I don't think it helps the community (whatever that is) to proliferate module releases along the lines of Blah::Blah::Fixed. So... instead, I'm trying to spark a discussion what could be done short of that.

In response to some specific points, I was approaching this from the standpoint of things that might encourage me, as a CPAN contributor -- by positive or negative means -- to step up the priority to fix a bug, incorporate a patch, etc. at a time when I'm not actively using a module and have a shortage of tuits. It certainly wasn't a suggestion that any of it be "imposed".

On the money front, I'm not suggesting significant amounts like a shareware model -- if someone said "hey, if you could get that patch in there in the next week, I'd gladly buy you a drink at the next YAPC" that might well be enough for me. The idea is to explicitly recognize that asking someone to do something for you is an imposition in their busy lives -- and even a token offering can be enough to make them feel valued as opposed to put upon.


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.

Replies are listed 'Best First'.
Re^3: Responsibilities of a module author
by renodino (Curate) on Nov 24, 2005 at 01:48 UTC
    I actually got to thinking about this in light of BrowserUk's mention of a "community branch". Tho I disagree with the tenor of his suggestion (i.e., just taking the module over), I think theres a germ of an idea (which has probably already been discussed somewhere around here): namely a second tier of modules below CORE, but above "whatever's on CPAN". For the sake of discussion, I'll call them Certified Modules.

    If I read your OP correctly, one of the major issues confronting developers is that organization's won't permit downloading just any old module. I know I've encountered that with a number of my customers. If it isn't CORE, then there better be a very good reason to install/upgrade it.

    So if there were some add'l level of "trust" involved, i.e., a certification, then that issue might be eased. And part of the requirement for a Certified Module is that the module author has explicitly agreed to release the module to whoever administers certification for maintenance. One can imagine many other baseline requirements (e.g., it must use the normal build/test/install make process, it must have a test suite, it must explicitly specify which versions of perl and prereq modules, and on what OS's and/or platforms, it is certified for.

    Of course, there's the little issue of funding... I doubt there's much of an opportunity for commercialization of the process, and it will cost money for all the h/w and s/w, not to mention staff to run this. But hey, if OSDL can survive, maybe there's room for another such org ?