Zen and the Art of Open Source Maintenance

This blog post will not be as long as I wish it to be. I do not have the time nor the pa­tience at the mo­ment to dive as deep into this sub­ject as I feel the sub­ject it­self de­serves. It also will not be as short as I wish it to be. It takes time to de­ter­mine what is im­por­tant and what is not. My hope is that by de­clar­ing this es­say “incomplete”, you will grant me some grace and un­der­stand­ing.

While read­ing an old — un­pub­lished, for now — es­say of mine, I was re­minded of the won­der­ful book by Robert Persig ti­tled Zen and the Art of Motorcycle Maintenance. I read it in high-school, and it has served as the foun­da­tion of much of my world­view up to this point. The book serves to help any­one in any pro­fes­sion, but I think it speaks par­tic­u­larly well to the lives of open source main­tain­ers. Here, I hope to re­flect on its teach­ings and find ways to ap­ply them to the daily rou­tine of open source main­te­nance and de­vel­op­ment.

If you have not read the book yet, please do so now. I am not kid­ding. Stop read­ing this blog post, walk down to your lo­cal book­store and pur­chase a copy. Do not come back un­til you have read it.

For The Disobedient

Since I sus­pect many of my read­ers to be rebels, or oth­er­wise feel re­pelled by great lit­er­a­ture, I will pro­vide a brief overview of the book.

Zen and the Art of Motorcycle Maintenance is not, as you may have guessed, ac­tu­ally about mo­tor­cy­cle main­te­nance. Al­though it con­tains some valu­able tips for those will­ing to get a lit­tle greasy, the book is re­ally about how we per­ceive the world and how to nav­i­gate it with­out go­ing in­sane.

Structurally, it fol­lows Persig on his fic­tional mo­tor­cy­cle trip across the coun­try. Much of the book hap­pens in con­ver­sa­tion with him­self while he rides down var­i­ous roads and high­ways.

While I will save dis­cus­sion of the more im­por­tant mat­ters for a later day, there is one sec­tion that needs ex­pla­na­tion: Persig’s gump­tion traps.

What is a gump­tion trap? A gump­tion trap is some­thing that saps your mo­ti­va­tion for a pro­ject. In the book, Persig de­scribed them in the con­text of — you guessed it — mo­tor­cy­cle main­te­nance, but gump­tion traps lie every­where in day to day life, es­pe­cially for open source main­tain­ers. He de­scribes two types of gump­tion trap: set­backs and hang-ups.

A set­back is any gump­tion trap that is not, for lack of a bet­ter word, your fault. It’s when some­thing that ex­ists out­side of your con­trol im­pacts your abil­ity to get sh*t done. For an open source main­tainer, sup­ply chain at­tacks and — god for­bid — GitHub out­ages count as set­backs. They can of­ten feel out­side of your con­trol. That feel­ing is what drains your gump­tion.

The good news is re­al­ized that there are things you can do to pre­vent set­backs, like lock­ing your de­pen­den­cies and avoid­ing GitHub. Planning ahead, even if it’s hard, can pre­serve your gump­tion for the re­ally fun parts of open source main­te­nance.

A hang-up on the other hand, is a more com­pli­cated kind of gump­tion trap. Hang-ups hap­pen in­ter­nally, and are coun­ter­in­tu­itively more dif­fi­cult to move past. They sap your de­sire to con­tinue work on your pro­ject not be­cause some­thing ter­ri­ble hap­pened, but be­cause there’s some­thing wrong with the way you view the world. Per­sig says there are three im­por­tant kinds of hang-up: value traps, truth traps, and mus­cle traps. I do not think truth traps or mus­cle traps are par­tic­u­larly rel­e­vant to my work as an open source main­tainer, so I will be as­sign­ing in­ter­pre­ta­tion of those as home­work for my read­ers. Value traps, how­ever, are quite rel­e­vant, so I want to go into those in de­tail.

Value Traps

A value trap comes up when some as­pect of your value sys­tem comes into con­flict with the pro­ject it­self.

Stubbornness can stop you from see­ing a good so­lu­tion to a prob­lem be­cause you are too fo­cused on a bad so­lu­tion. Spend­ing a lot of time work­ing on a bad so­lu­tion only see it as it is retroac­tively is a recipe for frus­tra­tion and, of course, lost gump­tion. The so­lu­tion here is to slow down. Spend time look­ing around the pro­ject and make sure all of your as­sump­tions are cor­rect. For open source main­tain­ers, this sec­ond look does not nec­es­sar­ily have to be at the code. It can also be a look at the peo­ple around the code. It’s tempt­ing to be­lieve that you are the only one who can solve each prob­lem. In re­al­ity, there’s likely a com­mu­nity of peo­ple work­ing with you. Maybe a mem­ber of that com­mu­nity has in­sight you do not have. Talk to them.

Boredom can make you sloppy, and sloppy work is bad work, and bad work steeps the gump­tion right out of you. What’s worse is that bore­dom of­ten comes af­ter you have al­ready lost much of your gump­tion. This vari­ant of value trap is ab­solutely not spe­cific in any way to open source, so I will not pre­tend to con­nect the two. Per­sig rec­om­mends tak­ing a rest and get­ting plenty of sleep. What­ever you do, he says, do not keep work­ing. Per­son­ally, when I en­counter this gump­tion trap, I try to work on an­other “project” within my open source pro­ject. Maybe I am not in­ter­ested in de­bug­ging at the mo­ment, so I swap over to writ­ing a new mod­ule in­stead. I can come back to my de­bug­ging task later with a fresh per­spec­tive and a full tank of gump­tion.

Anxiety, per­haps bet­ter char­ac­ter­ized as fear, can stop you from do­ing any­thing at all. I of­ten get anx­i­ety merg­ing PRs, even af­ter I have done all of my due dili­gence and truly be­lieve them to be ready. There is some­thing about hit­ting “merge” that spikes my adren­a­line. But, code ages like milk, so I must merge it any­way. Per­sig sug­gests you do ex­tra due dili­gence if it makes you feel bet­ter. If that does not help, just man up and do it.

Conclusion

The won­der­ful thing about all the gump­tion traps that Persig high­lights is that they are fun­da­men­tally in your con­trol. Some can only be pre­vented, and oth­ers re­quire some level of in­tro­spec­tion, but they all can be man­aged. Now se­ri­ously, if you did not lis­ten the first time: go read the f**king book. Do it.