I recently ran into a rather annoying (confirmed) bug in an open source software package that I have integrated into my application.  According to the public issue tracker this bug has been resolved in the latest release of the software.Occasionally you NEED that bug fix to avoid an expensive refactor of a particular module, however for technical and/or political reasons, you will not be able to upgrade to the latest release.On inspecting the code changes made, the fix seems simple enough that I feel a viable option would be to patch the code myself and recompile my current approved version of the software, however detractors want to argue the case that this is nearly always a bad idea in that it is risky and introducing a troublesome complexity.In their eyes because this code change was done by us solely for our use, it must be part of our code base, meaning that rather than introducing the open source software as a third party dependency, we must introduce it as a new project and incorporate its automated build into our build process.To me I think this is wrong headed, as we would be pulling their code from their source control repository into ours, and we lose the history behind any code changes that came before that.  Also it just seems like something that is far too complicated for such a small code change that needs to be made.Would it be a bad idea to do the above in this case?  If so, then what is the ideal situation when open source needs to change, but only for your sole benefit in house?
Patching open source software when upgrading is not an option?
open source;builds;software patches
If you can't use a later version that doesn't have the problem you're encountering, the only options you have are to eitherlive with the problem and find a workaroundfork the library and fix it in your private version (which is what you'd effectively be doing)throw in the towel and tell your managers that the problem is insurmountable (which would be a lie, as you have two other options open to you).I've been in your position, option 2 (make a custom fork) is often the most palatable solution available. That's life when dealing with open source libraries, especially ones that evolve quickly and have a bad habit to break backwards compatibility between releases (which in my experience is the most common reason to have to do things like this).For more than a few OSS libraries it's led me and teams I've been a part of to mandate wrappers around any and all of them and accessing the functionality of 3rd party libraries exclusively through those wrappers. That way, if we need to replace a 3rd party library with a version that's so different it'd break our code, the changes are at least largely confined to that wrapper. It's not the nicest (adds code, can add complexity and cost performance) but sometimes it's the only way to retain your sanity.