The pull request easily the best process to emerge around distributed version control systems, themselves easily the best thing to happen to version control, and one of the better things to happen to software development in general. What makes pull requests so powerful is that they make it stupidly easy for software authors to integrate improvements to their code. Moreover, distributed version control makes it stupidly easy for me to just make their code do what I want instead of cajoling them into doing it.

Instead of begging in email lists, forums and bug trackers, trying to keep repositories synced, and sending diffs around, you just:

  1. Fork the author's repository on GitHub or BitBucket
  2. Fix and/or augment the code
  3. Write a test to prove it
  4. Push the repository back
  5. Issue a pull request to the author to merge your changes.

If your changes don't suck, and the author isn't a knob, you will get your changes integrated. Bonus: an unwritten rule, baked into the infrastructure of the system, is that you're not on the hook to maintain them. We're talking about a one-time effort to irrevocably shape a tiny corner of the world in your image.

Here is a list of open-source software—so far only Perl modules—that I've augmented this way:

XML::LibXML::LazyBuilder
This is basically Perl's answer to Python's lxml.etree, i.e. taking most of the work out of writing XML. The only problem is that it couldn't do namespaces or create things like comments or processing instructions, severely hampering its utility. So I fixed it.
RDF::Trine
The premier Perl RDF framework exhibited some funny behaviour in its parser, so I fixed it.
Text::vCard
This library for handling vCards didn't automatically encode or decode base-64 for things like images, so I fixed that.
RDF::RDFa::Parser
This RDFa parser had some nasty bugs that were introduced with newer versions of it dependent libraries, so I fixed them.
XML::LibXSLT
The go-to Perl XSLT processor didn't expose the output_method function which was in the C API, so I added it.

A Note on Etiquette

Often the most compelling argument on how software ought to behave is to Just Fix It™ and ship the code. This isn't to say, however, that we should expect that authors should cooperate just because we wrote a patch. Plus, as an assurance that what you've written isn't garbage, and to further abridge the effort on the part of the original author, it is essential to include unit tests that cover your changes.

I Am Having Fun With This

The inception of collaborative development sites and the pull request has inspired me to don the hat of the open-source developer more often than I had expected. I am finding myself not only gaining materially from doing so, in the form of abridging my paid work, but also having a direct hand in making things better for everybody, which I appreciate.