Open Source Guilt & Passion

I was on In Beta a while ago, and we talked about the “guilt” that comes with maintaining open source projects. I feel both intensely passionate and exceptionally guilty with how I contribute to open source. I love getting patches into new projects, and the needs of existing projects are demanding.

An open source contributor doesn’t feel guilt as in a crime, but guilt as in time: What is best to spend your yours on? Steve Klabnik has a strategy for dealing with a limited amount of time:

The basic idea is this: you try to minimize the things that are bad, and maximize those that are good.

My strategy has built on Steve’s: minimize the guilt of open source, maximize the passion from open source. I’ve been thinking a lot about what creates passion, and what builds up guilt. It’s also worth considering what destroys passion, and what can tear down guilt.

If you’re new to contributing, you’ve probably only experienced the passion side of open source: the rush of starting something new or getting that pull request accepted. This is tied closely to what makes an open source project pleasurable to work on and worthwhile for others to use. Generating passion for your open source project can be done in many ways:

  • Solving real problems: This by far the biggest generator of my excitement for open source. Serve Rack apps with just a symlink. Install anything on OSX without a hassle. Make stats easy to collect. The list goes on and on: Solve my problem, earn my passion.

The erosion of open source passion is a sad one. Conflict is a common cause, but there are others as well:

  • Opaque process to accept patches: GitHub has made some serious progress with this, but I think the barrier to entry is still too high. Saying “Just send a pull request” is not enough. There’s more work than that for both the maintainer and the contributor, and building a wall between the two does nothing but hurt your project.

There’s a flip side to passion: the guilt. The guilt of not responding to someone who needs help with your code. The guilt of issues/pull requests piling up, and newcomers unsure of who to blame. The guilt of not having documentation when you may have figured it out yourself without any. These have affected me the most:

  • Responsibility and its consequences: The most weight behind my open source guilt lies here. If you’re the maintainer, the blame is yours. An unbounded set of items exist that multiply guilt: Security holes, availability/uptime, prompt response time for issues. These are natural byproducts of having a project that others are interested in, and the fun part is that ignoring any of them only increases the guilt factor.

My job as an open source maintainer is to break down the worry suffocating my email inbox, issues dashboard, and support queues. It’s easy to drop in and fix something, then disappear. It’s much harder to stick in the game for months or years and make a serious dent on a project. Here’s what I have been trying lately to destroy my open source guilt:

  • Giving up control: Letting someone else take the reins is one of the hardest things to do with an open source project. Relinquishing power over a project can come in many forms: giving someone else commit access, allowing them to deploy/release a new version, or wholesale transfer of project direction and control. The price paid is “[trading] away shares of the total reputation return in exchange for others’ work”.

“What project should I work on?” is not always a question of which demands priority, but which I can make most effective use of my time on to minimize the guilt and maximize my passion.

Perhaps emptying out the issues queue will decrease the worry. Implementing that new feature I had in mind might keep the fire burning.

I invite you to evaluate your own projects in a similar manner: Maybe we’ll all feel a little less guilty and a little more excited to be contributing to open source.

Thanks to Jeremy for feedback and Jamie for doodles.

Originally published at

@qrush is a short, sturdy creature fond of drink and industry. Working on @Agrilyst, @CoworkBuffalo, @MxDesk.

@qrush is a short, sturdy creature fond of drink and industry. Working on @Agrilyst, @CoworkBuffalo, @MxDesk.