The Invisible Job of Maintaining an Open Source Project

If you have ever maintained a moderately popular open source project, you know what Saturday morning looks like.

You sit down with coffee. You open the repository. You see the badge counter on the issues tab. Forty-seven. You scroll. Some of them are good. Some of them are duplicates of the same question you have answered eight times. Two are bug reports that need real investigation. One is from a corporate user who is frustrated and wants you to know. Three are feature requests that are not actually about your project. Eleven are stale conversations that should be closed but you cannot quite bring yourself to close them because each one has a person attached to it.

You open the pull requests tab. There are nine. Three of them are dependency bumps from automation. One is a thoughtful contribution from a first-time contributor and you want to review it carefully, but you do not have the energy this morning, and you know if you wait too long they will lose enthusiasm and disappear. Two are from a regular contributor whose changes you trust. One has been open for six weeks and you have been avoiding it because the diff is large and you are not sure you agree with the direction.

You have not started.

This is the invisible job of maintaining an open source project. It is not the code. The code is the part that is easy. The code is the part that got you into this. The invisible job is everything around the code. The triage, the labels, the milestones, the comments, the closings, the releases, the changelogs, the contributors you wish you had time to mentor, and the ones you wish would go away.

This is also where maintainers burn out.

The unsung mechanics

Most of what makes an open source project actually function happens in a layer that is rarely discussed. The visible artifacts, the code, the README, the documentation site, are the part that gets the credit. The invisible mechanics are the part that determines whether the project is alive in twelve months.

These mechanics include, at minimum, triaging incoming issues, separating duplicates from bugs from feature requests from misuse. Maintaining a label taxonomy that makes the issue queue searchable for users and contributors. Defining and updating milestones that signal what is being worked on for the next release. Reviewing pull requests, with feedback that is technically rigorous and human enough that contributors come back. Cutting releases on a cadence, with notes that explain what changed and why it matters. Surfacing stale issues that have lost their context so they can be closed gracefully. Pinging contributors whose pull requests have been blocked on review for longer than is fair. Handling security disclosures privately and disclosing them publicly on the right timeline. Maintaining the changelog, which is usually the part that gets cut when time is short.

None of this is glamorous. All of it is required. Most of it is done by one person, occasionally two, on the side of whatever job actually pays them.

The reason most open source projects quietly die is not that the code becomes obsolete. It is that the maintainer eventually cannot do the invisible job anymore. The code keeps working. The project does not.

What compounding feels like

There is a moment, somewhere between the project becoming popular and the maintainer burning out, where the mechanics start to compound against you.

When a project has fifty issues, you can keep them in your head. You know which ones are real, which ones are stale, which ones are duplicates of something you already addressed in a comment three months ago. When a project has five hundred issues, you cannot keep them in your head. You start to lose context. You start to dread opening the tab. You start to apologize for slow responses. You start to feel like a worse maintainer than you actually are.

The same thing happens with pull requests. With releases. With contributors whose context you used to remember and now have to look up every time. The compounding cost of fragmented attention is the slow leak that turns engaged maintainers into reluctant ones.

The tooling that exists today is not built for this. GitHub itself is built for a maintainer with twelve issues and one or two contributors. At scale, the maintainer becomes the bottleneck because every action requires them to navigate, decide, and click. The work is not technically hard. There is just too much of it, and the interface is designed to be browsed, not operated.

What maintainers actually need

The standard advice given to overwhelmed maintainers is to delegate. Bring on co-maintainers. Empower contributors. This advice is correct and also rarely sufficient. Trusted co-maintainers are not abundant. The act of finding, vetting, and onboarding one is itself a significant investment that overwhelmed maintainers do not have time for. Many projects stay solo because solo is what is sustainable, even though solo is what is breaking.

What maintainers actually need is not more people. It is fewer steps. They need the parts of maintenance that are mechanical to become mechanical. They need to be able to say what they want done and have it done, without clicking through six dropdowns to make it happen.

