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.


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


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/

Save It For Your Bartender

Some wise words from Rich Hickey, the creator of the programming language Clojure. The context around this was people complaining that Clojure requires patches to be created, rather than allowing GitHub pull requests.

I’m responding to Jay here (because we’re friends and I know he can take it:), but this is for everyone who feels similarly:

I prefer patches. I understand some people don’t. Can’t we just agree to disagree? Why must this be repeatedly gone over?

I’m not sure what value you think a message like this is going to provide to the thousands of participants in this list. Does it make you feel better? It will not convince me otherwise.

Here’s how I see it. I’ve spent at least 100,000x as much time on Clojure as you will in the difference between producing a patch vs a pull request. The command is:

 git format-patch master --stdout > your-patch-file.diff 

There are two sides to change management - production/submission, and management/assessment/application/other-stewardship. People who argue that the process should be optimized for ease of submission are simply wrong. What if I said patches were twice as efficient for me to assess and manage as pull requests? (it’s more than that) Do the math and figure out how the effort should best be distributed.

I don’t think asking for patches is asking too much, and I truly appreciate the people who are going to the extra effort. And, I respect the fact that people disagree, and they might decide not to participate as a result. However, I don’t need to justify my decision over and over. How about a little consideration for me, and the other list participants? There is a real diluting effect of get-it-off-my-chest messages such as these on the value of the list and the utility of reading it for myself and others.

Sometimes it’s better to save it for your bartender :)