People often wonder how to get involved in open source.  It’s pretty easy, really: there’s more work to be done than people to do it!

It can also be surprisingly easy and pleasant.  Here’s how I dove in, and without spending a lot of time, did something to improve the situation of an Erlang Postgresql driver.

A few months ago, I realized that some code I was using at work, Will Glozer‘s Erlang driver for Postgres, was not really being updated much, and the Github ‘fork’ graphic looked like a bunch of messy spaghetti as everyone forked and patched and hacked, but never contributed anything “back” to any place central.

It was obvious there are some bright people doing good work, so the talent and will (no pun intended!) were not missing, but a central repository was.  Github is nice in a lot of ways, but one thing I think it fails to do in some ways is encourage community, although they have continued to make improvements over the years.  It is a great tool, but open source is about more than source code: it is fundamentally about people interacting in order to produce software.  Forks and pull requests and patches and all that are nice tools, but they can be dispersive, in that they often seem to be small individual efforts that are just thrown out, with little coordination, and little ongoing effort.  That’s not necessarily a bad thing: lots of people get started with little fixes here and there, but you still need a group of people at the heart of a project who consider and decide what to include, when, and why.  Overwhelmingly, the language for that is English, and the place is a mailing list or forum built around the idea of people talking, rather than patch management.

In a moment of pique, I decided that it was a shame to see a small but useful project like epgsql wandering and neglected, so here’s what I did about it.  Most of these steps are things you can do to improve some open source software you use and love but know is suffering from lack of attention.

• Luckily, the project was in a pretty good place: it does most of what it needs thanks to Will’s original work, and a big rewrite by Anton Lebedevich some time ago.  That’s where the hard work was, and those guys deserve the real credit for the code.  That makes being a caretaker feasible.
• I wrote an email to the main Erlang mailing list: http://erlang.org/pipermail/erlang-questions/2014-February/077290.html – it was a bit curt, but generated some interest.  Postgresql is pretty popular among those in the Erlang crowd using relational databases.  They are both projects where robustness and correctness are important.
• I created an “epgsql” organization on Github so that the code was not merely something that was “davidw”‘s, but had a neutral name.  Hopefully others will continue working on it in the same place if I am no longer able to.
• I created a Google Group: https://groups.google.com/forum/#!forum/epgsql – Google Groups are a great way to create something that’s easy to manage, and very accessible: people who prefer email can interact with it just like a mailing list, and those who are more casually interested, or prefer the web can use it as a forum.  They’re free, very easy to set up, and are reasonably flexible.  For larger projects, perhaps being beholden to Google is not such a great idea, but one of the key points with improving epgsql is that it not interfere with my work by taking much time.
• I sought out people who had done some interesting work with epgsql and invited them to take part in the group.  There are now several of us with commit privileges.
• I try and get people to spell out their patches in as much detail as possible, and respond quickly to get some dialog going.  I try and involve everyone in the group in what’s going on, as much as possible (we’re all busy), because I really want this to be a group project, not something that starts and stops with me.

So far so good, I’m happy with the improvements that have been submitted over the past few months.  Now, here’s the thing: I would not consider myself an expert with Erlang, and didn’t know much at all about Postgres’s binary communication protocol, but have managed to pick up enough of the latter that I basically get how things work.  So in order to do a good open source deed, you don’t need to be the best or most knowledgeable person out there, you just need to put in a little bit of time.