I think it's a incredibly unfair to assume that I'm not acting in good faith when I send patches upstream. I was contributing to the free software community long before I was getting paid to do so. I spend almost all of my working hours doing upstream maintainership work or writing patches. I have PRs that are several years old and I still am working on getting them merged upstream. I'm also just a developer, I'm not in a position to start spending money on projects on behalf of my employer. I do happen to donate to plenty of upstream projects and foundations, but that's money out of my own pocket.
The issue is that there are some (rare) cases where upstream is completely unwilling to merge a patch for philosophical reasons.
If you want me to be blunt -- the example I'm thinking of is Docker (which doesn't have a cash-flow problem), and has refused outright on many occasions to merge patches that allow for build-time secrets. On SLE we need this because in order to use a SLE image on a SLE machine you need to "register it" and the only way to sanely register it automatically is to bind-mount some files into all containers on-build as well as on-run (which you cannot do with upstream Docker today). Red Hat spent a long time trying to get a patch like this upstream, as did we.
To be clear, I'm not say you personally. I don't know you, or anything about your work so I'm speaking in purely a general sense about a position that you were representing.
I don't think all upstream contributions are in bad faith. I'm just saying there tends to be competing priorities which leads to some instances of hostility.
As for the Docker example, I don't know what the right answer is without digging deeper. My naive thought is to write a SLE/RHEL shim/plugin style component to allow functionality that's missing. This allows keeping the upstream vanilla, while not having to fork into something without the brand recognition. If that doesn't work, forking as `rhel-docker` or `sle-docker` doesn't seem that bad to me. Ubuntu does this with all the bcc-tools.
This is of course predicated on having tried all previous solutions first (paying an upstream developer, work with upstream with a good back-and-forth to incorporate a patch, etc). In the end, if the project decides something against their philosophical viewpoint, they're perfectly entitled to not accept patches. It's at that point, I think it's not the best solution to fork, downstream patch, and release as if it's the vanilla upstream.
The issue is that there are some (rare) cases where upstream is completely unwilling to merge a patch for philosophical reasons.
If you want me to be blunt -- the example I'm thinking of is Docker (which doesn't have a cash-flow problem), and has refused outright on many occasions to merge patches that allow for build-time secrets. On SLE we need this because in order to use a SLE image on a SLE machine you need to "register it" and the only way to sanely register it automatically is to bind-mount some files into all containers on-build as well as on-run (which you cannot do with upstream Docker today). Red Hat spent a long time trying to get a patch like this upstream, as did we.