LWN: Comments on "The value of drive-through contributions"

Conventional viewpoint?!

micka — Sat, 04 Jun 2016 22:15:34 +0000

Ah I though I'd read about the rebasing of Libreoffice over the ASL release of Apache OpenOffice.
I (incorrectly) assumed the work was done and finished but apparently it wasn't.
Another error I made: it wouldn't have allowed to make LO ASL as new contribution wouldn't have been included.

Conventional viewpoint?!

Wol — Sat, 04 Jun 2016 18:12:43 +0000

> libreoffice is actually under dual apache/MPL

Actually, no. LibreOffice is NOT Apache, which is why LO can take advantage of OOo code, but the reverse is NOT true.

LO is dual-licence LGPL/MPL

Cheers,
Wol

The value of drive-through contributions

ballombe — Wed, 01 Jun 2016 12:58:48 +0000

> 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?

What happens to me: the patch comes with no explanation of what it is supposed to improve, subtly breaks backward compatibility in corner case, and is slightly off the coding style.

So yes, I can try to guess what this is all about, fix it not to break compatibility, and still not be sure the result fills the submitter use-case.

A bug report with no patch is more useful than that.

Conventional viewpoint?!

micka — Tue, 31 May 2016 18:13:55 +0000

Not at all. The only formal definition of open source (the OSI one) give exactly the same rights and guarantees (apart maybe some minor nitpicks on either side of the useless argument).
The FSF is not a good reference either, one of their license (GDFL) is not free using either definition.

Conventional viewpoint?!

lgeorget — Tue, 31 May 2016 15:27:15 +0000

The difference is clear for someone who wants to reuse the code.

An open source license merely gives you the right to check out and audit the code, a free software (per the definition of the FSF license allows you to use the code, modify it, redistribute it (including in its modified form), etc. : https://www.gnu.org/philosophy/open-source-misses-the-poi...

Even if probably most open source software out there qualify as free (I guess), that's not quite the same thing.

Conventional viewpoint?!

micka — Tue, 31 May 2016 09:21:27 +0000

I don't know, I don't make a difference between 'free software' and 'open source'. I just see the second one as a way to not have to explain the 'free as in free beer v.s. free speech' thing (not a problem in my language, the confusion doesn't exist).

For open/libreoffice, if what you're thinking of is the license, libreoffice is actually under dual apache/MPL and openoffice is (I think) only apache. Would you care to detail what you mean here?

Conventional viewpoint?!

flussence — Mon, 30 May 2016 19:46:19 +0000

> «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 […]

Maybe that's simply another point in the distinction between “open source” and true free software projects? Compare Op*nOffice and LibreOffice for example - the latter group *chooses* to be open, the former is merely *obliged* to be by the license it inherited, and the atmosphere around each one couldn't be further apart.

The value of drive-through contributions

dps — Sat, 28 May 2016 00:08:42 +0000

I have been partly responsible for two separate drive-through contributions to the linux kernel: both where critical bug fixes done in connection with my day job. An explanation of the bug was included in both cases. The actual fix was different in detail, but not in principle, from my original one in both instances.

My day job did permit any serious kernel development except for critical bug fixes, so doing more was unfortunately not possible. I like to think that some other people benefited from not experiencing the bugs :-) Both bugs only affected heavy server hardware which is too expensive for a personal box.

The ability to get the bug squashed and move on was valuable, and one of the nice things about open source was we could produce an interim fix, and upstream squashed be bug quickly.

Conventional viewpoint?!

Nemo_bis — Fri, 27 May 2016 20:13:57 +0000

«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.

The value of drive-through contributions

pm215 — Fri, 27 May 2016 15:33:45 +0000

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 value of drive-through contributions

lsl — Fri, 27 May 2016 13:50:29 +0000

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.

The value of drive-through contributions

jezuch — Fri, 27 May 2016 09:30:08 +0000

Everything here's spot on. In fact, it's so obvious to me that I find it hard to believe that anyone would think of drive-through contributors as "waste of time". Maybe that's because I'm an occasional drive-through contributor myself :) See, I have to work with some Open Source projects in my $DAYJOB (who doesn't nowadays?). They invariably have bugs. I used to import the sources of the project in question into our repository and fix the bug there and maybe submit a bug report upstream - but it unnecessarily increases the size of our internal repository, it reduces the incentive to work with the upstream and is Just Wrong(TM). So now I immediately submit the fix upstream and endure the pain of waiting until it is included in a public release. And the most important thing is that *this is how it's supposed to work*. Open Source is supposed to be open to *everyone*, and *especially* those that just have an itch to scratch.

> "But I don't care how many X's they have; if they act like an asshole they're bringing everybody down."

OK, let's call it a "Brasseur Multiplier" or "Brasseur's Law": if a 10X developer detracts 20 1X developers, the 10X developer is in fact the -10X developer. And that's why we should not tolerate assholes just because they are good developers.