Based on the posted email exchange, I wouldn't say either one of you is being a jerk... but you're in danger of being a jerk if you continue to insist that Ivan change his module as you desire.
Ivan wrote:

This module is for verifying _real world_ *credit cards*. It is *NOT* a pedantic implementation of the ISO 7812 standard, a general-purpose LUHN implementation, or intended for use with "creditcard-like account numbers".

Okay Craig, let's look at it from the flip side. Say he implements your requested change. There may be people out there who are using this module on real, actual credit card numbers which are always at least 13 digits. Now, are you going to deal with all of the bug reports about how upgrading to the latest version of Business::CreditCard broke some applications because it suddenly started accepting 10 digit numbers when before it did not?

Ivan's approach is conservative and correct.

As an alternative suggestion maybe you can convince Ivan to add a verifyISO() routine that acts as you desire. (No one is likely to be depending on something that doesn't exist :-) But if he doesn't want to do that, you still have other options--"subclass" his module (I don't know if it's OO or not but a similar idea holds even if it's not), create your own module, use his module, but write your own routine that you inject into his namespace for your own nefarious purposes, etc. :)

He doesn't seem to believe that your argument (nor patch) add anything toward those goals. He's quite correct to insist that you fork the module should your goals differ.

-David

Your original beef was that you couldn't use Business::CreditCard for Authen::PIN. You accepted that "Authn::PIN probably shouldn't use this module for a general-purpose LUHN implementation."

But then it became a question of whether validate should obey ISO-7812 or follow real-world practices. Do you even have any stake is this? I mean, do you even use the module? It sounds to me you like you found a "problem" in a module you don't even use. I suspect the validate is almost exclusively used to verify a credit card number before initiating a transaction. Anyone using it for that purpose would welcome the cut in false-positives that checking for a minimum length of 13 digits provides.

If you do use this module, and this check is causing a problem, you should be discussing that problem. If problems or false-negatives occur, the author is willing to re-open the issue: "Feel free to re-open this bug if verify() doesn't work with any real-world credit card number."

After reading through your email exchange my opinion would be that no, you're not being a jerk. OTOH I fully understand and agree with Ivans decision to verify credit card numbers by checking for a minimum length of 13 characters until there is a real-world case of a valid cc number with less than 13 characters. So if you need a module with your desired behaviour (and it is worth the effort to follow the updates of an upstream module over the years), you probably should fork and create a new module under a different name. Whether that module would be useful enough to upload to CPAN is for you to decide.

The only part that confused me was

Feel free to re-open this bug if verify() doesn't work with any real-world credit card number or you have a patch. :)

He asked for a patch then rejected it. Either way let it go and figure out a more appropriate module for your need. Lots of modules can be reused for unintended reasons but once its apparent he only wants to handle real cards let it be. Makeing a module better and work right is different from making it work more like you want ;) BTW the following code does what you want and still uses the module so you get any future enhancements. Definitely redundant code in that module for getting the check digit.

sub check_last {
        my $last_digit = substr($_[0],-1);
        my $card       = substr($_[0],0,-1);
        return 0+($last_digit == generate_last_digit($card));
}
[download]

Interesting post. This is timely for me, since I coded up some additional stuff for WWW::Mechanize (to handle link titles) that I needed for some testing I'm doing. I got onto #perl to ask about the protocol for doing such a thing, and was told to submit a change to RT on CPAN, along with my justification.

I have no idea what the author's reaction is going to be, but I've talked to Andy (once -- it's unlikely he'll remember), and I found him to be a great guy. He's also got his own opinions, and may decide, for a variety of different reasons not to include my changes. Hey, that's the way it goes. There are plenty of workarounds I can use if I want to continue to use my change in the future. It's not the end of the world if my change is rejected.

Always remember, There's More Than One Way To Do It -- when you realize that you're trying to force something to happen in a certain way, maybe that's a sign you should be trying a different approach.

Create a patch set and backward compatability are the two major things I would advise.

If your version is radically different from the current version of the module the likely hood of getting a feature included is minimal. If the current fuctionality is just plain wrong thats a bug and can be explained as such.

If you need behavior that is different from the current module then provide a way of switching it on and off. The default should be off for compatibility but with time this may change.

Provide a patch set against a specified version of the module. This allows the maintainer to easily evaluate what you have done and how it effects everything else. Including it in a open location, developer mailing list etc will allow other people to evaluate your changes and make suggestions even if the change isn't accepted.

Take the GP example. This was just a straight bug report not a bug fix. These will often get rejected as being irritations unless they are genuine issues in the majority case.

My personal opinion is the likely hood of the request being dealt with would have been better if a patch like the below snipet had been included.

Hope it help

UnderMine

On a train in the middle of nowhere

 sub validate {
-    my ($number) = @_;
+    my ($number, $param) = @_;
     my ($i, $sum, $weight);
    
     return 0 if $number =~ /[^\d\s]/;

     $number =~ s/\D//g;

     return 0 unless length($number) >= 9 && 0+$number;
+    return 0 unless length($number) >= 13 && !(defined $par am->{ISOs
+trict} && $param->{ISOstrict});

     for ($i = 0; $i < length($number) - 1; $i++) {
      $weight = substr($number, -1 * ($i + 2), 1) * (2 - ($i % 2));
     $sum += (($weight < 10) ? $weight : ($weight - 9));
     }

     return 1 if substr($number, -1) == (10 - $sum % 10) % 10;
     return 0;
 }
[download]

Note: code unchecked

I suspect that "impartial friend" is an oxymoron, except in the limited case of the friend being a friend to Ivan Kohler and you.

I've read the dialogue, and I think Ivan is right. I think he's right, with this as the this main groundmostly for this reason: any change in behavior visible to the user is a bad thing, unless there are cases where the module is behaving in contradiction to its documentation¹. ISO 7812 may allow credit card numbers shorter or longer than 13 digits, but I suspect that shorter numbers are very unlikely, as 13 digits only allows five digits for the customer number.

No, I don't think either Craig or Ivan are being "jerks." Disagreements don't imply either party is a jerk; it's the behavior during and after a disagreement that puts one (or both) participants into the state of jerk-dom. Both have legitimate reasons for their positions. Both are remaining civil, so neither is a jerk.

I've got to stop writing these when I have to leave the keyboard.

Editorial changes

Note: having $code, you can chop it and generate the last digit, then compare with the chopped one.

Oha

Update: i do not agree to suggest to fork the module, probably you can ask the author to make a verify_last_digit() method which does not check the length?

You want to use verify() to check PINs from some other module so you pretend that you care about some ISO spec and then post a sour-grapes review based on this pretend concern of yours without mentioning your true motives. Yes, that was the action of a jerk.

++ for being brave enough to ask for honest feedback. I agree with several posters above. Not a jerk yet, but time to let go.