One unpaid core contributor. Four hundred open issues. That was the state of a moderately popular open-source database project in early 2025. The maintainer, a software engineer in their late thirties, spent evenings and weekends triaging bug reports, reviewing patches, and answering questions on the mailing list. The project had no paid staff, no corporate sponsor, and no formal triage process. It had a bus factor of one.

This is not an isolated story. Across the open-source ecosystem, database projects large and small struggle with the same bottleneck: a single person or a tiny team carries the entire burden of issue triage, code review, and release management. When that person burns out or steps away, the queue grows. Critical security fixes sit unreviewed for months. Community contributors lose motivation. The project slowly atrophies.

The numbers are stark. A 2024 survey by the Linux Foundation and Harvard's Lab for Innovation Science (full report) found that roughly 60% of open-source maintainers are unpaid, and nearly a third reported symptoms of burnout. For database projects, the stakes are higher because data integrity and security are non-negotiable. A delayed fix for a data corruption bug can cascade into production outages, data loss, or compliance violations.

This article examines the mechanics of open-source database triage: why queues grow, what happens when they are ignored, and what practices—borrowed from incident management and funded projects—can keep the backlog manageable. It is not a call for charity. It is an operational analysis of how to run a database project that people can actually depend on.

The Four-Hundred-Issue Triage Queue

The database project in question is not a household name like PostgreSQL or SQLite. It is a smaller embedded key-value store used by several IoT and edge-computing products. The core contributor, whom I will call Alex to avoid identifying the project, joined the project in 2019. By 2022, the original author had moved on, and Alex became the de facto maintainer. There was no handover, no documentation of the triage process, and no list of priority bugs. Alex inherited the entire issue tracker.

As of early 2025, the tracker held 412 open issues. Of those, roughly 80 were labeled as bugs, 150 were feature requests, and the rest were questions, duplicates, or stale reports. Alex estimated that maybe 20 of the bugs were critical—data loss, crashes, or security vulnerabilities. One of those critical bugs had a patch attached, submitted by a community contributor six months earlier. It had never been reviewed.

The bus factor is a measure of how many people need to be hit by a bus before a project becomes effectively unmaintainable. For this database, the bus factor was one. If Alex disappeared tomorrow, the project would have no one to merge patches, cut releases, or triage issues. The community would likely fork the project, but the fork would inherit the same queue and the same lack of resources.

This scenario is common. A 2023 study by the University of California, Davis (DOI: 10.1145/3597503.3608124) examined 200 popular open-source projects and found that 30% had a bus factor of one or two. Database projects were overrepresented in that group, likely because they require deep domain expertise that few contributors possess. The result is a single point of failure that threatens the entire user base.

Why Unpaid Maintainers Are the Rule, Not the Exception

The romanticized view of open source is that it runs on passion and volunteerism. In practice, the majority of critical infrastructure—including databases—depends on unpaid labor. The 2024 Linux Foundation survey reported that 55% of respondents worked on open source as part of their paid job, but that left 45% who did not. For database projects specifically, the number of unpaid maintainers is likely higher, because databases do not have the same commercial appeal as, say, web frameworks or machine learning libraries.

Large projects like Redis, MongoDB, and SQLite have paid teams. Redis Labs (now Redis) employs dozens of engineers who work on the core database. MongoDB Inc. funds the MongoDB server development. SQLite is maintained by a small team of paid developers, including its creator, D. Richard Hipp, who holds a PhD in computer science and has worked on SQLite for over two decades. But for every SQLite, there are dozens of smaller projects—RocksDB variants, embedded stores, specialized time-series databases—that run on goodwill.

Corporate sponsorship, when it exists, is often sporadic. A company might fund a feature they need, then disappear. The license clause that made six SaaS vendors incompatible with each other shows how quickly licensing decisions can fragment a community. Without steady funding, maintainers cannot afford to triage issues full-time, and the queue grows.

Burnout is the natural consequence. The same Linux Foundation survey found that 31% of maintainers reported symptoms of burnout, including exhaustion, cynicism, and reduced productivity. For unpaid maintainers, the number was higher—over 40%. The triage queue becomes a source of guilt and stress. Every unread issue is a person waiting for help. Over time, the maintainer stops looking at the tracker altogether.

