|P is for Practical|
Re^4: Responsibilities of a module authorby BrowserUk (Pope)
|on Nov 26, 2005 at 13:00 UTC||Need Help??|
No. That was not my intent, but I agree with you (and others that/msg'd me) that it could be read that way.
My intent was to suggest a mechanism whereby the users of a module could collaborate to fork a version of the module that would allow them to pool there efforts into producing and maintaining something that met their needs and requirements.
The intention was to avoid having 20 individually forked versions, whether on cpan or local production systems, whilst relieving the pressure on the original module author from having to either feel obligated to react to user pressure for new features and bug fixes, or abandon all control over the direction his code went in.
I felt that if a few, long term users expended their time and effort coming up with one or more patches that met their collective needs, and demonstrated both their commitment and collaboration to getting something that worked for more than a single application, the author my feel more inclined to see their point of view and incorporate those patches back into the original module. I did not envisage any mechanism for forcing him to do so.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.