[bin_bash]

The hard part of OSS management is dealing with change requests. Something comes in and now it's on the maintainer to ensure that the new fix doesn't break anything existing, or the new feature doesn't collide with anything else that comes down the pipe later. It's not work that can be done by volunteers, it's something that can only be done by long-term maintainers.

When I worked on an OSS project I hated getting PRs. They usually wouldn't work for one reason or another and I would have to explain why they were problematic. It took a lot of time out of my day—I would rather people just submit bug reports and feature requests.

[fourthark]

Also it hurts all around to tell a hopeful contributor that their code isn't good enough.

Yes, with hours of effort you can make your review relentlessly positive and constructive, but then it still hurts and they probably don't have the ability to fix it.

You'll have to fix it for them, which is often harder than writing it from scratch.

[jka]

Thanks for writing this; it matches an undescribed feeling that I've experienced for a few codebases.

What I'd add in response is that this "change request load" is much easier to manage for small, well-maintained projects with fewer quirks.

And if the entire project architecture can fit within your mental buffer space at one time, then it's much easier and faster to parry those incoming change requests and pull requests into clear, effective feedback and code.