Drive-by contributions

28.07.2012 21:52

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.

A bunch of rusty gears.

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.

Posted by Tomaž | Categories: Life


I work in both small one-man projects and bigger ones. It's harder to track all the patches for a big project. With stricter rules (coding style and so on), more complex codebase needing people knowing the right part of the code to review the patch, and more users than developpers (so more drive-by patches being made), a huge backlog of waiting patches tend to build up, which is hard to sort out. Patches get outdated and out of sync with the main codebase and it needs a lot of work to merge them back. The faster moving codebase because of more devs doesn't help with that.

Github at least helps with out of sync patches. It's easier to update and merge them. But the swarm of patches that can result isn't very nice either.

Smaller projects are easier to manage. The patches usually can be merged faster.

As for dead projects, I did adopt some myself, if only to put them in a place where patches can be merged (and without doing further development on them). That is not so much work, and I think it's worth it. Look at the example of Jam: this build system formerly devleopped by Perforce isn't updated anymore, and now we have forks for the Haiku project, for Boost and for Freetype, each with different features, and no plan to merge them back. It would have been better to host it up somewhere and share it, it would likely have more users that way.

There used to be an "unmaintained free software" wiki where one could put dead projects, but it seems to be closed now. I host my own page for BeOS/Haiku software : . As you can see, there is some success to this approach. I even got some old closed source projects open sourced so I could resume work on them.

Yes, this does use quite a lot of my time, but things are improving, and a lot faster than if I (and others) had been making only closed source tools.

Great article, Tomaz, and you are doing great open work on various fields. Just stay open as long as you can and always reconsider your experience leaving Zemanta. Nice observation about one-man project. It is easier to understand another brain than team thinking. Except women :-)

Posted by MMM

Add a new comment

(No HTML tags allowed. Separate paragraphs with a blank line.)