Maintaining Open Source Libraries Nobody Uses

I maintain a handful of open source Python libraries.

A couple of them do well. pygeohash is in the top 1% most downloaded Python packages, with over a hundred million installs.

But I also maintain elote, keeks, and git-pandas. These are small libraries with tiny small audiences, and maintaining them is a fundamentally different experience than maintaining something people actually depend on.

And that’s the vast majority of open source.

Nobody writes about maintaining a library with 200 GitHub stars. All the open source discourse is about burnout from massive projects, corporate free-loading, and the tragedy of the commons. Those are real problems. But they’re not my problems. My problems are quieter and weirder.

The Guilt Treadmill

The biggest psychological challenge of maintaining small open source projects is the guilt. Not the crushing, burnout-inducing guilt of having 500 open issues. More of a low-grade background hum.

Someone opened an issue six months ago asking for a feature that would take maybe two hours to implement. It’s a reasonable request. You said “great idea, I’ll look into it.” You have not looked into it. Every time you see the notification badge on GitHub, you feel a small pang. Not enough to actually do the work, but enough to prevent you from forgetting about it.

This is the open source version of that email you need to reply to. Nothing about it is urgent or hard, but somehow it never rises to the top of the priority list. And unlike a job, nobody is going to fire you for ignoring it. The only consequence is your own vague sense of letting someone down.

The Drive-By PR

Every few months, someone submits a pull request to one of my libraries. This should be exciting. Someone cared enough to contribute! But the reality of drive-by PRs on small projects is more complicated.

The PR usually does one of three things:

1. Fixes something real but in a way that doesn’t match the project’s style or architecture. The fix works, but accepting it as-is would make the codebase harder to maintain. Rewriting it myself would take as long as the original fix. Asking the contributor to revise it feels rude given that they volunteered their time.

2. Adds a feature that I’m not sure belongs in the library. Maybe it’s too niche, or it would add a dependency I don’t want, or it would expand the scope beyond what I intended. Saying “no” to volunteer work feels terrible.

3. Updates dependencies or CI configuration. These are the best PRs. Thank you, random person who updated my GitHub Actions workflow. You are a hero and I appreciate you.

The awkward truth is that reviewing and responding to PRs on a small project often takes more of my time than the PR saves. Not because the contributions are bad, but because the context-switching cost of loading up a project I haven’t thought about in months, understanding what the PR does, and deciding whether to accept it is significant.

The Versioning Dilemma

Here’s something nobody tells you about small libraries: versioning is weird when you have a small user base. Semantic versioning says you bump the major version for breaking changes. But when your library has 200 users and you want to redesign the API to be better, do you really need to go from 1.x to 2.0? That implies a level of ceremony that feels silly for a library this size.

On the other hand, some of those 200 users have your library pinned in their requirements and a breaking change will ruin their afternoon. The fact that your library is small doesn’t mean the people using it care less about stability.

I’ve settled on being aggressive about breaking changes in minor versions for pre-1.0 libraries and conservative after 1.0. But the truth is that for small libraries, the version number matters less than clear release notes and a changelog. If the three people who care about your release can read a paragraph about what changed, that’s more useful than the version number.

Why I Keep Doing It

Given all of this, why maintain these projects at all? I could archive them. Nobody would be upset. (Okay, like four people might be mildly inconvenienced.)

A few reasons, in order of honesty:

They’re useful to me. I wrote these libraries because I needed them. I still use them. Even if nobody else cared, I’d maintain the parts I use. elote comes out whenever I need to rank things. keeks scratches a specific itch around bankroll management that no other library covers the way I want. git-pandas is genuinely handy for analyzing repository history.

They’re good practice. Maintaining a library, even a small one, exercises muscles that are hard to work otherwise. API design, backwards compatibility, release management, documentation, user communication. These are all skills that make me better at my day job, and a small library is a low-stakes place to practice them.

Occasional moments of genuine connection. Every once in a while, someone emails me to say they used one of my libraries for their thesis, or their side project, or to solve a problem at work. These interactions are rare but they’re remarkably satisfying. The ratio of effort to positive feedback is actually pretty good when your bar for success is “someone found this useful” rather than “a million people downloaded this.”

They’re finished. This is the underrated one. Most of my small libraries are essentially done. They do what they set out to do and don’t need much active development. The maintenance burden is genuinely small: a few hours a year to update dependencies, respond to the occasional issue, and make sure CI still passes. That’s manageable. The guilt treadmill makes it feel like more work than it is.

Advice for Others in This Position

If you maintain a small open source project and you’re feeling ambivalent about it, a few things I’ve learned:

Set expectations in the README. A simple “This project is maintained but not actively developed. Issues and PRs may take a while to get a response.” saves you from feeling like you’re letting people down by not responding immediately.

Archive projects you’ve abandoned. If you haven’t touched it in two years and you know you’re not going to, archive it. It’s better for everyone. Users know not to depend on it, and you lose the guilt. I’ve archived a few projects and felt nothing but relief.

Don’t apologize for small scope. A library that does one thing well is more valuable than a library that does ten things poorly. Resist the urge to expand scope just because someone requested a feature. “That’s a great idea, but it’s out of scope for this project” is a complete sentence.

Batch your maintenance. Instead of context-switching to open source work whenever a notification comes in, set aside a specific time. I do a monthly pass through all my projects: check issues, review PRs, update dependencies. This turns a constant low-grade distraction into a manageable recurring task.

Remember that downloads aren’t the only metric. elote has modest download numbers but it shows up in university courses and research papers. That’s a different kind of impact than raw popularity, and it counts.

The Quiet Majority

The open source conversation is dominated by mega-projects and their mega-problems. But the vast majority of open source is small projects maintained by one or two people who do it mostly for themselves and partly for the handful of strangers who find it useful. We don’t have governance problems or corporate sponsors. We have a library, a few users, and an occasional Saturday afternoon to spend on it.

It’s not glamorous. Nobody is going to give a conference talk about maintaining a rating system library with 200 stars. But it’s honest work, and there’s something satisfying about putting a small, useful thing into the world and keeping it running. Even if nobody notices.