I realize you asked for reasons why people drag their feet regarding upgrades and learning new ideas, but it may be more helpful (and constructive) to focus on solving the problem.

I believe Masem's got the right idea in that you need to set up a separate installation of Perl 5.6, along with the modules you desire and then use that to develop and deploy new work. It may seem a waste of resource at first glance, but consider the other changes, bug fixes, features, and modules you can tap into. It may be wiser to consider it an investment in the long run.

I'm not certain how your site is implemented, but I believe it's fair to say that it either uses text files or databases at some point--two things that Perl excels at searching, editing, and updating.

With this in mind, it should be possible to:

• Locate all potentially troublesome CGI scripts on the server(s) in question.
• Copy them to a testing area and modify the shebang line to use the 5.6 installation
• See if any (or all) have compilation problems (e.g. -c) and record those problems in a separate file.
• Automate the fixes that can be done easily.
• Document the failures and develop in-house packages that provide convenient, more idiomatic solutions that fix the problem with as few changes as possible.
• Invoke the modified scripts via LWP::Simple (or whatever) using test parameter values.
• And so on

The idea being to borrow the most successful hacking tactic and socially-engineer your managers, sponsors, and co-workers to understand the benefit of your ideas. People usually don't change their minds until they see real advantages to doing so. You can demonstrate these benefits (and also help determine the scope of the problem) pretty easily by using Perl's skills as a glue language.

(Done right, these utilities may eventually lend themselves to a complete deployment harness, like the one tilly alludes to from time to time.)

For example, you mentioned that you repeatedly see similar calls to sendmail. Since it's used so repeatedly, you should have an in-house wrapper that provides one or more interfaces into a more appropriate approach. Similarly, you should have a shared openFile() subroutine, one perhaps that tests the filename for taintedness and fails cleanly.

You may not be able to automatically find every problem, but if you can find most of them, it should be reasonably easy to get people to buy into fixing them--especially if you provide convenient and simple solutions to those problems. Once the majority of problems are found and solved, it shouldn't take long to fix any remaining issues.

There are several ways to tackle the technical details and I'm sure you can think of several more than I've mentioned. However, you need to show your people why they should upgrade their thinking and I believe the best way is to given them evidence that doing so will provide better results, be far less difficult (and expensive) than they fear, and provide clear and present benefits to the function, stability, and security of your site. It'll take time, patience, diplomacy, and some careful task management, but I think it'll help the organization in the long run.

--f