But contributing to someone else's codebase is tricky. A lot of times, it'll take the owner more time to review your contribution than it would have for them to build it themselves. This is true even if you're a great engineer, because (1) even great engineers need to learn a lot when entering a new codebase, and (2) the owner doesn't know if you're a great engineer so has to assume the worst and review everything carefully.

If the change is a small bugfix, no big deal. If it's a major new feature, even if it's a feature the owner wants, you have to understand that opening a PR isn't necessarily a gift to them.

With Cap'n Proto, I maintain the core C++ implementation. I'm happy to accept small fixes but when people try to implement big new features, yes, it has been rough. I spend a huge amount of my work hours reviewing code for my team, all of whom I know well and were vetted through a hiring process, and I still find that stressful. A random large PR opened by someone I don't know... eek. But I do feel pretty bad about the big PRs that I've failed to review.

On the other hand, if someone wants to build a Cap'n Proto implementation in a new language, it's much easier: they get to own that codebase themselves, do it how they want, and I'm happy to link to them. That said, unfortunately, doing it this way has led to some pretty variable quality in per-language implementations which is Cap'n Proto's biggest weakness.

I meant it more in terms of resources: you seem to be saying that you maintain Cap'n Proto as part of your job at Cloudflare. You mention PRs that you have failed to review, I guess Cloudflare did not need them. And as you said, if Cloudflare had needed them, you would probably have been faster doing it yourself. Which also means that opening those PRs was a loss of time for everybody from the beginning on.

At least that is more and more how I see open source:

- I have to "blindly trust" some projects (e.g. a standard lib, TCP, protobuf) because I couldn't maintain them myself. I try to minimize that and chose those carefully.

- I accept to depend on projects that I could easily fork or replace. I can contribute to those, and if the maintainers ignore me I just fork away.

- If it's small enough, I'll rewrite it myself (using the open source code for inspiration).

Conversely, I behave more and more like this as a maintainer:

- I don't hesitate to tell people that I won't take time to review non-trivial PRs

- I encourage people to fork if they want something I cannot give them

- If people cannot fork and need something I cannot give them, then they are screwed. That's sad, but that's life. I can't burn myself out for them.

I use to say "PRs are welcome!" when people asked for new features. I stopped doing that unless I am really sure I will actually review them.