This is a followup to SupportingVsForking, where I talked about the difference between supporting some open source code and forking it being whether you could get your changes accepted upstream. One thing that is not widely understood is that getting bugfix changes accepted upstream is hard work at the best of times, with a cooperative upstream.

(We can see this from how many private changes to the Linux kernel each Linux distribution maintains.)

The problems are many. Often there is a conflict between the expedient way for you to fix a problem now and the 'right' way to fix the problem, which the upstream is going to argue for and which may require quite a lot of development (and arguing with developers); sometimes the upstream won't even know what the right way is, but they'll know that your way is the wrong way. In some cases, you and the upstream may disagree about whether there is a bug and (if there is a bug) where it exists and what exactly it is. Some times the upstream may accept that there is a bug but feel that fixing it is too disruptive at the current time.

(And all of this assumes that your proposed change is good code. Sometimes it isn't; the most common case in Linux is new hardware drivers, which often contain code that varies from the merely bad to the outright wretched. A distribution often needs to support the new stuff soon and didn't write the drivers; the upstream needs to have code that can be maintained over the long term by people other than its original authors.)

All of these translate to 'thanks but no thanks' for your bug fix or change, which means that you get to maintain more code for a while.

It's worth noting that accepting downstream changes is work for the upstream too. Many of these problems require an investment of time from upstream developers to read code, debate approaches, investigate problems, and so on, and the time of upstream developers is in limited supply. Plus, things like code reviews and arguing with people about whether something is the right approach or is actually a bug are not very rewarding or fun activities, which makes it harder to persuade developers to do them.

(All of this goes even more so if you are adding features or removing limitations instead of fixing bugs, because those raise much larger questions of whether they should be done at all and if your approach is the right approach.)