Distributed version control changed free software development in ways we're only now beginning to understand. I used SVK for years from the start, and it improved the way I work. (Yes, I committed code on airplanes in 2005. I've forked and patched projects I don't have commit access on. I've done that for six years now.)
These days Git and friends have taken over from SVK, and that's fine.
Two and a half years ago, while helping to brief an influential technocrat about what was actually going on in the world of free and open source software, I repeated a phrase I'd heard elsewhere. "Forking is an act of love."
Today, Github puts the truth to that. In writing a book (could be almost any book, but it's the Little Plack Book in this example), I read a lot of code. I read a lot of code and documentation for a lot of projects and modules. Sometimes I find bugs. Often I get confused. Sometimes I find gaps.
Distributed version control means I can fork those projects into my local repositories and work on them as if I were a committer. Git and Github help, but they're not necessary for other people to use. I could mail patches generated locally. The important thing is that the barrier for me to fork and branch locally and work work work and commit and then contribute upstream is sufficiently low that I just do it.
A nice feature of Git and Github (not solely a feature of either, but a nice feature) is that project maintainers can integrate my changes with relative ease.
I patched the Perl core before the Git migration, in the Perforce days. That was an act of pain before even navigating the internals of Perl. Now only half of that pain remains, and it's the expected pain.
A fork doesn't have to be a bad thing. If it's a small, focused fork and if it's always intended to merge, a fork can be an act of love. Certainly me adding documentation or revising documentation or fixing a bug or adding a feature because I'm there, I'm thinking about it, I have ten minutes, and I can do it and move on is a donation to the project and the greater Perl community and the world of free software because I care about all of those things. (I come across sometimes as a cranky old curmudgeon because I'm passionate about writing great free software. Also, I'm overeducated and tend to amuse myself when I write prose.)
And then.
Sometimes forking is an act of enterprisey customer- and upstream-hating violence, where short-sighted expedience several years ago has succumbed to the staggering sinkhole of deferred maintenance, and ... well, at some point, it seems counter-productive for IBM to continue to call their lumbering Frankenstein's dinosaur monster "Perl", especially if they've hacked in special magic to get it to work.
I suppose the good news is that IBM's customers have paid for that monstrosity, and of course you know money, and commitment, and time, and knowledge are just flowing from IBM to p5p....
Maybe I ascribe too much malice and not enough incompetence. After all, what are the odds that a company like IBM could find spare computing time on a spare machine to give an interested volunteer or two the opportunity even to see what it would take to get a modern version of Perl running on their platform?
Update: With that said, IBM has contributed platform patches to Perl in the past, so why not continue that?
Honestly, in person, you don't come across as that old.
I have used IBM ClearCase and the zombie played a big role in the maintenance of CC. It's a pain to use it though since it's an old version (5.6) that sometime doesn't work with current modules thus hindering full maintenance automation.
Yes, I believe IBM should smack the zombie in the head and upgrade the cperl.
Also, I have noticed Mercury using Perl on their LoadRunner software and after the acquisition of Mercury, HP has upgrade LR to use Strawberry. No sure about the company's contribution to Perl development though.
People in my family are born crotchety.