Locally patching & maintaining third-party library code

Answer 1

What you've described sounds pretty optimal; use source control to track what you're changing. Although you're forking the code, you should be able to re-merge it back together when you get the next release from the vendor. Ideally the next release will contain the fix(es) you require. And by using source control it makes it easy to report to the vendor a diff of what you think is a workable fix.

As to your apprehension when modifying the code, you should of course try to keep your diffs as minimal as possible, to make it easier to merge back together with the vendor's changes (I'm sure you're already doing these):

• Don't change whitespace.
• Don't try to refactor the code.
• Keep your changes as close to the original style as possible.
• If you get a new version that has drastically changed internally, but fixes your bug, drop your changes.

As to your concern about coding to the API, perhaps you can acquire some unit tests for the library? If not, you likely have your own unit tests for your code that uses the library. Either one of those is your best bet for detecting if your changes have modified the semantics of the API, or have any other bad side effects.

Answer 2

I think you're right in the weaknesses you have identified. Robert Glass in Facts and Fallacies of Software Engineering says (fact #19) "It is almost always a mistake to modify packaged, vendor produced software packages", exactly because the work of merging your modifications into new releases will be difficult, tedious, and likely to cause bugs.