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.
  • Quick setup/install: The demo gods are powerful. Providing a way to get started faster, even in browser, goes a long way for exciting consumers of your open source project.
  • Transparency and empowering contributors: If you’re getting something from a project, you hopefully want to give back in some way. Give your contributors a way to do this and display the path to contribution publicly and clearly.


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.
  • Embroiling contributors in politics: Communication between humans is not easy, especially online. Well-meant sarcasm can be lost easily. The small idiosyncrasies of a conversation are missing entirely. I’ve sent my fair share of trolling IRC messages and angry emails, and they have gained me nothing. It’s a shame that many maintainers choose to break down the excitement of open source with bullshit and bureaucracy.
  • Difficult setup, lack of documentation: The flip side of quick setup is one that is painstakingly long and obnoxious. Another common open source complaint is a project that has “no documentation”. The whining can be silenced with screencasts, tutorials, and even blog posts.


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.
  • The “Issues Count” Problem: This number sits on top of your project at GitHub. It frames each link to your code or wiki. Why is it so high? Is this project planning a new release? Has the maintainer abandoned it? Even if the project is stable, this number has a negative connotation and changes how I feel about using and contributing to it.
  • Your name: Every commit has a name attached to it. Entire git commands are dedicated to finding out who’s responsible for each line of code. Your name might appear on a LICENSE file, CONTIBUTORS list, or maybe just under THANKS. Sadly, avoiding using your real name seems to be impossible. Putting your name on something means you should be proud of your work. Despite this, it assigns me guilt: it’s my work, and my problem to help fix first.


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”.
  • The license: The beautiful part of the MIT License (and many others) is the part that frankly describes the product you are receiving “AS-IS”. There’s no strings attached to using the code or putting it out there for others to use. By its nature this frees up guilt, since your liability is not at stake. If someone wants their patch accepted or issue fixed so bad, they can fork it AS-IS and fix it themselves.
  • Being extremely open: This guilt erasure method is one I’ve been trying with OpenHack. The process for starting an OpenHack meetup is well-documented, and results in trusting an organizer with access to the main site that now over 30 cities share use of. Gittip is another example of trying to run an entire business in this manner, down to considering a name change for the company in a GitHub issue. Being open and honest is a simple way to remove guilt.

“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.