Comment by danShumway

Even when maintainers are super nice, it's work to get a patch into an acceptable state for a project, and at least to a certain extent it's not clear why that work should always fall on the person who's making the patch for themselves.

If a forked repo solves a problem and keeps it Open Source and available, and their solution genuinely is good and useful for the community, then there's nothing to prevent the original repo from pulling their code and reformatting it or adding tests. Upstream maintainers are totally free to go downstream looking for patches. They don't need to ask anyone's permission or convince somebody else to make a pull request. Just copy the code upstream if you care about it.

I've done this in the past with public projects -- fixed a problem, left a quick note on the original repo saying, "hey, I have solution but it's just for me. You're welcome to adapt it if you think it's worthwhile." I've also done the opposite and worked really hard to get something accepted. I've also walked the middle line, where I coordinated with upstream to contribute to an official API, but at the same time made it clear that my downstream fork was going to diverge and stay specific to my use-case.

It's nice for patches to get merged back upstream, and it's nice for patch writers to put in the effort to do so, but part of the point of Open Source is you don't need to wait for that to happen.

I have no qualms whatsoever about maintaining a personal fork of someone else's software. If I'm patching something to solve one of my problems, I'm going to search for a solution that solves it as specifically and narrowly as possible. I'm not going to worry about what your coding style is or what you'd like the API to look like. Then once my problem is solved, if I have time, I'll think about broadening it or altering it to fit with the overall community.

But that's a separate step that doesn't have to be specifically my chore. Anybody can do it.