I believe this project is important to the future of Perl 5. It has several parts:
- To encourage new developers to work on the Perl 5 core (internals, ecosystem, and libraries).
- To improve documentation and processes to make improvements to the Perl 5 core.
- To experiment with new features and design decisions.
- To clean up the internals.
- To mentor new and recurring contributors.
- To take some of the burden off of the overworked, underappreciated pumpkings.
I see corehackers as the other side of the important perl5i project; important features perl5i identifies and stabilizes can come into the corehackers tree (or forest, I suppose) for further experimentation without destabilizing the main development trees for Perl 5.
This is a huge benefit of Perl 5's switch to Git last year, and I'm glad to see Perl 5 development take advantage of it.
One of the obvious inspirations is the Linux Kernel Janitors project, which has performed similar functions for the Linux kernel.
The project is in its early stages. You can fork Chip's own bleadperl repository on GitHub and experiment with making changes. The IRC channel is active (if a little bit scattered; it's not clear exactly what's happening when, so you have a chance to guide it to your desires and expectations), and there are plenty of people interested in experimenting with all sorts of pent-up ideas.
In particular, I'm most interested in cleaning up some of the internals to make them more readable, more optimizable, and more amenable to further extensions and enhancements such as compiling Perl 5 to LLVM. A 30% performance improvement is likely, with few changes.
I've personally forked an experimental Perl which enables
strict unilaterally, unless running with the
-e flag, without having to
use any module. I'll write more about that soon.