In the last couple days, there has been a bit of discussion in the Perl community about the popular Moo library and how some of its recent changes have put applications at risk for sudden failure. No matter what side of the debate you’re on, this is the bottom line:
Open source authors (myself included) can break your code.
If you count all the lines of code that must be deployed to run your application, most of it probably isn’t yours. It’s a fair bet that more than half of your stack is open source libraries. And that’s great! That represents a huge amount of time and money that you didn’t have to spend, not to mention many open source libraries are simply better than what you might have built on your own.
But all that open source code also represents a risk. If an upstream author introduces a bug or changes an interface, then you may find your application is suddenly broken when you upgrade to a new release. Of course, we don’t deliberately try to break your application. On the contrary, most of us work extremely hard to produce high-quality code and maintain compatibility. But breakage can and does happen. At any given moment somebody, somewhere, has a broken application because some library on CPAN/RubyGems/PyPi has changed. Are you going to be next?
Some development teams have been burned by these changes so many times they avoid upgrading libraries like the plague, or just prohibit using them altogether. But we all know that’s not the right answer either. Postponing upgrades just compounds the risk, and reinventing wheels (badly) is an expensive disservice to your customers. Open source dependencies are a necessity for today’s aggressive project schedules and rapidly shifting requirements. But like all things in the software industry, they are constantly changing.
So that’s why dependency management is so important. As our applications become more and more reliant upon open source code, we need to have solid control over changes in that code. We need to be able to clearly identify & replicate our dependencies, and to incrementally upgrade them in a safe manner. Fortunately, tools like Pinto (Perl) and Bundler (Ruby) can really help us here. We also have services like Stratopan and GemFury. These tools and services aren’t the only way to manage dependencies, but they are built upon familiar toolchains which makes them easy for developers to learn. Yet, they aren’t nearly as widespread as they should be.
It takes a bit of time to learn these tools and integrate them into your development process, but they pay huge dividends in the long run. If you’re not firmly in control of your open source libraries, then you owe it to yourself (and your users) to find a solution that works for you. Please, don’t let me break your code.