Instead, the observation is that granting others access to projects has a time dimension: you need to not only find them trustworthy now, but also reasonably believe that they will remain trustworthy. That last part is much harder, and includes things that are partially outside of the other person’s control (like account takeovers, being targeted by foreign and domestic law enforcement, etc.).

I generally think projects should accept more maintainers; however, your point about asymmetry goes both ways.

I hand out code rights freely to those who seem similarly invested. As they can then share the burden for each new issue popping up, etc. However writing the code (the PR) is usually not the hard part in a FOSS project. The fortitude to maintain it is. As the weeks, months and years go by - who will be around?

"Commit rights" here seem pretty off-topic to me, honestly. This is FOSS. Assuming a permissive license, you can fork it and publish your own freely. It's not an insult to me for you to do that.

But yea, if i'm looking for an out - i'll hand them out to anyone interested. If however i'm needing to maintain it for my own purpose, then my time and will are the resources i'm most concerned about. A single PR is not a the only variable in the equation there, imo.

If they offer to maintain it, I’d sooner point my docs to suggest using their fork instead of my repo. That makes them the maintainer without me offering to support what they do

i also believe that code should be reviewed by a second person, if possible. so if i have a one-man project and there is a second contributor, i would review their pull-requests and commit them. if they in turn are able and willing to review my commits, i might give them commit rights as long as we both can agree to review each others commits. in that case, the other person will only commit code i have written, and i will commit code they have written. (or however we set up the process. either way i will still have seen all the code going into the project.)

but i agree with the article. it really depends on the nature of the project. i do have some projects where i am just messing around, creating something useful, but not critical. having others directly commit to that would probably not be a big problem, even if the code they write is messy, as long as it works, it'll be ok.

alternatively, if i do have the time to review code, i can also do that after it has been committed. if it's bad, i can clean it up then. and if there is to much cleanup work happening i can revoke commit rights and i'll only have to remove the most recent commits that i don't have the time to clean up.

I'll believe that when they're replying to issues, labeling bug reports, etc. Hell, or even making PRs that maintain the code base! That would be an instant commit access. Writing new code is easy. Maintaining is tough, boring, etc.

Again, if i even get a gut feeling that this is going to be work - i'd rather just fork my own damn project and give them my old one. I FOSS projects to let others use my work if it's of value to them.

It's a thin line between having fun side projects and work. I think you misunderstand the type of projects i FOSS. If your arguments were common i'd be more inclined to just make projects private, as i'm that averse to wanting more work in life.

I really, really like to keep the fun in my projects.

i do that on projects that i am interested in. because it sometimes is a good way to get into a project and show that i care about the project as a whole, not just getting my patch accepted. and why should i not care? i am using it myself.

to call that virtue signaling as the grand parent comment does, is frankly insulting.

however, caring about a project doesn't guarantee anything.

a while ago i found a nice project that solved a problem i had. it had some bugs that i fixed to make it work for me. i shared the issues and fixes with the project, expecting to do more work later. but then my situation changed and this project is no longer a priority. i hope to get back to the it, but i can't say when that will be. i still care about the project, i just don't have time for it now.

The risk is that a malicious user fakes good commits, earns commit rights, and then pushes malware that is then installed by unsuspecting downstream users before the code is found and reverted.

This can be partially mitigated by making sure they don’t have permission to create a release, but it would still be possible to compromise developers working off the main branch.

I do think being more liberal with commit bits helps a lot more when you have a project you want to grow, that is new, and you have a lot of code that needs to be written by a lot of people, and ideas to explore, and things that even need rewriting. You need the code written, people to use the software, so you know where to further drive improvements. You need people willing to dogfood and rewrite things and fix the thing they just broke.

I wouldn't give commit rights to anybody in that case but, like. If you have a solid history of +5 patches, you have some clear FOSS experience of your own, clearly have skill, and it's early on in the life of the project? I just need the help? Yeah, you could make worse decisions.

I have been on both very established projects of 20+ years where commit rights came months after writing patches, and newer projects where they came days after writing patches because the project was (is) still growing. Ultimately, I think it comes down to having an idea of where you want things to go, and picking out the people who seem to share that idea.