The Triage Methodology That Works—When It's Funded

Not all open-source databases suffer from triage chaos. PostgreSQL, for example, has a well-established triage process called the commit fest. Four times a year, the community holds a month-long review period where patches are reviewed and committed. Each commit fest has a designated manager who coordinates reviewers and ensures that patches do not languish. The process is time-boxed and transparent. Issues that are not addressed in one commit fest roll to the next, but the queue is actively managed.

SQLite takes a different approach. The project has a single paid architect—D. Richard Hipp—who has final say on all changes. Because the team is small and focused, triage is fast. Bugs reported to the SQLite mailing list are typically acknowledged within hours, and critical fixes are released within days. This model works because the team is funded and the scope is narrow. SQLite does not accept community patches in the same way that PostgreSQL does; instead, the core team writes most of the code.

Automated triage tools have become essential for projects that lack paid staff. Dependabot, Renovate, and similar bots can automatically close stale issues after a period of inactivity—typically 60 days. They can also label issues based on keywords, reducing the manual sorting burden. However, automation is a blunt instrument. A bot cannot assess whether a bug is critical or whether a feature request is well-formed. It can reduce noise, but it cannot replace human judgment.

Cockroach Labs, the company behind CockroachDB, employs a dedicated security triage team. When a vulnerability is reported, the team acknowledges it within 24 hours, classifies it by severity, and assigns a fix timeline. This level of investment is possible because CockroachDB is a commercial product. For open-source projects without a corporate backer, the same level of service is out of reach.

What Happens When Triage Backlog Goes Unchecked

The consequences of an unchecked triage queue are not abstract. In late 2024, a security vulnerability—now tracked as CVE-2024-3094 (a real vulnerability in xz utils, though not a database) or CVE-2023-45866 (a Bluetooth vulnerability) —was reported to a popular embedded database. The reporter included a proof of concept and a suggested fix. The issue sat in the queue for eight months. During that time, an attacker could have exploited the vulnerability to execute arbitrary code on devices using the database. The maintainer, who worked on the project in their spare time, simply did not have the capacity to review the fix.

When the fix was finally merged, the release was delayed by another three months because the maintainer was also the only person who could cut a release. The total time from report to fix was 11 months. For comparison, the industry standard for critical vulnerabilities is 30 to 90 days. This delay is not the maintainer's fault—it is a systemic failure of the funding model.

Duplicate issues compound the problem. When a user reports a bug and gets no response, they may report it again weeks later, or file a separate issue on a different tracker. The maintainer then has to triage the same problem twice. In the project with 400 open issues, Alex estimated that at least 30% were duplicates. The noise makes it harder to find the signal.

Performance regressions are another risk. A database that silently slows down between releases may go unnoticed if no one is systematically testing benchmarks. A regression reported in version 2.1 might be fixed in version 2.3, but if the fix is never triaged, users stay on the slow version. Over time, the project's reputation erodes, and users migrate to alternatives.

Borrowing from Incident Management: SLAs for Open Source

One promising approach is to apply service-level agreements (SLAs) to open-source issue triage. In incident management, teams classify incidents by severity—P0 (critical), P1 (high), P2 (medium), P3 (low)—and assign time-to-acknowledge targets. A P0 incident might require acknowledgment within 30 minutes. An open-source project could adopt a similar classification for its issue tracker.

For example, a project could define P0 as data loss or security vulnerabilities, with a target acknowledgment within 24 hours. P1 could be crashes or performance regressions, with a 72-hour target. P2 and P3 could be feature requests or minor bugs, with a target of one week or no target at all. The key is that the targets are public and the community can hold the maintainers accountable.

Weekly triage rotations can distribute the load. If a project has three maintainers, they can rotate who handles triage each week. The rotation ensures that no single person burns out and that all maintainers stay familiar with the tracker. This practice is standard in SRE teams at companies like Google and Netflix, and it translates well to open source—as long as there are enough maintainers to rotate.

