Welcome to the Eternal September of open source. Here’s what we plan to do for maintainers.

Source: GitHub Blog

When the Cost to Contribute Drops

In the era of mailing lists, contributing to open‑source required real effort. You had to:

1. Subscribe to the list.
2. Lurk and understand the community culture.
3. Format a patch correctly.
4. Explain why the change mattered.

The effort didn’t guarantee quality, but it filtered for engagement. Most contributions came from people who had genuinely invested in the project.

The Problem with High Barriers

• Exclusion: The high barrier kept many potential contributors out.
• Effort vs. Reward: A lot of work was required before anyone could even try to help.

Projects recognized this and worked hard to lower the entry barrier, making open source more welcoming.

The Pull‑Request Revolution

Hosting projects on GitHub, using pull requests, and labeling “Good First Issues” dramatically reduced friction:

• Instant PR creation: A pull request can now be generated in seconds.
• Guided onboarding: “Good First Issue” tags point newcomers to low‑risk tasks.
• Broader participation: Communities grew and contributions became more accessible.

That was a good thing.

The New Balance: Friction vs. Trust

Friction is a balancing act:

• Too much friction → ideas and contributors are kept out.
• Too little friction → maintainers can be overwhelmed, eroding trust.

Today, generative AI makes it easy to produce code, issues, or security reports at scale. The cost to create has dropped dramatically, but the cost to review has not.

Why Most Contributors Are Still Worthy

• Good faith: Most want to help projects they care about.
• Learning & visibility: Contributing is a way to improve skills and gain reputation.
• Career benefits: Working on widely used open‑source can boost a résumé.

These incentives are not new and not wrong—they’re the same motivations that have driven open‑source participation for decades.

The Real Challenge

When low‑quality contributions arrive at scale, the review workload can outpace maintainers’ capacity. Even well‑intentioned submissions can overwhelm a project, leading to:

• Backlog of PRs
• Delayed feedback
• Eroded trust in the collaborative process

If trust—the foundation of open collaboration—starts to strain, the health of the ecosystem suffers. Balancing low entry barriers with sustainable review practices is now the key challenge for modern open‑source communities.

The New Scale of Noise

It is tempting to frame “low‑quality contributions” or “AI slop” as a recent, unique phenomenon. It isn’t—maintainers have always dealt with noisy inbound submissions.

• Linux kernel – Operates under a web of trust philosophy, formalized its SubmittingPatches guide, and introduced the Developer Certificate of Origin (DCO) in 2004 for a reason.
• Mozilla and GNOME – Built formal triage systems around the reality that most incoming bug reports need filtering before maintainers invest deeper time.
• Automated scanners – Long before GenAI, maintainers handled waves of automated security and code‑quality reports from commercial and open‑source scanning tools.

“Are you really trying to help me, or just help yourself?”

The question from maintainers has often been the same. Just because a tool—whether a static analyzer or an LLM—makes it easy to generate a report or a fix, it doesn’t mean the contribution is valuable to the project. The ease of creation often adds a burden to the maintainer because there is an imbalance of benefit: the contributor may get credit (or a CVE, or visibility), while the maintainer inherits the maintenance burden.

Recent Examples

• cURL – Ended its bug‑bounty program after AI‑generated security reports exploded, each taking hours to validate.
  Read the announcement
• Ghostty – Moving to an invitation‑only contribution model, requiring discussion before accepting code contributions.
  Contribution guidelines
• Various projects – Adopting explicit rules about AI‑generated contributions.

These are rational responses to an imbalance between the ease of generating contributions and the effort required to maintain them.

What we’re doing at GitHub

At GitHub, we aren’t just watching this happen. Maintainer sustainability is foundational to open source—and foundational to us. As the home of open source, we have a responsibility to help you manage what comes through the door.

We are approaching this from multiple angles: shipping immediate relief now, while building toward longer‑term, systemic improvements. Some of this is about tooling; some is about creating clearer signals so maintainers can decide where to spend their limited time.

Features We’ve Already Shipped

• Pinned comments on issues – Pin a comment to the top of an issue directly from the comment menu.
• Banners to reduce comment noise – Show a banner that encourages reactions or subscriptions instead of “+1” or “same here” comments, cutting down unnecessary notifications.
• Pull‑request performance improvements – Optimized diffs make the new Files changed view up to 67 % faster, especially for large pull requests.
• Faster issue navigation – Significantly improved browsing speeds help maintainers triage bugs more efficiently.
• Temporary interaction limits – Temporarily restrict activity for specific users on a public repository.

These improvements are aimed at reducing review overhead and streamlining the developer workflow.

Features We’ll Be Shipping Soon

• Repo‑level pull request controls
  Allows maintainers to limit pull request creation to collaborators or disable pull requests entirely. While pull requests were fundamental to the growth of open source, maintainers need tools to manage their projects effectively.

• Pull request deletion from the UI
  Enables the removal of spam or abusive pull requests, keeping repositories more manageable.

Exploring Next Steps

Walls don’t build communities. As we look ahead, our goal is to give maintainers more control while protecting the collaborative spirit that makes open‑source work.

Directions We’re Exploring (in consultation with maintainers)

• Criteria‑based gating

  • Require a linked issue before a pull request can be opened.
  • Define rules that contributions must satisfy before they’re accepted.

• Improved triage tools

  • Leverage automated triage to evaluate contributions against a project’s own guidelines (e.g., CONTRIBUTING.md).
  • Surface the pull requests that need the maintainer’s attention first.

These tools are meant to support decision‑making, not replace it. Maintainers stay in control.

Trade‑offs & Safeguards

• Restrictions can disproportionately affect first‑time contributors acting in good faith.
• All controls are optional and configurable to mitigate that risk.

Community Experiments

These approaches aren’t mutually exclusive:

• Education helps good‑faith contributors succeed.
• Guardrails help maintainers manage scale.

Why One Solution Won’t Fit All

Every project has its own values. The tools built around the platform become proving grounds for features that may later be adopted more broadly. We’re watching these experiments closely.

Rethinking Incentives

If we only build “blocks and bans,” we create a fortress, not a bazaar.

• Broadening the notion of “contribution.”
  • In WordPress, manually written “props” credit contributors for code, documentation, testing, community support, etc.
  • Recognizing diverse contributions surfaces trust signals (e.g., consistent issue triage, documentation merges) that help maintainers make faster, more informed decisions.

We want GitHub to surface and celebrate all the ways people move projects forward.

Tell us what you need

We’ve opened a community discussion to gather feedback on the directions we’re exploring: Exploring Solutions to Tackle Low‑Quality Contributions on GitHub.

We want to hear from you. Share what is working for your projects, where the gaps are, and what would meaningfully improve your experience maintaining open source.

Open source’s Eternal September is a sign of something worth celebrating: more people want to participate than ever before. The volume of contributions is only going to grow — and that’s a good thing. But just as the early internet evolved its norms and tools to sustain community at scale, open source needs to do the same. Not by raising the drawbridge, but by giving maintainers better signals, better tools, and better ways to channel all that energy into work that moves their projects forward.

Let’s build that together.

---

Written by

Ashley Wolf – Director, Open Source Programs at GitHub

I work on open‑source strategy and programs that support maintainers inside GitHub and across the ecosystem. I also serve on the Steering Committee for the TODO Group, where we help organizations use and sustain open source responsibly.

---

Explore more from GitHub