The unglamorous side of open source
Nobody writes blog posts about responding to the 50th "this doesn't work" issue that's actually a misconfiguration.
I maintain three npm packages. Here’s what that actually means on a random Tuesday.
The issue queue
Most issues fall into three categories:
Genuine bugs. Maybe 20%. These are great. Clear reproduction, something’s actually broken, I fix it, everyone’s happy.
Misconfigurations. Maybe 50%. “Your library doesn’t work.” Turns out they didn’t read the setup guide. Or they’re using an incompatible version of Svelte. Or their bundler is stripping the CSS.
Feature requests disguised as bugs. The rest. “It should also do X.” No it shouldn’t. X is out of scope. But you can’t just say “no” without explaining why, so you spend 15 minutes writing a polite response.
What I learned about scope
Early on, I said yes to too many feature requests. The datagrid grew features I didn’t need, that 90% of users didn’t need, that complicated the API for everyone.
Now my answer to most requests is: “That’s a great idea for a plugin/extension. Here’s how you could build it on top of the existing API.”
Not everything needs to be in core.
Documentation is the real product
A library without docs is a library with 10x more support issues. Every hour I spend writing docs saves me 5 hours of answering the same question in issues.
I still don’t write enough docs. Nobody does.
When to stop
I put the datagrid in maintenance mode. Not because it’s abandoned, but because it’s done. It does what it needs to do. Bugs get fixed. But I’m not adding features anymore.
This felt weird at first. Like admitting defeat. But it’s actually the responsible thing. Users get stability. I get my time back.
Would I do it again?
Yeah. Building something that other people use and find useful is genuinely satisfying. The GitHub notification anxiety is less satisfying. But on balance, it’s worth it.
Just don’t expect glamour. It’s mostly reading other people’s error logs.