Daniel Compton

The personal blog of Daniel Compton - Projects

While open source is free as in beer, it’s also free as in baby

The hardware store

Recently Zach Tellman and Factual open sourced several libraries that they wrote to handle specific needs where nothing else existed. In the comments on Reddit some people were griping about the possiblity that this software might be abandoned in a year or two, and if they depended on it then they would be stuck. I think this mindset comes from a misguided and selfish perception of open source.

As a new software engineer, it can be attractive to treat open source libraries, applications, and frameworks like a hardware store. If you have a problem and the standard library doesn’t address it, then pull in a dependency. Need a util function? Do a search on GitHub, and add in a dependency. Want to take advantage of this new fangled single page app craze? Pull in another one. Need to process XML with Ruby? Just install Nokogiri in a minute and you’re away laughing.

This may work for a while, but it misses something vital about software engineering: software decays over time, a.k.a. entropy. Software doesn’t exist in an isolated system, it interacts with other systems that change over time. These are things like your operating system, memory, other external services, databases, CPU’s, network, I/O devices (printers, displays), and most importantly users. These systems are replaced or updated with newer systems. Sometimes the changes are backwards compatible, sometimes they aren’t. As a consequence code is written once but maintained forever. Using someone else’s open source code can be a great help for you, because you don’t have to write it. However as things change over time, entropy will kick in and the code will need to be maintained and updated.

It takes a village to raise a library

Instead of treating open source software as a hardware store, I think a better metaphor is that of joining a village raising a child. Every dependency that you pull in needs to be maintained over time, along with it’s dependencies too, all the way down. The question isn’t about whether the maintenance will need to be done, it’s who is going to do it? Larger communities have more resources and time to do this. Older projects have been refined and battle tested and have more stable API’s. If you’re working in a young, obscure, or fast moving language then more of the maintenance may fall on you.

I think of someone releasing open source software as a gift to the world, not as claiming a responsibility to maintain it for you. Some projects do claim that responsibility, but it’s not automatically conferred just because someone released a project on GitHub. I think much more of the responsibility falls on the person using it. It’s your code that will be using it, your code that will need to be upgraded, and your code that will break. These are a few things that you should ask before you start using a library or framework.

Once you’ve answered these questions, you’ll have a much better understanding of the risks you inherit from using the library and the likely future direction of the project. If you do decide to adopt it then I recommend joining the mailing list, watching it on GitHub, or otherwise staying up to date with changes.

alt.deps.options

Pulling in a dependency should be a considered approach, and there are several other options to look at first:

fin.

Open source software is a massive boon to programmer productivity, saving man centuries of effort. But remember, just as you own your availability, you also own your software and everything that goes into it.


I didn’t get to this point on my own, I owe a big thanks to Colin Taylor, Derek Troy-West, and Mark Derricutt for their advice on this, and rejecting my code reviews when I pulled in unnecessary dependencies!

Update: This has been translated into Chinese at www.labazhou.net/2014/11/while-open-source-is-free-as-in-beer-it-is-also-free-as-in-baby/