Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay.
The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them.
Most maintainers err on the side of controlling too much. Which makes them into bottlenecks.
One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.
Bad commits can be easily reverted. Whereas giving people a bit of trust often inspires them to help more.
Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.
Code style, inconsistent APIs, a feature that's barely tested by its own contributor, introducing dependencies on innards that were planned to be removed by an ongoing refactoring project, etc. So many ways contributions can go wrong.
The entire context of this thread is that adding committers can introduce risk in the quality of accepted contributions. Building a trusted network of gatekeepers is hard.
"Style" is more than indentation - my favourite example is something I worked with very closely, but always needed a cheat-sheet on my desk - the PHP arrays api.
Just look at the docs for array_search and array_replace.
This is much worse in managed memory languages - do you allocate memory, who frees it, who can use a buffer in zero-copy mode, who can't ... whether the functions are always re-entrant.
All that said - any originating coder who burns out due to support issues, killing the community is measurably worse off than someone who has thousands of users who demand that you support such "legacy" APIs for another six months.
I'm talking here about a developer API that is extremely flexible and extensible. Even one-liner contributions can have bad effects, and virtually all contributions I receive "work" at a superficial level and if they provide tests the tests usually pass. "made it through testing" is a low bar, the bigger implications of a patch need to be considered.
Examples of PRs that "work" exactly as intended yet are the wrong way to solve the problem:
if I had released that fully and the whole world coded to "mysql.insert.values.bar == 5", that's broken API since it breaks the values() method. Backwards-incompatible fix required.
"a bit of trust" this! Most often maintainers ego is the issue and too much control over ones baby project is the road to frustration and burnout. The way the power is shared and the shape of community structure is huge factor often neglected by tech-only focused maintainers/owners. There is a good piece of wisdom on social aspect of open-source in Social Architecture by Pieter Hintjens[0]. I recommend learning about his pov to anyone interested in open-source open-projects.
My policy is to never ask, and to only accept if I think I can be worthy of the work at the time (so I might accept at a later date if I feel I don't have the bandwidth today).
A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master
We kind of did this with a project I was working on once. Someone was being helpful, main maintainer was getting tired, so helpful guy got full rights to the repo. He went on a several-year-long frenzy of activity, up to being a release manager, putting lots of micro-optimisations into the code and still being generally helpful until he got sucked up by Google and vanished.
Sadly, lots and lots of little bugs and awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code.
I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.
Would the project have had much development at all without the "helpful guy"? If the maintainer was too tired to even keep an eye on him/her, then it sounds like the project would have stalled without that help.
> One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.
In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.
The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them.
Most maintainers err on the side of controlling too much. Which makes them into bottlenecks.
One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers.
Bad commits can be easily reverted. Whereas giving people a bit of trust often inspires them to help more.