Avian’s Blog

I like free and open source software and I use it almost exclusively in my day-to-day computing tasks. One of the reasons why I prefer it over proprietary applications is because I can go in and change things. Nothing is more frustrating than when one little bug in an otherwise perfectly fine piece of programming makes it unusable for a task at hand and you can do absolutely nothing about it. Or when you need one feature which you know must be a one-line change and you are left with pleading to some narrow communication channel with a disinterested customer support person on the other side.

Not surprisingly, such tinkering has led me to the current state where many of the programs I use every day are custom compiled with this or that little change I made. Over they years I got good at maintaining these changes in a somewhat painless way (in short, quilt and/or git). But software upgrades are still painful as each upgrade either means dropping my custom patches or wasting time to port them to the new version. This is why I prefer Debian and its slow release cycle for computers I use.

If it's not an one-off hack though, but some application I will use at least twice, I always take the time to roll-up the change in a presentable patch and send it to upstream developers along with a nice description. Having a patch accepted in upstream of course is always better than maintaining my own private version of the code. It means I no longer waste time each release cycle and other people can benefit from my work, which gives me a warm and fuzzy feeling.

The problem however is that very few of these patches actually get applied by the maintainers of the project. In my experience, the best chances are with active, small or one-man projects. Larger projects usually just let such contributions linger indefinitely in the mailing list archives or the ticket tracker. I'm not even talking about them rejecting the patch - in that case I usually take the time to correct any problems maintainers found as that is of course beneficial to me as well. In most cases there is simply no reply at all.

Jono Bacon calls this kind of participation in free software projects drive-by contributions and explains that they are expensive in term of maintainer effort and that communities should strive to convert such random contributors to active members. I can't argue with that logic. Obviously a patch from someone that has an established track record within the community requires less careful review before it is accepted into the official repository. Although the patches I'm talking about are always relatively small fixes and not some big architectural changes that would require some broad consensus from developers.

The problem is that I simply don't have time to be actively involved with every project developing each piece of the software that runs on my computers. I usually join the mailing list of a project I submit a patch to, at least for a while. But for more there is simply not enough hours in a day and I have enough of my own projects.

Another problem are dead projects. Is it better to leave a series of patches in an abandoned public tracker or accept all the overhead that comes with it and release my own version?

Sean Dague praises GitHub as a solution to such problems. In my experience GitHub is a double-edged sword. On one hand pull requests are easy to make and provide a standard and hassle-free way of accepting such contributions from random users. But on the other hand, if a project isn't already using GitHub this leads to confusing situation where you have a network of forks on GitHub in addition to a official repository that may or may not be completely ignored by the original developers. Often researching the fragmented fork tree takes more time than actually implementing the fix yourself and again, it doesn't help much with the fact that you have to maintain your own fork, even with all the magic of git-merge.

I know I'm talking in a very general way about many diverse projects, but that is the general pattern I seem to keep noticing. Each time I get involved in some job that uses open source software I preach how it's important to contribute back to the community and not keep a fork of the code in isolation. But recently I often ask myself if I'm doing something wrong or if it's actually not worth my time to keep trying to contribute quality patches when a quick hack I keep in private achieves much the same result.