develooper Front page | perl.module-authors | Postings from November 2011

Re: The CPAN Covenant

From:
Jonathan Yu
Date:
November 27, 2011 23:04
Subject:
Re: The CPAN Covenant
Message ID:
CAMDxSEjcvQUBHsgGWex29g7SEeVBBizuDFmdsVzThbFpnx7pQw@mail.gmail.com
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-diddler@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.
>
>
>
>
>
>
>



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About