Skip to content

Instantly share code, notes, and snippets.

@searls
Created June 17, 2014 18:00
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save searls/eaf8dcdd4b3a10a97694 to your computer and use it in GitHub Desktop.
Save searls/eaf8dcdd4b3a10a97694 to your computer and use it in GitHub Desktop.

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.

@Zearin
Copy link

Zearin commented Aug 11, 2014

@searls: I the sentiments of this article.

Since gists offer Forks but not Pull Requests, I wanted to offer a “pull request” for this gist. I forked it and made a few minor edits, which I hope are to your liking.

Please keep up efforts like this! I’ve felt similarly for a long time, but have fallen short of starting conversations on such topics. Articles like this make it easier for me to share these sentiments with others. Perhaps, when there are enough articles like this, and enough people reading them and sharing them with others, things might change (even if just a little bit) for the better.

@testobsessed
Copy link

Howdy! I'd do a pull request if I could. Here are my edits. Note that I didn't end up adding or changing words. I love your use of language. So I just trimmed and rearranged. Hope this is helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment