Stepping Up

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.


> he couldn’t find a decent CPAN module for XML validation

This has a very simple reason that is actually fairly unique to the problem domain: XML is crap. I've recently been in the similar situation of looking for a module like XML::Simple, but less crap, less magical and less inconsistent. Turns out there's none. Wrote one myself and found out: XML is such a damn mess that my solution, while working for my special case, would break in the general case very quickly. I have a rewrite in mind, but it won't be pretty in any case.

So in short: When you can't find a module for a certain task, then it's likely that the task is either one that should not be done in the first place, or is not easily and solvable for the general case.

> he couldn’t find a decent CPAN module for XML validation

XML::LibXML supports validation using both XML-Schema and RelaxNG. Additionally Kip Hampton has a module that implements Schematron under XML::Schematron, Sam Tregar has XML::Validator::Schema which implements a subset of XML-Schema validation, and the BBC have XML::Validate that uses XML::LibXML or Xerces or MSXML depending on what is available for your platform.

That's what I found with a quick search through CPAN by authors (or modules) who's experience with XML I tend to trust.

I'm pretty sure we discussed this on #plack, but your use case for XML (while common) is broken. XML doesn't have, pretend to have, or expect to have a "data model". Every module that tries to force XML to serialize data is going to be fundamentally broken because of this mismatch. That includes XML::Simple, XML::Smart, XML::Toolkit, XML::Pastor, XML::Compile, and hundreds of other XML::* modules on CPAN.

Blaming XML for this however is hardly fair. It's a markup language, like Markdown, Textile, or POD. Would you blame POD for not being able to properly serialize your AST? If you did people would laugh at you.

The fact that it mostly sorta-kinda-works means that you can get some nice benefits. One of my company's recent projects really benefitted by implementing an XML based config that semantically was cleaner than the Perl DSL version. Is it an abuse of XML like I'm decrying here? Yes. But it was cleaner than the alternatives, and the pragmatist in me says "that's okay".

Great post! I have been similarly putting myself into the contributions world (just got my first commit into a core modules!).

I have had a similar experience, most authors are willing and maybe even eager for help, if you are offering help, not just suggestions.

I just took over the terrifyingly complex Zoidberg shell, but even for smaller projects: just get out there and contribute!

Perigrin, you missed the largest part of that discussion because it happened in #web-simple.

The thing is that i was never looking for serialization, just deserialization into a consistent and comfortable format. Deserialization is very possible, just requires some thinking, and is possible consistently too. The difficulty comes in when you try to deserialize into a data structure that's actually comfortable to use.

Just a very small comment on github and issue trackers. I imagine the reason many people have their github issue trackers disabled for cpan projects, is that they prefer to track their issues on, and don't want to keep track of two separate issue lists for the same project. (I have the issue tracker disabled for all my Perl projects on for that very reason.)

While I know it might be Perl sacrilege, but I don't much care for RT. I find that GitHub issues integrate so well, and I almost can't read code posted to RT. To each his own, but I would support a mass move to GitHub issues.

A few links for those who might be interested:

Issues 2.0 announcement

Issue Mentions

Issue mentions in the wild

> but there ain’t no CPAN for Python. ...

You should clarify what you mean by that, since there *are* PyPI, Rubygems, PEAR and npm.

While there's an argument what is the "correct" way to count modules, rubygems has already passed CPAN for the number of available gems:

Leave a comment

About Buddy Burden

user-pic 14 years in California, 25 years in Perl, 34 years in computers, 55 years in bare feet.