I try to stay out of these discussions (*cough* flame wars), but here goes...
The relationship between CPAN and the Developer is bi-directional, no doubt. As an organization, CPAN can, as it chooses, decide to do what you are suggesting, remove software or boot a Developer. However, I do not believe the prerogative of CPAN is to do so, since it would reduce the utility of CPAN as a whole - the point of CPAN, and the advantage it confers to Perl over other languages, is a central location for all software, that is installable in a very straightforward manner. This is something that Java is only recently starting to attempt to replicate (e.g. with Maven). On the other hand, a Developer, as he/she chooses, can decide to accept or reject patches, etc. The nature of open source is that Developers are often too busy with other work (read: putting food on the table) to perhaps commit to tracking down some very difficult-to-find (or even unreproducible) bugs. On the other hand, as a user, you can leverage the advantage of open source - the freedom to see and to modify the source code - to benefit both yourself, and the community-at-large, by submitting patches. If you feel that the patches are taking too long to be applied, or they are being rejected outright, it is your prerogative to fork the project. There are many examples of this on CPAN already - e.g. MooseX::Types::DateTime::ButMaintained. It should also be noted that some projects that appear to have been abandoned have had their maintainership rights assigned to others, who have thus taken over maintenance of a package. You may contact the PAUSE Administrators to discuss these cases. There are many other options that do not involve flaming the developer, who contributed their work to the CPAN for the public interest, free of charge. Should software be buggy? Of course not. But life is not perfect, and there are always trade-offs to be made. At this time, I feel that I would be remiss if I didn't also note that David Cantrell is a rather prolific CPAN developer - his work is used by many other libraries, including some that are packaged in Debian. On the other hand, I guess your statements are more generally stated rather than specifically levelled against Mr. Cantrell, in which case, I will say that in general, open source software provides you, the user, the freedom to: 1. Fork the project 2. Bribe the developer to fix it 3. Choose another suitable library 4. Complain on mailing lists 5. Fix the problem yourself, submit patches (possibly also #1 if upstream is unresponsive) I should note that trying #4 *might* work, but will *probably* alienate the upstream developer and other developers as well. It certainly does not serve your cause. If you are using a CPAN library and making money from it, then I think it is fair that the upstream developers should be compensated for their work - either by you paying them to prioritize your required bugfixes, or by you contributing your work back to them (and the community) in the form of patches. Note that most licenses mention that the software is provided "AS IS", without any warranties, express or implied, INCLUDING fitness for a particular purpose. That means that open source software might well not do as advertised. It is the risk you take when you decide to benefit from software that has been provided to the community in the public interest. TL;DR: I am not aware of any case on CPAN where an author is intentionally, and malevolently, attempting to "sucker" you into paying to make it work. Cheers, Jonathan On Mon, Nov 28, 2011 at 1:14 AM, Linda W <perl-didd...@tlinx.org> wrote: > David Cantrell wrote: > > On Thu, Nov 24, 2011 at 08:09:35AM -0800, Linda W wrote: >> >> Don't have to touch their code,... but if we want CPAN to be able to >>> be relied upon.. it's can't have unaddressed bugs for months (let alone >>> a year or more)... >>> >> >> I promise to address bug reports quickly if you make them more important >> than everything else in my life. >> > > --- > If that's how unimportant CPAN is to you, then I'm sure you > will have no problem if someone takes over maintenance of the module. > > If it is a problem, maybe it will 'become more important to deal > with that than everything else in your life... > > > You can do that by paying me. >> > > --- > Well, i certainly can't enforce this, but whoever sponsors CPAN, > if they want it to stay alive, ***IS*** paying you for the privilege of > putting your code on CPAN and have reserved some name. > > If you don't want to maintain your code on CPAN, then I would > say the default policy should be to no longer 'pay you', in the currency > you are receiving. > > Oh, you want more than permanent fame on CPAN (if your code is > good working), ... OTOH, if your code is doggie doodoo, and basically > a way to sucker people in to pay you to make it work, um... don't > think that's what CPAN was designed to be.... but things do change... > and money corrupts everything...so who knows.. > > > If you >> don't pay me, then you are admitting that me settling down for the >> evening with a beer and a good book is more important *to you* than me >> fixing the bug or accepting your patch. >> > > ==== > You don't have to accept my patch into your code, but you > might consider that having code on CPAN is a privilege as well as a > responsibility. > > If you don't live up the the responsibility part, I think > it is fair that privileges be reduced or removed accordingly. > > Should be a problem for someone who ALWAYS has something more > important to do than CPAN. > > > > > > >
