We’re stuck in a codependent relationship with open source. Our community’s investment in rubygems’ infrastructure is not commensurate with our dependence on it. Many of our favorite tools break whenever github.com goes down. Most projects depend on already-unmaintained gems which will eventually need to be adopted or replaced—especially given the increased pace of Ruby’s own release schedule.
Sometimes I feel a teetering sensation from the ever-growing web of open-source dependencies upon which our applications are precariously perched. In recent years, fears have been fomenting that our tech stack is about to topple over. But are those fears founded?
This year, those worries came into focus when I was asked to adopt one of my favorite gems (of Jim Weirich): rspec-given. Sadly, every step of the process was more complex than it could have been. The experience has prompted me to reflect on how I use and create open source software.
Everyone agrees creators and users of open source share the responsibility to safeguard the future health of the projects we and our businesses have come to rely on. But time and again, we fail. Maintainers often fail to welcome other contributors, or to cede any control. Likewise, users rarely invest the time and money needed to keep their favorite projects healthy.
Technically and socially, our tools and projects are riddled with single points of failure. Our dependency and version control services are monolithic monopolies. For every prolific open source superhero, there are a thousand disengaged application teams. Concerns of convenience continually trump any semblance of contingency planning.
Let’s talk about how maintainers can ensure their tools will survive the end of their own involvement. Let’s discuss how to convince our businesses to avert real risks by making modest investments in the open source they use. Together, let’s solve these problems and regain confidence that we’re building software upon sturdy ground.