r/opensource bans solo projects and LLM-built projects: who loses, and why

r/opensource, the Reddit community where people share and discuss open source software, now bans two kinds of project from its feed: projects run by a single person, and projects built using large language models. Both rules hit the post that has always been the staple of a forum like this one, the post that says here is a thing I made, please look at it.

The two bans answer different complaints. The LLM rule is about volume. Tools that turn a prompt into a plausible-looking repository have made it cheap to publish code its author has never read closely, and every such post costs moderators and readers time to sort out. The solo rule is about something older: the one-person project posted for attention, never documented, and quietly abandoned.

Put together, though, they close the door at the stage where a great deal of open source begins. Linux started as one person's project. Most libraries people now depend on had a single author long before they had a community. The real argument is over what a community forum is for: finding those projects early, or protecting readers from the many that never grow up.

What the two rules filter out

Read as a moderation filter, the policy asks two questions of every project post. Does it have more than one person behind it? Was it built with an LLM? A yes to the first question or to the second is enough to remove the post. Only projects that clear both stay up.

That makes the rules stricter together than either is alone. A carefully written library by one experienced developer fails the first test. A team project that used an assistant to scaffold its test suite may fail the second. What survives is a narrower slice: multi-person projects that either did not use LLMs or do not say so, and the second half of that sentence is where the trouble starts.

The case for closing the door

The strongest argument for the LLM rule is arithmetic. Writing a working-looking repository used to take days, which acted as a rough filter on who bothered to post. When it takes an afternoon of prompting, the number of posts goes up and the average amount of thought behind each one goes down. Readers cannot tell at a glance which is which, and the only people paid in attention to find out are volunteer moderators.

The solo rule has a quieter logic. A project with one maintainer has one point of failure. If that person loses interest, changes jobs or burns out, issues stop being answered and the code stops being updated. Anyone who adopted it on the strength of a forum post inherits the problem. A second maintainer is not a guarantee of anything, but it is a signal that at least two people thought the work was worth continuing.

There is also the question of what the community is for. A subreddit that fills with launch announcements turns into an advertising board, and the discussion of licensing, governance and maintenance that keeps regular readers coming back gets pushed off the front page. Seen that way, both rules protect the conversation rather than judge the projects.

The case against

The objection to the solo ban is that it confuses a stage with a verdict. Almost every project is a solo project before it is anything else. The way it stops being one is that somebody outside finds it, files an issue, sends a patch and eventually takes on part of the upkeep. A community that only admits projects which already have a second maintainer removes itself from the step that produces second maintainers.

The LLM ban draws a different objection: the line is hard to place. Code completion in an editor, a question pasted into a chat window, a test file generated and then rewritten by hand, an entire repository produced from one prompt. Those are very different levels of involvement, and a single rule that treats them all as built with an LLM either removes careful work or gets quietly ignored.

The enforcement problem

A moderator looking at a linked repository can see some things and not others. The contributor list and commit authors are public, so a project that is visibly one person is easy to spot. Whether that person used an LLM, and how much, is mostly invisible unless they say so in the README or the post itself.

That asymmetry shapes how the rule behaves in practice. The solo condition can be checked; the LLM condition is enforced largely through disclosure. The author who writes a candid note about using an assistant for boilerplate gets removed, while the author who says nothing passes. Any rule that depends on self-reporting risks teaching people to stop reporting.

If you maintain a project alone

Losing one forum is not losing an audience, and some of what the rules ask for is worth doing regardless of where a project gets shared.

1. Make it survivable

   Write the README, the build instructions and a contributing guide as if you will not be around to answer questions. That is the concern behind the solo rule, and answering it directly helps anywhere you post.

2. Look for a co-maintainer

   Ask a regular issue reporter or an early user to take review rights. A second name on the project changes how it reads to strangers.

3. Be specific about tooling

   If an assistant wrote part of the code, say which parts and how they were checked. A vague disclosure invites the worst reading; a precise one shows the code was read.

4. Share where the rules fit

   Post where showing early, one-person work is the point, and keep r/opensource for discussion you can join without a launch to promote.

What to watch next

The open question is whether the rules hold their shape once they meet real posts. A blanket ban on LLM-built projects will be tested by every borderline case, from autocomplete to a generated test suite, and moderators will have to decide whether the rule means any use or substantial use. How they answer will decide whether disclosure keeps happening.

The solo rule raises a longer-running question. If the communities with the biggest open source audiences stop showing one-person work, early projects have to find users somewhere else, and the path from lone author to shared upkeep gets narrower. Whether other developer communities follow r/opensource, or position themselves as the place solo work still gets seen, is worth watching.

This article draws on Open Source Alternatives to Reflector? and answers to it (1, 2), on the Stack Exchange network, licensed under CC BY-SA 4.0.