[palata]

I have done a lot of open source and I disagree.

The problem being that as a maintainer, I refuse most contributions. Not only because they are low-quality (it happens), but also because they are often out of scope, or I just disagree with the direction. It's my project, I maintain it, I choose what goes in it. But you're free to fork it with your changes, that's exactly why I made it open source. If you make an interesting fork, I may totally import some or all of your changes! And if you first ask in an issue, I may offer you to open a PR directly.

I almost always use copyleft licences: it makes it mandatory to share the modified sources with the user, who can then upstream them.

Many times in companies, if I need to patch a permissive dependency, my company will not allow me to spend time upstreaming my patch. Whereas if it is a copyleft licence, I can tell my manager that I am obligated to open source my changes (which is not correct, but managers usually don't know that, don't care so much about the nuance, and anyway it's a win if we follow the copyleft conditions to the letter).

[gchamonlive]

I'd argue all merge requests matter, not only those that were accepted upstream. Sure, only those accepted generate value upstream, but there is a lot of byproduct from a rejected MR that still has value, either as a reference for further discussions or as resource for forks.

[lowbloodsugar]

Surely the value of patching upstream is so you don't have merge conflicts for eternity?

[palata]

Oh yeah, that's for sure.

But my experience has been that most managers are not competent in that regard. If you have a good manager that understands that, then that's great. But it's rare. Most of the time, it works better to bullshit them with the legal consequences of not allowing you to upstream your changes.

Again, that's my experience.

[em-bee]

i'd tell them, i we don't get the changes upstream then we can't ever upgrade to their new version.

[palata]

Which is bullshitting them, right? You can upgrade and re-patch.

[em-bee]

no more than claiming that we are legally required to upstream the patch.

the argument is though that repatching is work, and especially it's the kind of work you do not want to be stuck with while you upgrade, because if you forget to do it ahead of time, which is likely to happen, you end up with a potentially large downtime or an unexpected delay in the upgrade process.

in other words: the actual truth is: we can't upgrade unless we reapplied the patch to the new version. basically, it is about making the re-patch process appear as dramatic and disruptive as possible.

the leaders can't deny the possibility, because the code that is patched could change dramatically, to the point that you have to redo all the work from scratch.

i am actually stuck in such a situation with one of my projects. i need to merge two branches that were created some time ago causing a divergence that would have been easy to deal with, had i properly merged the branches at the time. now the merge will take as much effort as the original development.

as developers we all know this of course. the challenge is to explain this to the leadership in ways that they can understand.