|There's more than one way to do things|
We're using Perl 5.004.04 (which I know is full of bugs and some quite serious security holes anyway).
You do what? No, seriously. I think there's something wrong with that attitude.
But this seems reckless to me. On the other hand, very probably your codebase actually relies on those bugs in external software (I've seen that oh so often ... :-( ), and if it does upgrading would be disastrous, indeed. But consider: How many people actually know the trouble spots in 5.004.04 and know how to avoid pitfalls. Is the primary reason to distrust outside code a missing test suite which ensures the robustness of your system?
Is your staff actually a good enough team to tackle XML parsing on its own without taking years to do it right. Without hiding disastrous bugs in that code? And if they are good enough, wouldn't they be good enough to do proper code review on existing modules and feeding those bug fixes back to the community, serving others as you perfect your system?
I know from personal experience that we employed external code (CPAN modules in this case) which contained bugs. We found them in our testing environment, fixed them and sent patches to the author.
Ergo: By using external code, you don't have to use all external code there is. Which means: You can still write your own if you want/need to. Careful selection of modules is of course necessary as some others have noted above, too.
In reply to Re: Re: Re: Production Environments and "Foreign" Code