(Or "Why the solution has been obvious from the start.")
If my hypothesis is correct, that Perl 5's current development process is unsustainable, in part because synchronizing dual-lived Perl 5 modules with the core is a fool's game, there's one obvious way to get Perl 5 on regular release schedule and add important features that just about every other serious programming language supports.
Most of the pieces are already in place.
The success of the CPAN and its ecosystem already demonstrates that this strategy can work, as does the presence of virtual dependencies in packaging systems for free operating system distributions.
The idea isn't new at all, but you may not have heard it expressed this way: to solve (some of) Perl 5's maintenance problems with coordinating the stable release schedule of dozens of modules and distributions maintained outside of the core, stop coordinating the stable release schedules of dozens of modules and distributions maintained outside of the core.
Remove dual-lived modules from the core. (Update: Leave those modules necessary to bootstrap a full CPAN installer, of course.)
What replaces them?
If the underling premise of modern Perl and enlightened Perl is correct -- that the world's best and most effective Perl programmers take full advantage of the CPAN to make up for missing language features, to improve their productivity, and because solving a problem once and for all and sharing it is the ultimate expression of laziness, impatience, and hubris -- then the problem in the Perl world is that we don't do this enough.
To bring up a repeated example, releasing software regularly can be difficult. The best way I know to make it easy to release software every month is to release it every month. If it's difficult to release your software every month, you have a strong motivation to make it easy.
The Perl world hasn't made it sufficiently easy to find, install, maintain, and upgrade non-core code. Projects such as local::lib, CP5.6.2AN, and CPAN Testers go a long way. They don't provide everything, but the tools and knowledge are present to add the next few necessary features.
Please note that all of these features depend on CPAN remaining an uploading service and a mirroring/distribution service. CPAN itself doesn't need to change. CPAN works just fine for these purposes: especially as its simplicity has allowed a solar system of related services and tools to form around the shining star that is the CPAN distribution service.
The benefit of removing modules from the core are simple and compelling:
- There is less code for p5p to maintain.
- Releases of modules can occur on their own schedules; releases of the core can occur on its own schedule.
- Bug reports, feature requests, and patches will not as easily get lost in the cracks between the maintainer's preferred communications medium and the p5p list.
- Crufty old modules superseded long ago by something more decent will lose whatever patina they had from their "Of course they're core modules! This means we should use them!" status.
- Places of work which refuse to vet or install non-core modules will be revealed as the soul-sucking portals of hate that they are and all right-minded people will ignore them.
(The final reason is conjecture, but very satisfying to imagine.)
For this to work, the Perl community must:
- Produce a graph of modules and their dependencies in a form consumable by other services. David Cantrell's CPAN Deps (link not provided in deference to his bandwidth and CPU resources) is a great start.
- Exploit the CPAN testing reports to identify potential changes in leaf nodes of the graph due to upedge changes.
- Revise the testing strategy (and its reporting) to alert upedge authors of the effects of changes on downedge authors and vice versa.
- Publish metadata on the best-possible recommendation of versions for modules along a graph edge. That is, if you want to install Catalyst on FreeBSD 7.0, you may want Scalar::Util x.y, Test::Simple x.y, and Moose x.y.
- Given this metadata, provide a single, installable (source) tarball which bundles all of the nodes of a graph edge.
This is all feasible, if the Perl community has the will to do so.
Some may object that the final two steps may occasionally fail. That's right. You can't solve that problem -- not completely. You can try, but you will fail. That doesn't mean you shouldn't try. It only means that you're a fool for designing a process that can't cope with the occasional upgrade glitch.
Others may object that this does not address the education or the advocacy problem of teaching Perl novices to look for these bundles or system administrations that they're hateful little trolls unless they support these bundles on their system. Nor does it address the technical problem that occasionally plagues installing CPAN modules. Those are solutions for a different post.
One final objection is "What's the point?" or "The Perl 5 release schedule works for me!" or "But you ought to support these bundles for eight to ten years." Those are fine opinions, if wrong, for one simple reason.
The right way to write better software is never to go more slowly.