Zen and the Art of Open Source Maintenance<br>Elijah Potter

Sign In

Zen and the Art of Open Source Maintenance

This blog post will not be as long as I wish it to be.<br>I do not have the time nor the patience at the moment to dive as deep into this subject as I feel the subject itself deserves.<br>It also will not be as short as I wish it to be.<br>It takes time to determine what is important and what is not.<br>My hope is that by declaring this essay "incomplete", you will grant me some grace and understanding.

While reading an old — unpublished, for now — essay of mine, I was reminded of the wonderful book by Robert Persig titled Zen and the Art of Motorcycle Maintenance.<br>I read it in high-school, and it has served as the foundation of much of worldview up to this point.<br>The book serves to help anyone in any profession, but I think it speaks particularly well to the lives of open source maintainers.<br>Here, I hope to reflect on its teachings and find ways to apply them to the daily routine of open source maintenance and development.

If you have not read the book yet, please do so now.<br>I am not kidding.<br>Stop reading this blog post, walk down to your local bookstore and purchase a copy.<br>Do not come back until you have read it.

For The Disobedient

Since I suspect many of my readers to be rebels, or otherwise feel repelled by great literature, I will provide a brief overview of the book.

Zen and the Art of Motorcycle Maintenance is not, as you may have guessed, actually about motorcycle maintenance.<br>Although it contains some valuable tips for those willing to get a little greasy, the book is really about how we perceive the world and how to navigate it without going insane.

Structurally, it follows Persig on his fictional motorcycle trip across the country.<br>Much of the book happens in conversation with himself while he rides down various roads and highways.

While I will save discussion of the more important matters for a later day, there is one section that needs explanation: Persig's gumption traps .

What is a gumption trap?<br>A gumption trap is something that saps your motivation for a project.<br>In the book, Persig described them in the context of — you guessed it — motorcycle maintenance, but gumption traps lie everywhere in day to day life, especially for open source maintainers.<br>He describes two types of gumption trap: setbacks and hang-ups.

A setback is any gumption trap that is not, for lack of a better word, your fault.<br>It's when something that exists outside of your control impacts your ability to get sh*t done.<br>For an open source maintainer, supply chain attacks and — god forbid — GitHub outages count as setbacks.<br>They can often feel outside of your control.<br>That feeling is what drains your gumption.

The good news is realized that there are things you can do to prevent setbacks, like locking your dependencies and avoiding GitHub.<br>Planning ahead, even if it's hard, can preserve your gumption for the really fun parts of open source maintenance.

A hang-up on the other hand, is a more complicated kind of gumption trap.<br>Hang-ups happen internally, and are counterintuitively more difficult to move past.<br>They sap your desire to continue work on your project not because something terrible happened, but because there's something wrong with the way you view the world.<br>Persig says there are three important kinds of hang-up: value traps, truth traps, and muscle traps.<br>I do not think truth traps or muscle traps are particularly relevant to my work as an open source maintainer, so I will be assigning interpretation of those as homework for my readers.<br>Value traps, however, are quite relevant, so I want to go into those in detail.

Value Traps

A value trap comes up when some aspect of your value system comes into conflict with the project itself.

Stubbornness can stop you from seeing a good solution to a problem because you are too focused on a bad solution.<br>Spending a lot of time working on a bad solution only see it as it is retroactively is a recipe for frustration and, of course, lost gumption.<br>The solution here is to slow down.<br>Spend time looking around the project and make sure all of your assumptions are correct.<br>For open source maintainers, this second look does not necessarily have to be at the code.<br>It can also be a look at the people around the code.<br>It's tempting to believe that you are the only one who can solve each problem.<br>In reality, there's likely a community of people working with you.<br>Maybe a member of that community has insight you do not have.<br>Talk to them.

Boredom can make you sloppy, and sloppy work is bad work, and bad work steeps the gumption right out of you.<br>What's worse is that boredom often comes after you have already lost much of your gumption.<br>This variant of value trap is absolutely not specific in any way to open source, so I will not pretend to connect the two.<br>Persig recommends taking a rest and getting plenty of sleep.<br>Whatever you do, he says, do not keep working.<br>Personally,...