The Side Project Trap
When the thing you built for joy becomes the thing you dread opening.

There’s a moment in every passion project where the thing you built for joy becomes the thing you dread opening. The game system you designed because you loved the craft now has a Discord full of people waiting for the next update. The open source library you released because it solved your problem now has GitHub issues from strangers with edge cases you never anticipated.
I’ve been here multiple times and I’m still figuring out how to navigate it.
How We Get Here
You build something because you’re genuinely excited about it. You share it because others might find it useful and, when they do, that feels incredible. So you keep building and responding, showing up because the feedback loop feels rewarding.
Somewhere along the way, the intrinsic motivation that started the project gets replaced by obligation. The Discord notifications that once felt like validation start feeling like demands. The GitHub issues that once represented people caring about your work start representing an endless queue of unpaid labor.
The Tidelift 2024 survey found that 60% of open source maintainers have quit or considered quitting. The top reason? Burnout. Nearly half cited it specifically. And 61% of unpaid maintainers work completely alone, which means there’s no one to share the load when enthusiasm fades.
From 2017 to late-2023, I maintained a fork of a game engine that I absolutely loved, but as the solo developer, it was competing with my day job and family with thousands of daily users, an engaged community, and a growing list of “feature requests”. As my obligations have lessened lately, I may pick it up again as it was a near and dear passion of mine, but I’m still learning how to navigate the “open source/life balance.”
The Guilt Problem
What makes this particularly difficult is the guilt. You built something people depend on and walking away feels like abandoning them while scaling back feels like letting them down.
The XZ Utils backdoor in 2024 happened partly because a solo maintainer, burned out and isolated, became vulnerable to a malicious actor who offered to “help.” The maintainer had confessed years earlier that their mental health was suffering and their “ability to care has been fairly limited.” Nobody was there to share the burden, and eventually someone with bad intentions filled that vacuum.
That’s an extreme case, but the underlying dynamic is common. Maintainers feel trapped between their own wellbeing and the communities that depend on them. The Kubernetes project announced the retirement of Ingress NGINX in November 2025 not because the technology was obsolete, but because “the project has had only one or two people doing development work, on their own time, after work hours and on weekends.” They simply couldn’t sustain the effort anymore.
The phrase I keep coming back to is “free as in puppy.” Someone gives you a puppy for free, but now you’re responsible for feeding it, walking it, and cleaning up after it for the next fifteen years. Passion projects work the same way. The initial creation is the easy part. The maintenance is where the real cost lives.
What I’m Still Learning
I’ve started projects with clear boundaries that eroded over time, said yes to “just one more thing” until the pile became overwhelming. The guilt of stepping back from communities I helped build still catches me off guard.
Over the last few years, especially with COVID (and getting older), I’ve found a few guardrails that help me.
First, naming the transition matters. There’s a difference between “I’m building this for fun” and “I’m maintaining this for others.” Acknowledging when a project has shifted from the first mode to the second helps me make more conscious decisions about where my time goes.
Second, building in exits early helps too. Before a project gains traction, I try to think about what sustainable maintenance looks like. Can I document it well enough that others could take over? Can I set expectations early about response times and scope? The time to establish boundaries is before the community forms, not after.
Finally, separating creation from maintenance in my head helps too. The energy I get from building something new is different from the energy required to maintain something existing. Recognizing that these are different activities with different motivations helps me understand why I might love starting projects but dread the ongoing work (I own so many domains for random open source ideas 🙃).
The Uncomfortable Truth
Passion is fuel, but it’s not infinite. The things we build because we love them can become the things that drain us if we’re not careful about boundaries.
There are repositories with issues I’ve been meaning to address for longer than I’d like to admit. The guilt sits there, but so does the recognition that running myself into the ground wouldn’t actually serve anyone.
If you’re feeling the weight of something you built for joy, you’re not alone.
The unchecked use of “yes” is how most of us get here. The path back involves learning to say “not right now” or “not anymore” without treating it as failure.








