What to do when critical functionality of a dependency is broken and impedes development?

Question

Yesterday I was working on a Rails 5 API project which is using the acts-as-taggable-on library to allow things to have tags (like questions on SE). Rails 5 is in alpha support right now. There is currently a PR to fix a bug waiting to be merged into master; the bug caused my feature branch to come to a halt halfway through completion - I couldn't implement any of the functionality of the library because loading was broken.

As a quick fix, I simply cloned the repo, fixed the issue with the same code that the PR had, and pointed my Gemfile (dependency version control file) to my own Github fork, until the bugfix is finally merged back into master.

I got lucky that the fix was simple (and that someone had already done it), so I was able to get around the issue. But what if this library was critical to the development of my application? What if the bugfix that was stopping my development wasn't a wide-spread issue for other people, so the fix didn't come around quickly like it did this time?

Imagine that this feature needed to be completed before development on other dependent features - what do you do in that situation? What if, for me, tagging was absolutely critical to the next phrase of development, where everything else relied on it - but the tagging dependency is bugged for my configuration? What does one do when critical functionality of a dependency impedes development of (a) feature(s)?

And, surely, swordfights on office chairs for hours or days is not an option...

Answer 1

This is one of the reasons you're using open-source software, right?

You could make the very same argument for "what happens if my very expensive, proprietary, closed-source library suddenly falls over? Will there be someone available at [large, monolithic software company] to fix it for me?" With open-source software, at least you have the chance to fix that bug yourself.

If your software takes a critical dependency to an open source library, there are three things you can do to mitigate the risk:

1. Become familiar with the code base, perhaps even making contributions yourself. This is another reason why you chose open-source, right?

2. Have a fall-back library if the first library falls down. This is why you program to interfaces; so that you can change out the implementation if you have to, right?

3. Balance your desire for bleeding-edge against your need for stability (i.e. don't use alpha software). You knew what you were getting into, right?

Answer 2

The solution to developing applications where bugs or lack of features have a high risk of causing your work to stop is to not use high risk libraries. Boring and lame, I know..

You said this is an alpha release. Don't use alpha releases for critical projects. It's not even a beta release, let alone 1.0 so this sort of thing is to be expected. The entire point of this stage in a project is to find problems and harden the project.

If you find yourself in this situation you basically have to do what you did (we've done exactly the same thing). Fix it and PR the project.

But the solution is using more stable libraries with understood functionality and APIs or at least maintaining backwards compatibility to a stable version. You should be wary depending 100% on something you have no control over and require to succeed.

Answer 3

It is usually recommended to hide third-party libraries behind adapters or wrappers that you write yourself. This has twofold advantages:

• You can swap out the third-party library with another one without changing any of your code
• You can program the rest of your code against your own adapter interface. In case of a temporary problem with the library, just plug in your own stub/fake or simplified version of the library functionality. In that way development and testing of your downstream features are not blocked (even though the deployment of the full program still is).