Re: Reliable software OR Is CPAN the sacred cow

[blue_cowdawg]

1. be reliable: it should do it work correctly (ex. for email parsing task it must support all features defined in RFCs related to email format plus be able to handle non-RFC-compliant emails produced by some buggy software) 2. be secure: it should not allow unauthorized usage 3. next priorities may vary from have a lot features to work fast or be cheaper or have intuitive interface, etc.

Are you trying to tell me that your own code is 100% bug free and does all the above (or some analog thereof) 100% of the time?

Gimme a break! I know that I've probably written on the order of 1,000,000 lines of code over the last 35 years (proably more than that, I-dunno, the number ain't the point) and I've run into more WTFs in my own code. Subroutines that "shoulda worked" that didn't for one reason or another, forgotten switch cases, token types in a parse I wasn't expecting, you name it.

You're complaining about something that was written by volunteers. That's silly. If it's broke and you have a fix for it, gently and politely contact the module's author(s) and let them know you have a fix. They might even incorporate it in a future release of the module.

What I've described in a nutshell is the way Open Source is supposed to work and what is supposed to be the strength in Open Source. This is the difference, at least in my mind, between free, as in "freedom of speach" and free, as in "free beer."

If all you do is take from the Open Source world and don't at least offer to give back in some form or another then, in my humble opinion, you've blunted your right to complain. Even if your not offering code to fix a problem, you could at the very least offer up to the author(s) your situation as a test case of where the OSS code in this case is going wrong.

Hey... if code were 100% reliable 100% of the time us System Admistrator types wouldn't have jobs! :-D

Just my US $0.02 worth....