is AI ruining opensource?

Open source isn’t being “ruined” by AI so much as by trust breakdowns—especially drive-by pull requests that arrive without context, without real-world need, and sometimes without honest disclosure. Across Neovim, Laravel, Tailwind, and Ghosty, maintainers describe a consistent pattern: contributions land best when they’re small, targeted, and earned through community participation, while large refactors, readme-only vanity edits, and opaque AI-generated changes tend to get ignored or closed.

A flashpoint example set the tone: a long-running Express.js prank where every few hours a PR updates only the README with a name tied to a video, creating noise rather than value. That behavior echoes across ecosystems—forks and “update the docs and credit me” contributions that don’t fix bugs, add features grounded in user needs, or respect maintainers’ time. The panelists repeatedly return to the same principle: open source is fundamentally about trust, and maintainers need signals that someone will follow up when things break.

Mitchell Hashimoto (Ghosty) emphasizes starting with community immersion—observe the “vibes,” then make a small change. He argues that big, scary changes from newcomers are hard to review because maintainers must spend time understanding risk and edge cases. He also pushes back on refactoring as an early move: newcomers often don’t know why code is the way it is, and “rewrite it better” frequently ends up identical, worse, or missing subtle behavior. Taylor Otwell (Laravel) adds that maintainers look for PRs that “read the room”—matching code structure and conventions—and for contributions that unlock real developer power with minimal churn. He dislikes huge PRs that touch dozens of files to satisfy a narrow edge case, and he warns against features invented in a vacuum rather than driven by real use.

All three project maintainers describe process as a filter for quality. Ghosty, for instance, requires PRs to close an issue; users can open discussions, where maintainers can assess whether an idea is worth building before code is written. That reduces “drive-by” changes that are hard to evaluate and may never align with maintainers’ taste. Triage also matters: helpers with GitHub permissions and community moderators help route questions and label issues so maintainers can focus on what truly needs escalation.

When AI enters the picture, the panel’s stance is pragmatic. AI disclosure helps maintainers calibrate confidence and review depth. Mitchell says his team catches non-disclosures occasionally and will close PRs when honesty is missing. Taylor reports daily noise, especially “refactor X” PRs that appear to be random code reorganization with no bug or performance justification. The panelists also caution that using an LLM without understanding—treating it as a black box—wastes maintainers’ time and damages credibility, particularly if it’s the first impression.

Finally, the discussion widens beyond tactics: the best path for aspiring contributors is to become a user, find an issue worth fixing, and join the community—often with coaching from experienced contributors. Creating one’s own open source project can also be worthwhile for career and community-building, but it comes with emotional and time costs. The shared conclusion is that open source thrives when contributors earn trust through context, testing, and follow-through—not when they chase visibility through vanity edits or opaque automation.