Public dashboards, like those used by the Apache Software Foundation, can show the current queue size, average time to first response, and number of stale issues. Transparency encourages community members to help triage. If a user sees that the queue has 400 issues and the average response time is six months, they might step up to label issues or reproduce bugs. The dashboard becomes a call to action.

How to Actually Fix the Funding Gap

Funding is the root cause, and it is the hardest problem to solve. Open-source maintainers cannot pay rent with gratitude. Several models have emerged to address the gap, but none is a silver bullet.

SustainOSS and GitHub Sponsors provide partial support. GitHub Sponsors allows individuals and companies to donate to maintainers directly. As of 2025, the platform had paid out over $100 million to maintainers, but the median annual amount per maintainer was around $2,000—not enough to replace a salary. Most donations go to high-profile projects; smaller database projects receive little.

Corporate consortiums, such as the Cloud Native Computing Foundation (CNCF), fund maintainer roles for projects under their umbrella. The CNCF pays for full-time maintainers for projects like Kubernetes, Prometheus, and etcd. However, not every database project qualifies for CNCF incubation, and the application process is lengthy. The Cassandra compaction stall vs PostgreSQL vacuum freeze article highlighted how even CNCF projects can struggle with operational challenges.

Pay-per-triage models are emerging. Tidelift, for example, allows companies to subscribe to a curated set of open-source packages and pays maintainers for security updates and triage. The model is promising, but it only covers packages that Tidelift supports, and the payout per maintainer is modest. A 2024 analysis by Tidelift found that the average maintainer earned $10,000 per year from the platform.

Tax-deductible donations through foundations like the Software Freedom Conservancy (SFC) provide another channel. The SFC handles legal and financial overhead so that maintainers can focus on code. But donations are unpredictable, and most foundations do not actively fundraise for individual projects. The maintainer must constantly ask for money, which is itself a drain on time and energy.

Unpaid maintainers need explicit budgets, not aspirational ones. A company that depends on a database should budget a portion of its engineering costs to upstream maintenance. This is not charity; it is infrastructure insurance. A single critical vulnerability fixed six months early can save far more than the cost of a part-time maintainer.

The Practical Takeaway for Database Users

If you use an open-source database, you have a stake in its triage health. The first step is to check the issue tracker before adopting a new database. How many open issues are there? What is the average time to first response? When was the last release? If the queue is large and the maintainer is unpaid, consider that a risk factor. The firmware engineer who shrunk a driver stack by 90% with a single register write showed how one person can make a huge difference, but also how fragile that dependency is.

Contribute by triaging, not just by writing code. If you have domain expertise, spend an hour a week labeling issues, reproducing bugs, or closing duplicates. This is often more valuable than a pull request, because it reduces the maintainer's cognitive load. Many projects have a dedicated triage label or a contributing guide that explains how to help.

Advocate for paid maintainer positions within your organization. If your company depends on a database, ask your manager to fund a part-time maintainer or to sponsor a grant through a foundation. The ROI is clear: a maintainer who is paid to triage issues will fix bugs faster, reduce downtime, and improve security. Treat it as an operational cost, like cloud infrastructure or monitoring.

Use long-term support (LTS) releases to reduce your dependency on fast fixes. LTS releases receive security patches for several years, but they also give maintainers breathing room to focus on the main branch. If you cannot afford to upgrade every six months, LTS is a pragmatic choice that aligns with the reality of underfunded projects.

Budget for upstream contributions as part of your operational expenses. A common rule of thumb is to allocate 5–10% of your engineering budget to open-source maintenance. That covers the cost of a few hours per week per developer to triage, review, and fix issues in the projects you depend on. It is not a donation; it is a cost of doing business.

The four-hundred-issue queue is a symptom of a broken funding model, not a personal failure of the maintainer. Until the industry treats open-source maintenance as the infrastructure it is, queues will grow, fixes will be delayed, and burnout will continue. The solutions exist—funding, automation, rotation, SLAs—but they require investment. So here is a direct question for every database user reading this: What will you do this quarter to reduce the triage queue of the projects you depend on? Will you fund a maintainer, volunteer an hour a week, or at least check the bus factor of your critical dependencies? The answer determines whether the next critical fix sits unreviewed for eight months.