Buddy Burden

This week I became co-maintainer of a second module: Test::File.  I now have the privelege of being co-maintainer on modules by two of our most prolific Perl authors (i.e. schwern and brian d foy).  And, as you may have gathered from my blogs thus far, I’m certainly no one special.  What did I do to receive such honors?

Nothing, really.

I just contributed.  I found two modules that I actually cared about, where the existing art was almost what I wanted, but not quite, and then instead of hacking on them in private, or creating my own extension, I reached out to their authors, and I said, “hey, how would you feel if I sent you a patch for thus and so?” and they said “sure, sounds good” and I did, and then I sent more stuff—stuff that I actually needed, not just stuff to be doing stuff ’cause it sounded cool—and eventually they both ended up saying, “say, you seem like you have a strong interest, and you’ve demonstrated some meager ability, and I’m a busy guy ... why don’t you handle the releases for a bit?” and I said “sure, why not?” In this latter case, the entire conversation happened to be held in public, if you seriously cared that much to go read it.

But the point I’m trying to make is, this wasn’t brain science.  Anyone can do it.  You could end up becoming a co-maintainer, or end up taking over an orphaned module like I also recently did.  And I think you should.  Why do I think that?

You know, just the other day a friend of mine (also co-worker, also currently boss) was remarking to me that he couldn’t find a decent CPAN module for XML validation.  (Feel free to point me at one he may have missed in the comments.) He wasn’t necessarily upset by this in the specific case—we’ve all been in the position of not finding something you need on CPAN.  He was commenting more on the big picture presented by this.  Once upon a time, he opined (not necessarily as flowerily as I am waxing here, but you catch my drift), once upon a time, you could find anything you needed on CPAN.  You’d have to be looking for some pretty obscure shit to come up blanks on a reasonably intelligent CPAN search.  It’s not so much the case any more.  Now there are gaps ... perhaps there aren’t any serious gaps yet, but the cracks are showing.  We have to face the fact that we need to break out some putty and start filling in those cracks.

And, don’t forget: CPAN is Perl’s killer app.  It’s been said dozens of times, but I still say it bears repeating.  Python may be cool and all (personally, I swore off whitespace-dependent languages after Fortran, but whatever floats your boat), but there ain’t no CPAN for Python.  Ruby may be elegant and whatnot (with or without the rails), but there ain’t no CPAN for Ruby.  Javascript may be ... okay, look, Javascript is just insane.  Who the hell thought that was a good idea?  Is there anyone out there using Javascript for any reason other than because every browser on the planet implements it?  Objects but no classes?  It’s just weird.  Oh, and there ain’t no CPAN for Javascript.

Now, there are movements looking to start changing that, of course.  But those other languages have a bit of catch-up to play.  We’re out in front, but you know what they say in the marketing biz: you don’t keep a number one spot by restin’ on your laurels.  We all have to put some effort into it.  What can we do?  Simple: contribute.  Step up, help out, take over, keep up.  There is a small number of prolific CPAN authors.  There is a large number of regular-Joe Perl programmers like you and me.  Let’s rebalance that tree.

What is holding us back?  Well, I talked about this a bit on my other blog, upon the occasion of releasing my first CPAN module.  Inertia, procrastination, apprehension, perfectionism.  Blah blah blah.  Screw all that.  Just release something.  It doesn’t matter if it’s any good or not.  There are these constant rants by people about how CPAN is full of crap (there was one recently on module-authors, which I refuse to link to because of its inanity), but screw those people: a lot of that crap is composed of first attempts by people who later went on to do great things.  You know the coolest thing about crap?  It makes awesome fertilizer.

So put something out there.  Uploading a new module is good, and I encourage people to try it, but I’ve got to tell you: it’s a huge pain in the ass figuring out how to get started on that.  Not because of a lack of tutorials on it: rather because of a plethora of tutorials, all of which say something different.  I may relate my experiences on that, because I think I may have tried them all at this point, but I want to make sure I have something useful to say on the topic instead of becoming just one more tutorial with a different take on things.  As Voltaire (supposedly) said, “It is far better to be silent than merely to increase the quantity of bad books.”

But you have another option besides creating and uploading your own module: you can submit a patch, you can add a feature, you can fix a bug.  You live in the era of git, and GitHub, and that makes it easier to do than ever.  (There are lots of articles on why that is, so I won’t repeat that here.) MetaCPAN has come along, and now you can often just hover over the “Clone repository” link on the left side and get a direct link to the repository where the code lives, be it on GitHub or elsewhere.  Assuming it is on GitHub, you can (usually) just hop over there and open an issue.  (A plea to GitHub authors: please make sure your “Issues” tab is turned on—just click that “Admin” button if it’s not.  Finding the code on GitHub and not being able to submit an issue on it really derails the whole process.) Use that issue to talk about what you want to fix or change—note that I did not say to talk about what needs fixing or changing!  Always approach it from the angle that this is work that you are willing to do.  (And, if you’re not willing to do it, go back to the top and read this blog again, because it obviously didn’t take the first time.) Tell the author that you’ve put in the effort to see where the problem is, or where your new feature could be added.  Show them that you’ve taken the time to read their documentation (yes, all of it, now matter how long-winded they are) and you’ve grasped what they want to achieve with this module, and you know that what you want to do isn’t contrary to that.  Demonstrate that you’ve put in the time and effort to search elsewhere for solutions and you’ve still come to the conclusion that this is the right place for it.

Then wait for a response.  You want to make sure the person agrees with the fix or feature and is willing to include it in their module.  If they aren’t, then maybe you want to look at working on a subclass or plugin or extension to their module instead.  But, you know what? that’s the exception, not the rule.  Generally, they’re happy to have someone else taking an interest in their baby.

That’s what your module is, you know.  It’s your baby.  You’ll always be proud of it, even when you know it could have turned out better.  You’ll always be a little touchy about other people messing with it.  brian d foy compared giving me co-maintenance to giving me the keys to his car.  And, you know, when you drive another person’s car, you better show some respect for it.  You better make sure you understand what it needs, and what its quirks are, and where all the controls are (’cause sometimes the windshield wipers are in a weird place or something), and whether you need to goose the accelerator when you’re stopped at a red light, and whether that yellow light on the dashboard comes on all the time and it’s no big deal, or whether it means pull over RIGHT NOW!  In other words, when I start working on someone else’s module, I adhere to their coding standards (even if I think they’re insane), and I make my POD style match theirs (even if I think it’s bizarre), and I organize it and comment it the way they would (even if I don’t understand it).  To break out another analogy, you want to leave the campsite as clean as you found it, at the minimum.  Preferably cleaner.

And you put in that effort, and you become a contributor.  Maybe the author will ask you to be a co-maintainer.  Or maybe not, but that doesn’t matter.  The point isn’t to become co-maintainer so you can get on your blog and go “ooh! ooh! I’m a co-maintainer now!” That’s not what this blog is about.  Really.  The point is that you’re doing something to make CPAN a better place, and to make someone else’s life easier.  They’ll tell you how you can best do that.  Typically, they ain’t shy, so don’t worry about that.  As long as they’re happy with your contributions, you’re doing something positive for CPAN, for us other regular-Joe Perl hackers, for everyone.  And that’s what it’s all about.