If you have ever shipped an open source project, you have probably felt the quiet pressure to host a public bug tracker, answer every ticket, and somehow still find time to write code. A recent essay from raccoon.onyxbits.de is pushing back on that pressure, arguing that maintainers are confusing a helpful convenience with an ethical duty.
The piece draws a line between "could be useful" and "you owe it to your users," and that distinction is what is making people talk. Below we break down what the essay actually says, why it lands differently for anyone running a small project, and how the same logic quietly applies to the way we run teams.
Where the pressure actually comes from
Before free hosting platforms, the default communication channel for a project was an email mailing list. Maintainers handled triage in their inboxes, and there was no global leaderboard showing how many tickets sat open.
The real shift happened when publishing became cheap. Projects became "projects" rather than loose collections of files. With that came public trackers, profile pages with activity graphs, and a persistent expectation that someone is always watching the queue.
The author is careful to say this is not a takedown of trackers themselves. Bug trackers are useful tools. The argument is that a useful tool is not the same thing as a required one, and treating it as required quietly changes who the project is for.
Why this matters
For most of our readers, the word "maintainer" probably sounds like it belongs to a different world. Stay with it, because the dynamics are uncomfortably familiar.
A team lead who runs a shared inbox, a Slack channel for cross-team support, or a public roadmap is sitting in the same chair as a solo maintainer. You decide what counts as in-scope, what is "nice to have," and what you simply will not do this quarter. Every time you respond to a low-context message at midnight, you are choosing between two futures for your team: one where you set the terms, and one where your inbox sets them for you.
The essay's deeper point is about scope creep dressed up as virtue. A bug tracker was sold as a way to get noise out of email. In practice, it became a place where support, feature requests, social commentary and the occasional troll all land on the same board. The maintainer quietly gets promoted to community manager, support agent, and moderation team, often without asking for any of it.
Our analysis
The strongest version of the argument is also the most uncomfortable: a public tracker changes incentives, not just workflows. Once issues are visible, "no response" reads as "abandoned." A red activity graph reads as "lazy." Maintainers start closing low-effort tickets, responding to drive-by complaints, and shipping small fixes just to make the dashboard look alive. That is not engineering, it is performance.
Compare that with the old mailing list model. Quiet months were just quiet months. A maintainer who shipped one big release a year was seen as focused, not negligent. Visibility is what turned acceptable silence into a sin.
The trade-off is real. Closed channels are calmer, but they also filter out the casual contributor who would have filed a useful bug. The right answer is probably not "no tracker ever," but "tracker on my terms," with clear labels, a documented scope, and a willingness to let some issues go cold without guilt.
Who should care about this:
| Audience | What's at stake |
|---|---|
| Solo maintainers | Reclaim time; stop performing productivity for strangers |
| Small teams | Distinguish between community management and actual development work |
| Open source users | Understand that free tools come with the author's rules, not yours |
| Platform teams | Apply the same scope discipline to internal queues and backlogs |
Say you are leading an internal platform team maintaining a shared library that three product squads depend on. Keep a public backlog for actual bugs, route how-to questions to a dedicated channel, and write a one-paragraph "what this board is and is not" pinned at the top. That single paragraph does more for your sanity than any moderation tool.
What to watch next
Expect more maintainers to start publishing short "scope" notes the way product teams publish roadmaps, and more projects to experiment with closing issues by default after a set window.
If you run any kind of shared queue, public or not, this is your cue to write down, in plain language, what you will and will not do with it. Clarity now saves a very awkward thread later.
Key takeaways
- A public bug tracker is a tool, not a contract, and you get to decide whether to use one.
- Most "obligation" pressure in open source comes from visibility, not from any license clause.
- If you do run a tracker, write the scope of what belongs on it, then enforce that scope calmly.
- The same scope-creep pattern shows up in shared Slack channels, support inboxes, and internal roadmaps.
- Quiet periods are a feature of focused work, not a sign that a project is dead.
Frequently asked questions
Does the essay say open source projects should never use a bug tracker?
No. It says a tracker is a useful option, not a required one, and that maintainers are free to choose other ways to receive reports, including email or a "no public tracker, by design" policy.
What changed that made trackers feel mandatory?
Free public hosting from platforms moved projects from private mailing lists onto shared, visible boards, and that visibility quietly turned "you could" into "you should."
Why do maintainers complain about their issue trackers filling up with non-bugs?
The essay points out that an "issue tracker" absorbs feature requests, support questions, and general discussion, so the queue becomes a mix of everything instead of a focused list of reproducible bugs.
Is there a license clause that actually requires maintainers to fix reported bugs?
Standard open source licenses include an "AS IS" clause, and the essay leans on that to argue maintainers are not legally or ethically on the hook for free support or fixes just because someone filed a ticket.
How can a small team apply this thinking without ignoring real bugs?
Publish a short scope note for any shared queue, separate bug reports from how-to questions, and let low-effort issues close on a schedule instead of lingering as guilt bait.