1. 24

  2. 8

    I agree this is a worthy goal, but there’s a good reason it isn’t the norm. The incentives are usually strongly aligned against this. Often, fixing something downstream can be done in a few minutes. Whereas pushing a fix upstream will typically involve things like:

    • More deeply understanding the system you want to fix. This can be hours or days of work.
    • Creating a PR which goes through iterations of CR and discussions.
    • Delays in the PR process / non-responsiveness.

    Granted, all this work will then benefit others besides yourself, but you are still bearing the cost. As long as that remains the case, this rule will continue to be broken.

    As an author, things you can do to mitigate these counter-incentives:

    • Writing code that is well-documented and easy to understand
    • Having a low-friction contribution process
    • Being responsive

    And of course, those things are more work for the author.

    1. 6

      Type Safety Back and Forth is an earlier exploration of this choice.

      1. 6

        Prefer to push fixes upstream instead of working around problems downstream

        I wholeheartedly agree with this advice and the rest of the post. However, I think you should do both. If you have to solve a problem, you need a short-term and a long-term solution. Yes, the long-term solution is pushing the fix upstream, but until your PR is accepted and released in an official version, you need to have a solution, and that is why you most likely also need the workaround downstream, unless you have time to wait. Bonus points if you achieve a seamless transition between those two solutions.

        1. 3

          Yeah, I think this effect is particularly pronounced when the issues are in the operating system or some base infrastructure software that is generally deployed on a totally separate time scale from the upper-level software by many users. That is: if there is a bug in a publicly used library (e.g., libc) you want to fix it in the OS, but you also probably need to work around it in the consuming software experiencing the bug so that your deployed software can work immediately even on older versions of the OS that have not been updated yet and may not be for some time.