Propriatery company
One of the reasons they might not want to release is that they think the technology they created is unique (in fact, it is not available from CPAN) and as a company that lives from propriatery software it is hard for them to release any code as Open Source. Even though this code is part of QA and nothing to do with their products.

In addition to the code that is not available from CPAN they also have plenty of code that basically provides the same functionality as some of the CPAN modules but were written internally. Some were written even before the relevant modules were available on CPAN, others were written despite the fact that there were similar modules available but either bacouse of some technical problem or because of the NIH syndrom, the CPAN modules were not adopted.

So now, because they have not released those modules to CPAN when they were new, the company has to maintain a set of internal modules spending lots of time and money. Most of this work could have been outsourced to the community by getting some other people involved in the development or passing the maintainership to some interested people.
These modules are usually also less flexible than their CPAN counterparts as they only solved some subset of the problem and as we encounter more of the same problem we have to improve these modules. Replacing them by the relevant modules from CPAN is not easy as they have slightly different APIs.

Releasing code takes time
They are afraid that the extra work needed to create a CPAN distribution and then to support the users is too much and is a waste of time.
The developers will also have to spend time now researching other CPAN modules, discussing issues on mailing lists etc. just in order to get their modules up to CPAN.

I think that many parts of the extra work should be done anyway if we want to maintain our code with high standards. (Easy packaging, unit tests, documentation. I am directing them in that direction anyway.) The support issues should be either rejected and users should be told to implement their extra requirements as subclasses (but then of course we need to implement our modules with clean separation and easy subclassing in our mind) or should be accepted as patches or just seen as opportunities to get free QA on our code.
IMHO the extra time spent on getting involved in the community will pay off extreamly well for the company. The employees will be much more knowladgable about the tools they use, they will be able to solve problems much faster as they have the help of the community, they are also going to be much more satisfied as they see their code is being used by others.

Releasing trade secrets
They are afraid that some of the code that goes out might actually reveal real trade secrets of the company.

I think the internal code reviews of management should be good enough to avoid such situatuion. This is easier when we are talking about source code that is in the QA department but can be done even if the code is part of the product or service.

Helping the competition
They are afraid that by releasing code they use internally for testing they give tools to the competition free of charge.

While among other companies, competitiors can also use this code most of the users will probably companies that are not competitors at all.
Also usually these modules are not some Earth shattering inventions and I think the advantages of releasing code are much bigger to our company than to the competitors. Besides, in a short while someone will upload such a module and then we are left with the costs and the competition still got the help free of charge.

• peer review, more people looking at the code and improving it
• finding and fixing bugs even before we hit them
• finding and fixing corner cases
• making sure the code runs on several platforms even before we can test it
• forcing us to provide better quality:
  • packaging
  • documentation
  • unit tests
  • platform independency
  • clean implementation
  • reusabilty
• Getting our developers involved in the community will make them become more productive
• Help attract good Perl developers, help in recruitment
• Help retain the good developers
• Allow them to reuse code written here on their next job, thereby getting them to improve our tools even after they leave our company and are on someone else payroll.
• Make the developers interested not only the pay they get for writing this code but also by having their name associated with some code that the next employer can examine. That is, writing good and reusable code will be a clear interest for them.
• New hires might already use some of our code thereby reducing training cost