The value of drive-through contributions

It's not just you. Someone drops a patch at my doorstep and walks along. The patches tend to be simple bug fixes, not huge code dumps accompanied by future maintenance costs. What's not to like about it?

Of course, if someone requires days of hand-holding to submit a typo fix, that's something else. I wouldn't think of those cases as drive-through contributors, though.

I think it's easy for a project to fall into the grey area between "actively discouraging the drive-through contributor" and "making it always an easy and good experience for them", though. For instance, QEMU (which I'm involved with) gets some things right (we have a detailed "how to send us patches" document on the wiki), but some things not so right (we're nowhere near having any kind of "SLA", and if you're unlucky and your patch is in one of our unmaintained areas it's likely to go un-dealt-with unless you prod us several times and do a lot of the legwork in demonstrating that the patch is good). I think moving out of this grey area requires an active investment of time and effort from people in the core community, so it's not surprising if for many projects it gets starved of attention compared to the the work those core developers' employers are typically paying them to do... (I keep meaning to have another look at what we're doing here with QEMU, though, perhaps this article will be the nudge I need to actually do that.)

«The conventional viewpoint among open-source projects is that drive-through contributors are problematic», seriously? Most free software projects I know tend to boast about how many contributors they have and consider as many people as possible in the count, thereby giving value to the casual contributors as well. The fact that most software projects have a small base of (real) contributors is usually used as (misguided) argument by the enemies of free software.

As for a SLA approach, that's an important step to take, however it comes with issues: 1) it requires someone to be "forced" to do the work mandated by the policy, which usually means you must have employees working on it; 2) CVS and issue tracker software (let alone mailing lists) may be unable to answer the question "is there a question/report/patch which is still unattended after X days?" (for instance bugzilla is able to tell you such a thing, but less mature issue trackers aren't: https://phabricator.wikimedia.org/T76825 ).

The classification of the 4 main kinds of drive-through contributions was interesting, but also likely to be based on a small sample of projects. Can someone point to some research on the matter? I can find some research on Sourceforge or FLOSSmetric datasets (mostly ancient), something on the Eclipse and Mozilla bugzillas and something on i18n for a few hundreds projects, but little systematic and wide-ranging research on recent evolutions. Maybe http://doai.io/10.4018/ijossp.2012100101 , http://hdl.lib.byu.edu/1877/etd4996 , http://hdl.handle.net/10612/1796 are interesting but skimming didn't point to anything specific.