we have almost a "no external modules" policy here, and are basically restricted to the "core" Perl modules and DBI.

Theres not much to add to this thread but a minor observation. The "core" modules have been evolving for quite a while. Not only that but there are several collections of "core" modules. ActiveState fwict bundles a _lot_ more into their releases than are in the "standard". Each new version of perl has a slightly different set of modules acompanying the code and not only that, they have different versions. (Does your company let you upgrade modules in the "core" from CPAN? Will it let you install a module that has been included in a later perl release but not in the one you use?) A few modules are IMO still in the core becuase they have been in the core for so long nobody wants to remove them, _but_ they have been generally replaced in new code by other more powerful modules anyway. File::Basename vs File::Spec comes to mind as example. Does your company have a policy about which of the two should be used?

Afaik the list of modules that is included is constrained more by space (how many users really are going to use Parse::RecDescent for instance?) and a modules utility to actually buidling perl itself than by the modules worthyness. Not that unworthy modules would ever make into a standard release, but that there are tons of worthy modules that will never get included because their user base wouldnt be large enough to burden every install with. (Space is already being discussed in some circles as being excessive.)