Generally creating a lot of friction around contributing to a project defeats the whole purpose of open sourcing it.

A better policy might simply be to automatically (using AI for this is kind of an obvious thing to do) filter and classify incoming PRs and issues for complying with quality thresholds.

A huge PR that comes in without a clear discussion history in the issue tracker is kind of a rude thing to do. That should be an automatic close. Have some good contributor guidelines and then enforce them. With or without AI. Block repeat offenders that can't be bothered to stick to those. Most of the annoyance comes from having to do all this manually and getting distracted by all this noise.

A small, focused fix that comes in with a well articulated explanation of what was done and why is a different matter. It shouldn't matter if the contributor used AI or not.

The main issue is that the signal is drowned out with the noise with a lot of problematic contributions from new/unverified users. But those should be kind of easy to detect as well.

There are multiple ways to deal with this. But a blanket ban on AI is a bit throwing out the baby with the bath water.

I actually have the opposite problem on my OSS repositories. It seems people are to busy doing their own projects to actually open pull requests on my projects. There's a noticeable decline in the number of pull requests since last year.

> Generally creating a lot of friction around contributing to a project defeats the whole purpose of open sourcing it.

Is this friction? I think it's quality standards, and a flow that's relevant to a time when code is more of a commodity than before.

And contributing code isn't all that's valuable in OSS. Bug/UX reports and feature ideas are really valuable, more valuable now than code IMO.

Even before LLMs, I was much more likely to report an issue to an project if it was open source and I could go look at the code and confirm what's happening. Reporting a bug w/o this feels like wasting my time. Without source visibility, I'm usually inclined to just stop using the software (e.g. Microsoft products, or even "freeware"). With code viz, I can confidently report a bug with some sense of what the fix might entail, how long it might take, what my expectations for a fix might be.