The Social Coding Contract
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 of our 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 swear I can feel a teetering sensation from how precariously our applications are perched on top of an ever-growing web of open-source dependencies. Fears that our tech stack is about to topple over have been fomenting in recent years—but are those fears founded?
This year, those worries came into focus when I was asked to adopt one of my favorite of Jim Weirich's gems, rspec-given. Sadly, every step of the process has been more complex than it could have been, and 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 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 our software upon sturdy ground.