In Praise of Forking

If we are to write ever better software, we must relentlessly remove barriers to collaboration. The gitPAN is important for that reason.

When I worked on Perl Hacks in 2005, I needed a way to show off the "stuff a code reference in @INC" feature without making an obviously silly and contrived example. I chose the very real problem of wanting to know which piece of code loaded which module. This is handy for figuring out dependencies in a program, especially when you want to trim memory usage or reduce complexity.

The resulting code became Devel::TraceUse.

Perl 5's code-loading semantics aren't entirely simple nor straightforward, and the introspection capabilities of D::TU need to reflect that. The module had some bugs and corner cases, and it didn't support some uses I never considered.

Thanks to Schwern and gitPAN, Philippe "BooK" Bruhat forked Devel::TraceUse on Github to fix bugs and add features. The new version should be on CPAN shortly.

All I had to do as a maintainer was look over his changes, read the test cases, and give him co-maintainer status on the CPAN. If I wanted to fix a typo in the documentation or make a very, very quick change, all I had to do was fork his own copy, make a change, and send a pull request -- all from the browser window.

It helps that I've known BooK virtually for years and I trust his code and judgment. Yet it also helps that we can take advantage of software and services that make forking a positive act, as something lightweight and temporary and creative which we intend to merge again soon.

Sharing code on the CPAN is good, very good. So is tracking bugs and attaching patches. Yet stepping slightly beyond that to make our distribution system into a repository where we encourage modification and experimentation (always with an eye toward merging) is even better.