Can you say for certain that this is not directly caused by a policy of having a contributor license agreement? Have you experienced this on other projects that don't have one? It seems by having a CLA you're limiting your contributors to a subset of developers who are willing to sign one.

(Disclaimer: I personally would discourage developers from signing a CLA unless upstream is paying them to do so, since upstream is going to directly derive profit from it)

It is possible that the lack of useful contributions is due, in part, to a CLA being required.

An alternative would be to instead allow the author to keep copyright but require dual licensing (e.g. both GPL and MIT||BSD) for patches to be accepted into the main branch. The patch meets the GPL requirements, and the company can use the other license when distributing the patch with their own proprietary releases. Does that occur?

Is your main objection to CLAs copyright assignment, or that you prefer licensing to be pure GPL, or something else?

Edit: Rack say “To accept a contribution, all authors of the contribution need to: declare the patch under the CC0 license, or complete a copyright reassignment form, or perform the work under a paid agreement.”

The copyright assignment does make GPL enforcement easier by having unified copyright, since courts might require that the plaintiffs in a case own rights to a certain percentage of the work or the specific bits being infringed. But there are certainly tradeoffs involved and not all GPL-based CLAs do this.

The complication is that, if you received the source under the gpl, then you must release your patch under the gpl, too. But I think this can be worked around by the company licensing the source to you under a different license, that allows only submitting patches.

So basically, you effectively submit the same patch twice: once under the gpl, based on the public gpl'd code, and a second time under a proprietary license, based on the same code, offered to you under a proprietary license that exclusively allows sending patches.

Do you think there'd be ways to reduce (or at least assess) the time costs you encounter when accepting contributions, to the point where they'd be more manageable?

Enthusiastic developers can join a virtual meeting (on Discord and/or https://codeshare.io/ or something) where they, I, and anyone else who wants to spectate can discuss a feature from the idea phase all the way to the phase where everyone's personal tasks are designated. A 2-hour meeting is usually all that's needed to start 2 weeks of efficient offline development.

Drive-by PRs by people I've never talked to? Always a mess and never worth the time for me to even read, in my experience. It's odd how the commercial software world has developed this nearly perfectly efficient environment for teammates to work together, and it's completely ignored for many open-source projects.

tl;dr If I wanted to contribute to an open-source project, I'd prefer to work on a major 40 hour feature with the guarantee that my work will be accepted rather than 40 minutes and say "here's a surprise patch, take it or leave it".

I've worked in commercial tech most of my career and agree that industry has done a good job of making software collaboration effective.

Now I'm building applications based on open source software, and (as with commercial development using OSS) sometimes that means that clearing roadblocks or improving application functionality depends on making upstream changes.

I tend to be a bit reluctant to spend time in meetings because I find text-based conversation easier and more accurate.

Also since there are multiple dependencies and projects involved, it's tricky to divide time between developing all of those relationships. It's still valuable to do, certainly, but it can be challenging.

In this scenario, the approach I've adopted is that I'll spend time to fix the problem 'locally' (in a fork if necessary), offer the patch upstream (to feed back improvements, which aim to be generic -- but also with selfish motivations to reduce maintenance burden), and then move on.

Anecdotally, that's working fairly well so far - approximately an 80% merge rate over ~100 pull requests. I don't have great stats on how much time was spent on each, nor how complex each one was. A few definitely took some detailed puzzle-solving and investigation.

I checked out VCV rack when it was posted to HN the first time, and it seemed like a cool toy at the time. I'm blown away by the ecosystem that's built up now. Absolutely phenomenal.

You could just ask for the copyright to be assigned to your company, no? Or is this a precaution against liability from people sending you code they don't actually own?

edit I see I'm late to the party: https://news.ycombinator.com/item?id=24678007

SolveSpace (https://solvespace.com/), 2D/3D CAD app, actually also is dual licensed (GPL+CLA Sign).[0]

Initially SolveSpace v1.x was commercial proprietary[1] (including v1.8), since v1.9 it was unrestricted freeware proprietary[2] and later v2.0 released as FLOSS GPL-only licensed[3].

Few years ago CLA Sign was added by a former maintainer[4] (who bought rights for commercial/proprietary usage of SolveSpace project code from Jonathan Westhues[5]) and now it is riqured to sign CLA for contributing to project source repo on GitHub which is fully covered by GPL license[6] — this is a sorta of something wired looking for me, but idea of dual licensing (such as used for SolveSpace, VCVRack, Ardour, etc.) actually is maybe the best compromise between FLOSS & commercial proprietary software worlds.

[0] https://github.com/solvespace/solvespace/blob/master/CONTRIB...

[1] http://web.archive.org/web/20111228141027/http://solvespace....

[2] http://web.archive.org/web/20121126031632/http://solvespace....

[3] http://web.archive.org/web/20201004063615/http://libregraphi...

[4] http://web.archive.org/web/20201005020156/https://github.com...

[5] http://web.archive.org/web/20100109235957/http://cq.cx/index...

[6] https://github.com/solvespace/solvespace/blob/master/COPYING...