Group Therapy for Open Source Project Maintainers – InApps 2022

What if your open source project succeeds beyond your wildest dreams — Woo-hoo! — and is adopted by hundreds of users who depend on your software for their own professional work? But your daytime employer doesn’t allow you any time for open source contributing on the job.

“This not only means that your nights and weekends are consumed, but also that if there’s some kind of serious issue, you might not be able to address it right away,” warned Jory Burson, chief operating officer of web platform consulting company Bocoup, during one session at the Node.js Interactive conference, held last week in Vancouver.

The session, called “Maintainer Burden Group Therapy” was billed as a “small group discussion for tips on reducing maintainer burden,” was surprisingly well attended, indicating that the topic had struck a chord with attendees.

Burson and the other moderators — IBM Developer Advocate Erin McKean, and conference organizer/Node.js Foundation community education manager Tracy Hinds — stressed the serious need to address the burdens that fall upon open source project maintainers.

The room was quickly divided into groups of five to six attendees, with instructions to brainstorm about the biggest issues facing maintainers and ideas for addressing them. About twenty minutes of the 30-minute session were spent in these breakout groups. This reporter, merely by dint of random seat selection, ended up in something of a superstar group:

• Tech consultant Darcy Clarke, Toronto NodeSchool co-founder and author/maintainer of multiple modules in the npm registry.
• Dan Shaw, one of the founders of the Node.js Foundation as well as current director/secretary of the foundation’s board of directors, and also former president/CTO/founder of NodeSource. He called himself “the neglectful father of modules I created years ago.”
• Rich Trott, director of the Center for Knowledge Management at UC San Francisco, and also a member of the Node.js Core Technical Steering Committee. Self-described “hardest working meat-bag in Node.js,” Trott modestly characterized his open source maintainer background as “I land a lot of code in Node itself.”
• Tracy Hinds, the conference organizer, described her current maintainer work as “maintaining, supporting and expanding the Node.js community itself.”

The conversation began with everyone throwing out “pain points” from personal experiences in the open source universe.

Life Happens

“As a module author who has had a major career shift where my day to day does not enable actively supporting and extending them, I have a lot of lingering guilt,” said Shaw. “In part, from not being explicit to anyone discovering the modules that the author is not necessarily here for you in the same way an active author would be — or how I was when I first created them.”

Shaw added that he still wants to support those modules while giving discretion to other individuals to take the lead: “Unless I can find time, PRs might stay open a long time, and then relevancy dies. I feel like I ought to post ‘Fork me and have fun!’ at the top of these repos.”

Clarke jumped in to second that emotion. “I feel the same pain. There are things I would love to hand off, but finding the right person who is really going to both fit and commit takes a lot of time I also don’t have. GitHub ought to create a ‘Looking for Maintainers’ badge to help projects attract and identify new potential maintainers.”

Brainstormed solution(s): It’s on you, GitHub. Make that badge. Maybe start an official list of projects that are actively in search of maintainers. (It turns out there is already a page like that, created by Jeff Pickhardt, but it’s not exactly drowning in stars). This sounds like a good low-cost project for GitHub to maybe throw a little long-term maintenance muscle behind.

Not My Day Job

Clarke said, “I have a feeling of conflict working on OS projects where some of the people I work with are getting paid for their contrib time, and I am not. So needing people to understand that I can’t always be as responsive as they can, can’t always work on an issue the moment it pops up. Or even the same day.”

“I definitely feel privileged myself to participate, to have conversations about the future of these libraries, but I work in Canada where it’s a tough sell to get companies to understand the value of supporting the OS that they use all the time.”

Hinds agreed, chiming in, “Node contributors can come from any part of a wide range — someone who works on it full time, someone part time getting paid because their employer either supports it or looks the other way, versus someone who gives their personal time and evenings and weekends.”

“Privilege is the right word,” said Trott. “My employer understands the value of me working on Node. So I’m not getting paid to work on Node, but I work on Node while I’m getting paid. I have that privilege, and so many people do not.”

Besides being a personal burden for individual maintainers volunteering one hundred percent of their time, Hinds said,  this also creates issues for the community at large — and even for widely supported projects like Node.js itself. “This limits diversity among contributors, because even globally the pool of contributors still tends to draw mainly from people who have luxury of working on Node while getting paid,” she said.

Brainstormed solution(s): Step up education for employers to support efforts like Open Source Fridays. Expand foundation umbrellas to help monetize support for key projects. Take succession planning seriously as a community-wide open source issue, and start the conversation now.

Big Projects Run on Small People, Too

Maintainer burden is not only for sole proprietors on small projects, said Trott. Larger projects have the same issue in a different way: crucial, but perhaps not widely visible, aspects of large projects like Node.js frequently rest upon single individuals. “When you get someone not active in the project overall, but in charge of some important thing like cryptography — things that are not niche features at all — and then they’re not responsive when you really need them to be…”

Brainstormed solution(s): Working to create more “Maintainerati” events similar to those hosted by GH, including this one coming up as part of GitHub Universe. With specific attention paid to cross-pollinating contributors between “silos” within projects, so single crucial aspects don’t rest solely upon any one contributor.

Busy Hands

Twenty minutes went by in a flash. Each group appeared to be deeply engaged in serious, and sometimes impassioned, conversation. At the end, each sent up a representative to briefly describe the issues they’d identified. Reports were fairly consistent across all groups and ultimately coalesced into one theme: maintainer burden happens, and rapidly leads to burnout, mainly from lack of balance. And the things out of whack almost universally boil down to time vs. money. Veteran maintainers who get on-the-job support for their open source projects — or who, like Dan Shaw, go on to start companies to support their open source habits — are the ones most able to continue in the marathon.

So there you have it, open source aficionados. This amazing ecosystem of ours runs on the work of many, many busy hands, carrying the weight of our open source world. Sometimes those hands become tired or tied up in unrelated life events. It’s time for each of us to ask ourselves what we can do to better help with sharing the load.

Rich Trott suggests starting with node todo, a list of ways to get involved with contributing to Node.js as well as an easy get-started guide. But, really, it’s as easy as just picking your favorite open source project and asking what you can do to help carry a little bit of that burden.

The Linux Foundation, sponsor of The Node.Js Foundation and Node.js interactive is a sponsor of InApps.

Feature image courtesy Pixabay.