Some of these scripts drive the back ends for multi-million pound companies [...]

Right, but the guy who wrote the CPAN module probably did so to help him out with a 20 liner at home; conversely, if the module had been written for a multi-million pound company in the first place, chances are it would never have been okayed for release to CPAN.

Now I don't run a multi-million pound company, but I do see it as my responsibility to audit the CPAN code I employ, more or less carefully according to the criticality of the operations I'm using it for. If I'm not happy with the code I don't use it - either I roll my own, or I adapt it for my needs.

While it would be nice if all the code offered for free on CPAN were perfect, we're unlikely to reach that happy state any time soon.

One perfectly valid option is to offer the author some money to harden their code, either direct or through the convenience of a TPF grant.

Hugo

I agree with the last half of your comment.

• You should audit the code you use.
• You should harden it, and you should resubmit the code back to the author and back to CPAN.
• Or pay the authour to harden it.

But outside of that the community as a whole has a responsibility to understand the users needs. CPAN modules are for users, what do users need is what the author should focus on. This is usually easy because the code you are working on is for your own needs, and if you need something there is a probability someone else will need it or find it useful once you are done with it.

But I think the point this post is making is with more people using CPAN modules blindly as time goes on what is the communities responsibility to the code on CPAN. With the recent meditations on security in CPAN modules and this I think this whole debate can be changed slightly to does the PERL community need to audit the offerings on CPAN occasionally. And if so should there be a mechanism of discusison for what is found in the audit process.

Now I think that is being done, just the fact that the poster posted this shows the code gets reviewed. And the possible redresses for the situation have been stated, but I think the poster is asking for something more active from the community as a whole in general.

"No matter where you go, there you are." BB

Yes - your assesment is spot on, that's what I was trying to say.

As we now have CPAN ratings, maybe that could be extend to address user error and security concerns. Comments would have to pass through some moderation process and module authors should be given reasonable time to address such issues. If they fail to do so, then a caution should be logged against that module - this doesn't stop others from continuing to use it, but does ensure they are made aware of potential shortcomings.

Maybe something based around that would be possible?

Well I don't own a multi-million pound company either - I just write scripts that are used by some, but not many - if only my pay reflected that :)

Modules specifically written for companies will generally not get released due to ownership issues, but often they're just written for specific in house tasks which are not that useful to anyone else (apart from the odd competitor!)

From my own experience, you might be surprised how much CPAN code does get used by companies. I don't want people to stop releasing modules to CPAN because there's some great stuff out there, and I don't expect them to be perfect either - mine certainly aren't!

It's just that recently when auditing potential modules for our own use, I've seen a few that don't check for write failures and that worries me a bit - I can't see any situation where that's a good idea.

I suppose I'm trying to say if an author writes a module to scratch an itch - fantastic, but please think about proper error checking before releasing it to CPAN because many other people may start to depend on it :)

Some of these scripts drive the back ends for multi-million pound companies, I DO need to worry about how they handle errors.

Well it does matter for people doing this stuff commercially, and I wish (some) authors would start to realise this!

What scripts? The ones you write? Do you follow your own advice? 

Yes and yes as much as humanly possible - forgive me if I don't see the point of this. Are you going to post some useful comments or just troll?

What are you paying these authors?

Nothing - I avoid using these modules because they *dont* check for write errors which is what I've said all along, and for some bizare reason you've chosen to ignore.

Do I generally pay the authors of modules I use or the perl developers? No, though a previous company I worked for did heavily sponsor Embperl development - I would always consider sponsoring a module author if a module showed promise and could be useful to us - as a salaried employee I'd prefer it if sponsorship came from the company rather than my own pocket though :) I've donated code to a CPAN project and a tiny bit of stuff to KDE, and am happy to donate code/advice to authors (which may or may not be useful!) - that's generally how things work in the OS world isnt it. Don't forget that a lot of bug reports are probably coming from developers using code heavily in commercial environments, and that does help the whole community in a more indirect way.

Ok seeing as I know this is going to go into a discussion on commercial companies and social responsibility etc - just because I mentioned money and companies does not mean I consider myself important or a great perl coder - I write fairly solid code but there are many developers in the perl community better than me (and probably better paid as well :). Some posters have implied that it doesn't matter if a script isn't robust - I'm respectfully saying that just isn't true - for other people such as myself, it's vitally important that scripts are 99.9% robust. Actually, unless you're just pratting around, I can't see any situation where silent data loss is desirable, but that's exactly what will happen if you use some of the modules on CPAN without a lot care.

I'm trying to emphasise the fact that if an author *chooses* to release to CPAN, and it is *their* choice, they really must think about sensible error handling before they release. Who knows what will be developed with/on top of that module, and what impact it may have later on?

If a script doesn't handle errors, at least the problem is localised to that script but, as we all know, modules are there for *reusable* code and that code might be used in thousands or millions of scripts. A module author therefore has to take some responsibility (heck, pride even!) for ensuring robustness - I'm not talking legal liability here, just a personal duty. If they can't or won't do that they should *NOT* release to CPAN - post it on their site, advertise it here, do anything else yes, but again - DONT PUT IT ON CPAN!

Code auditing is an answer, and depending on the project ranges from being to desirable to mandatory, but having to do a thorough audit on every CPAN module you use takes a lot of time and effort - as suggested by another poster, I need to look at the B:: stuff to see if that could help automate things - if I get something done (which wont be anytime soon) I'll release it here.

If they can't or won't do that they should *NOT* release to CPAN - post it on their site, advertise it here, do anything else yes, but again - DONT PUT IT ON CPAN!

CPAN is for sharing, not for perfection. Outside of being polite, CPAN authors have zero social responsibility. This draconian sense of entitlement that you have is really repulsive and won't convince anyone, regardless of the validity of your ideas.