Fat Versus Thin Core
I used to feel the Perl core should be as small as possible. That is, it should ship with the smallest number of modules whilst still being "practical". For everything else, there is CPAN.
So naturally, I was pretty pleased when I heard that CGI and some other modules were going to be removed from the core in perl 5.20. But lately, I've started to change my view on that. Here is why...
I've been watching the p5 porters for a couple years, and I feel that major enhancements to the language just aren't going to happen. There are lots of different reasons for that -- some technical, some social. I'm not bitter and I'm not pointing the finger. This is just what happens when programming languages and their communities mature. The same will happen to Ruby and Python.
But I know that Perl still has a very long and prosperous life ahead of it. But if the future does not lie in the language itself, then where does it lie? I think the answer might be the modules it ships with.
Perl owes some of its success to the fact that CGI.pm was right there in the core at a time when lots of people were starting to do dynamic web sites. Here we are 20 years later, and CGI-style progamming has been replaced by frameworks with routers and templates and controllers. It makes sense to remove CGI.pm from core now, but perhaps we should also be looking to put something in its place. And we have plenty of things to choose from: Catalyst, Dancer, Mason, Mojolicious. How we pick one is a whole other story. But I contend that shipping one of them in the Perl core could be path to the future .
I understand that a fatter core presents a maintenance burden for p5p. But these frameworks actually have pretty large and vibrant communities. Most are probably bigger that p5p itself. So putting one of them into core could help bring many new contributors into the p5p sphere. Some of them might even make significant contributions to the language while they are there.
To put it another way, some folks call Ruby a language with "batteries included". At one time, Perl was the "batteries included" language too, because it had regexes, and interfaces to common system calls, and *gasp* CGI.pm. But now, the world has caught up and we expect more from our languages.
So maybe we need to think about what kind of stuff people want to do with computers these days, and then focus on providing them with a Perl offers them a way to do it. Perl doesn't have to be all things to all people, but it ought to make a strong effort to appeal to some group of people. That probably means putting more modules in the core, rather than less.
 The same thinking could potentially be applied toward DBIx::Class or Poe, or some of the other widely used frameworks.