I migrated one of my CPAN distributions to Dist::Zilla yesterday. This seems like a little thing, but all of the Dzil plugins I use in the distribution remove one small step from managing the distribution. I don't have to update version numbers. I don't have to update the README file. I don't have to worry about copyright information, or specifying dependencies, or keeping my metadata files up to date.

I don't even have to use the PAUSE website to upload a new distribution.

In similar fashion, I migrated that distribution to Github. Moritz Lenz had found and fixed a couple of bugs. I'd already set up the distribution such that test cases were reasonably easy to add, and the code was simple enough that the fixes were fairly obvious. Moritz forked my distribution from Gitpan.

I had my own Git clone of that repo, where merging Moritz's changes took a couple of commands. Releasing a new version with those changes was almost immediate. After that, I converted my personal SVK over SVN repository to Git, made my own Git repository on Github, and cherry-picked the commits from my original fork to my new repository.

I never lost history. I never had to edit a conflict. I never had to ask Moritz to resubmit a patch. The only distribution editing I did was to remove unnecessary files from my repository and to ask Dzil to generate them.

I knew all of the existing behavior of my distribution continued to work, because all of the tests passed. I knew my distribution would work properly with PAUSE and the CPAN because all of Dist::Zilla 's tests worked. I also know that if any problems arise, the difficulty of fixing them is solely the difficulty of finding and fixing the bugs, not of managing the process of fixing the bug and managing repositories or verifying previous behavior or wrangling uploads or editing metadata in files manually.

The distance between fixing a bug and distributing a new version to users has shortened, and that path is now smoother.

You don't have to use Git or Github or Dzil or Perl. Plenty of other good tools exist to manage complexity or to make complexity go away. Yet isn't that what we should do as programmers? We find barriers and difficulties and obstacles and we eliminate or minimize them, not solely because the new versions have a novelty factor or have greater elegance and aesthetic appeals, but because the relentless process of simplifying removes artificial complexity and structural scaffolding that all too often distracts from the real problems we need to solve.

After all, Moritz and I want to publish an attractive, informative, readable, accurate book about Rakudo Perl 6. Software is just the means by which we do so.