Closed for Contributions: Why Open Source Projects Are Shutting Their Doors and How to Keep Them Open

In January 2026, curl software running on tens of billions of devices shut down its bug bounty program. Not because it ran out of bugs or money, but because maintainers were drowning in AI-generated 'slop' reports, even after they instituted a policy banning anyone who submitted "AI slop," which too failed to stop the flood. In six years not a single AI-only report had found a genuine vulnerability. The lead maintainer described it as a DOS attack on the project and said the move was about ensuring the project's survival and the maintainers' intact mental health. curl is not alone, and it's not just bug bounties.

Across the ecosystem, maintainers are quietly closing the doors. In June 2025, libxml2's maintainer ended support for embargoed vulnerability reports, citing the unsustainable burden of security triage as an unpaid volunteer. Kubernetes' Ingress NGINX will receive no security patches after March 2026, the reason being maintainer burnout. This talk asks why projects are closing the door and what we, as contributors and community builders, can do so it stays open for the people who actually belong inside.

Four major points to discuss:

• AI slop as a DoS on maintainer attention. curl, libxml2, and many other OSS projects have argued that low-quality reports waste maintainers' time, drive burnout, and should in many ways be treated as if they are malicious.

• A burnout crisis. The 2024 Tidelift survey found 60% of maintainers are unpaid and nearly 60% have quit or considered quitting a project, with 61% of unpaid maintainers working solo.

• Trust turned into an attack surface. The XZ Utils backdoor (CVE-2024-3094) was a 2.6-year social-engineering campaign in which an attacker exploited a burned-out solo maintainer and shipped a backdoor which was rated CVSS 10.0.

• And it isn't new. Hacktoberfest 2020 became a DigitalOcean-sponsored, GitHub-enabled DDoS of meaningless spam wasting thousands of maintainers' time after a viral video showed students how to farm a free T-shirt.

The question isn't whether to gate contributions; it's how to gate for quality without slamming the door on good faith. The second half of the talk covers the solutions:

• What maintainers are doing that works. AI-disclosure-or-ban policies and published AI-usage guides; GitHub interaction limits; opt-in plus accepted-labels and reporting tools.

• What contributors and communities can do. At Point Blank, the student OSS community we run, every GSoC proposal goes through peer "war room" review so nothing reaches a maintainer as slop; we teach "contribute before you apply" and that a maintainer's attention is the scarcest resource in the project.

• What the industry owes. Pay maintainers. Money won't review PRs, but it buys the co-maintainers and time that end the bus-factor-of-one.

I'll close with a one-page checklist for contributors, community organizers, and maintainers to keep contribution spaces both open and survivable.

• An evidence-based picture of why maintainers are restricting contributions in 2026: AI slop, burnout, security, and incentive abuse which is beyond the usual "open source is underfunded" line.

• The maintainer playbook that measurably reduces noise, and the Hacktoberfest precedent that proves it can recover a community rather than kill it.

• A contributor-and-community model for not being part of the problem, drawn from running a student OSS community at scale.

• Concrete funding and governance levers, plus a take-home checklist for each role.