The list of mechanical maintainer tasks is long, but the verbs are repetitive. Find. Surface. Close. Label. Comment. Open. Merge. Tag. Release. Most of these tasks do not require human judgment for the action itself. They require human judgment for the decision. Closing five duplicate issues is a mechanical task once the human has confirmed they are duplicates. Cutting a release is a mechanical task once the human has approved the version number.

The tooling we have today asks the human to do both, the decision and the execution. That is the wasted step. The decision is the part that requires the maintainer. The execution should not.

Maintenance as conversation

The pattern we keep seeing, both in our own maintainer workflow and in the workflows of the maintainers we have built for, is that maintenance becomes manageable when it collapses into conversation.

You sit down on Saturday morning. You open one window. You say "show me everything that needs my attention." The system surfaces the issues with new comments, the pull requests awaiting your review, the stale conversations that should probably be closed. You read. You decide.

You say "close every duplicate of issue 4012 with a comment pointing to it." The system asks you to confirm. You confirm. It is done.

You say "what pull requests have been waiting on me for more than two weeks?" The system surfaces six. You triage them in order of importance. You leave a comment on one, request changes on another, merge a third.

You say "draft release notes for everything merged since v3.4." The system pulls the merged pull requests, groups them by category, drafts the notes. You read. You edit two sentences. You say "publish as v3.5." It is done.

What changed is not the work. The same triage decisions get made. The same release notes get cut. The same conversations get had. What changed is the friction. The clicking is gone. The decisions remain.

This is the version of maintenance that does not burn maintainers out. It is the version where the work compresses into the parts that require a human and removes the parts that do not.

What you actually get back

The maintainers we have shipped this to tell us something consistent. The first week feels strange. They have spent so long doing the navigating themselves that they keep reaching for the GitHub tab out of habit. The second week the habit breaks. By the third week, the Saturday morning routine that used to take three hours takes forty minutes.

The forty minutes is not nothing. But the part the maintainers actually notice is not the time. It is the mood. The work that used to feel like an obligation feels like a project again. The contributors that used to feel like a burden feel like collaborators. The release that used to feel like a slog feels like a small celebration. The shift is qualitative before it is quantitative.

This is the part that the tools-as-productivity-multipliers framing misses. What maintainers need is not raw speed. It is the relief of not having to grind through the mechanical work to get to the human work. The mechanical work is what burns them out. The human work is what they enjoy. Compressing the first frees them to do more of the second.

What this changes about who can maintain

The interesting downstream effect of compressing the mechanics is that more people can sustainably maintain projects. A working engineer who could not afford to spend six hours of their weekend on triage might be able to afford forty minutes. A maintainer who was about to step down might find they can keep going for another year. The economics of maintenance change.

This matters because the world has more software that depends on more open source than at any point in its history. The maintainers of that software are largely uncompensated and increasingly overwhelmed. The math of who can keep maintaining what is grim. Compressing the mechanical work changes the math.

We are not under any illusion that better tooling solves the structural problems of open source maintenance. Compensation, governance, succession planning, those are real and unsolved. But the day-to-day friction is a problem we can solve right now, and solving it gives maintainers the oxygen to address the larger ones.

What GitChat brings to maintainers

GitChat is the conversational client for the work of maintaining a repository. It covers the full surface area of what maintenance actually requires.

It triages issues, surfaces duplicates, identifies stale ones, applies labels in bulk. It finds pull requests that have been waiting on review and tells you which ones are blocking releases. It generates changelogs from merged work. It cuts releases with notes you can edit. It manages milestones. It updates collaborators. It handles the parts of the project that GitHub gives you a beautiful interface to browse and an exhausting interface to operate.

Every action that changes state pauses for your approval. Destructive actions surface an extra warning. You stay in control of every decision. You stop having to be in control of every click.

You bring your own LLM key. You use the AI model you already trust. The chat lives in one window. The repository lives where it always has. The maintainer keeps the judgment. The tool takes the friction.

If you have read this far, you have probably maintained something. You know which parts of that work drained you. The code was not the problem. Everything around the code was. We built the thing that takes the everything-around-the-code off your plate. The judgment is still yours. The work is finally lighter.