@meowray FWIW, strongly disagree here.
I think it is entirely possible to have quality, velocity, and open contribution.
I'm not saying there isn't a tradeoff, but I think the above three can be preserved sufficiently.
For example, in LLVM, I think the bigger challenge than quality is that people view "contribution" as _much_ more about "sending a patch" and not "reviewing a patch. As a consequence, the project has lost community and cultural prioritization of code review as an active and necessary part of contribution.
Also, "open contribution" doesn't mean you _have_ to accept contributions. I think a project can still have meaningfully open contribution while insisting contributors balance their contributions between patches and review, and where contributions that are extractive are rejected until the contributor figures out how to make them constructive.
IMO, criteria for sustaining both quality & velocity in OSS:
- Strong expectation of _total_ community code review in balance to _total_ new patches -- this means that long-time contributors (maintainers) must do _more_ review than new patches.
- Strong expectation of patches from new contributors rapidly rising to the quality bar where they are efficient to review and non-extractive.
- Strong testing culture that ensures a large fraction of quality is mechanically ensured
- Excellent infrastructure use to provide efficient review and CI so tests are effective
I think LLVM struggles with the first and last of these. The last is improving recently though!