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...
What to do when critical functionality of a dependency is broken and impedes development?
project management;dependencies;time management
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:Become familiar with the code base, perhaps even making contributions yourself.  This is another reason why you chose open-source, right?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?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?