• the weeds are spreading
• substance vs. performance
• indicators of pretend projects
• what good foss looks like
• the argument for gatekeeping
• keep the commons clean

A specter is haunting the open–source community: the specter of slop.

It’s impossible to escape. Visit any mainstream software or programming oriented community, and you’ll see it completely overwhelmed by one garbage post after the other.

A lot has been written about why AI generated code is problematic, often non–functional, and unethical. Basically, why we call it slop. I’m not here to contribute to that corpus. I think that task is much better suited to programmers and thinkers far more experienced than I.

The problem I want to talk about today isn’t exactly caused by AI and its consequences; but much like all forms of online spam, LLMs have certainly made the problem much worse.

I’m talking about dishonest, low–effort slop projects: how they’re poisoning the culture of open software collaboration, and making the FOSS world more painful for experienced developers, and less accessible for newcomers.

In this article, I’m going to be making an argument for gatekeeping. Not people, but culture, which is always worth defending. I’m not advocating for elitism, credentialism, or hostility towards beginners.

Instead, I say we should band together and defend the norms, values, quality standards, and our shared understanding of what open–source is for. In others words, I argue we should fight to preserve the things that made us fall in love with the FOSS community in the first place.

What I advocate is closer to keeping a garden than guarding a castle; there are weeds that choke out the plants, and if no one pulls them out, the garden dies.

the weeds are spreading

The open–source ecosystem has a problem: it’s being polluted by garbage. To be clear: I’m not talking about “bad code”. I’m not talking about posts by newcomers that don’t follow best practices or haven’t yet learned the conventions and expectations.

Like any programmer, I’ve written my fair share of shitty code. In fact, I continue to do so; most things I write are going to be liquid ass before I get around to polishing and fixing them. That’s expected, it’s part of the process.

But if you’re a novice, you may not have the skills necessary to make your bad code better. That’s okay, too. We were all beginners once, and barring newcomers from participating at all just because they can’t meet a certain quality bar is simply cruel and unfair. If we want our community to grow and sustain itself, it’s a given that novices should be taught how to participate.

When I talk about “garbage”, I’m not referring to something bereft of skill. I’m talking about projects that are low–effort, and dishonest. And this isn’t just a personal annoyance; it’s ecosystem pollution.

Slop projects clog up discovery and discussion channels, bury genuinely useful content under piles of noise, dilute the meaning of “open–source project”, and encourage inexperienced devs to mimic bad patterns. It harms everyone, especially newcomers. Taking a stand against slop isn’t toxic gatekeeping, it makes our spaces more welcoming by creating space for real novices.

substance vs. performance

As alluded to earlier, there is a distinction between “project slop” and AI slop. There may be a some overlap, but the concepts are not identical. In my opinion, while slop projects are more often than not majority AI–generated, they don’t have to be. Similarly, a project whose author made heavy use of AI tooling is not automatically slop; it’s just very likely to be.

If I had to define what separates slop projects from the rest, I’d say it comes down to their release–first mentality (as opposed to the standard “problem–first mentality”). Where “good” projects are usually built because the author needed to solve a problem, slop is built because the author wants attention. Where real projects are refined over time, slop is frontloaded with marketing and quickly abandoned.

There’s a core dishonesty to be addressed. Slop performs “project-ness” rather than actually being a project. They may mimic the aesthetics of one: a code of conduct, issue templates, contribution guidelines, development roadmaps, but they’re missing one crucial component: substance.

When you publish something under the banner of open–source, you implicitly enter a stewardship role. You’re not just shipping files, you’re making a contribution to a shared commons. That carries certain responsibilities: clarity about purpose, honesty about limitations, and a basic alignment with the community’s collaborative ethos.

Slop projects violate this social contract. They exploit the aesthetics of open–source without embodying the underlying ethos. The result is something that is not useful, does not solve its stated problem, and is often knowingly misrepresented by its authors. Engineering takes a backseat to marketing, and the “open–source” label becomes a kind of free advertising.

These “works” aren’t made to help people or solve problems, and their contribution isn’t a selfless act of giving. This cheapens the ecosystem. It erodes our trust in what it means for a project to exist, to be maintained. Slop treats open–source not as a commons to steward, but a stage to perform on.

indicators of pretend projects

It’s quite difficult to derive exactly the bounds of project slop. It can take on many different forms, and is constantly evolving, making attempts at defining a taxonomy an exercise in futility.

Instead, I’ve compiled a (subjective) list of general red flags: things that tip me off, or at least make me suspicious, that the project I’m looking at is, indeed, garbage.

Before getting into it, I’d like to point out the common thread across all these examples: these are, essentially, beginner’s projects that overstate their own importance.

A huge disclaimer: there is absolutely nothing wrong with being new, nor should we discourage anyone from publishing their learner’s projects and asking for feedback.

The problem isn’t that these projects are made by inexperienced developers, it’s that they’re being fundamentally dishonest about what they’re delivering.

If you wrote a shitty todo list app, by all means, please share that and ask for feedback; just don’t promise me a “revolutionary productivity framework that redefines workflows, made with ❤️ by developers for developers”.

Similarly, there’s no shame in copying something else or reinventing the wheel, (there’s really no better way to learn new skills), just don’t pretend like you’re doing something other than learning.

Note

There may be completely valid, non–slop projects that tick a couple of these boxes. Please treat these as a starting point for further investigation, not the be–all end–all.

Without further ado, here’s my list of project slop red flags:

1. The project has a website using the same vibe–coded template as every other slop project.

• You know exactly which one I’m talking about.
• Bonus points if there’s so much blur and smooth scrolling that my fairly-modern Android phone can barely render what’s supposed to be a documentation website at 15 FPS.

1. The only selling point is the open–source label.

• This doesn’t include OSS alternatives to proprietary software; rather, software for which open–source solutions already exist, but the author can’t tell us anything that sets their project apart.
• If “it’s open–source!” is the only thing you can say about your work, I’ll assume it doesn’t have any other substance.

1. Begging for contributions on Day One.

• The pattern I’ve noticed: serious, well–intentioned developers don’t beg for contributors; they let the project speak for itself, to which contribution will flow naturally.
• There’s nothing wrong with asking for contributors; but there’s something about being begged to contribute to brand–new weekend projects that puts a sour taste in my mouth.
• I’ve even had random people reply to (unrelated!) Reddit comments asking me to contribute to their project! Like, what?
• You are the maintainer, and there are no users, like, build something before outsourcing your obligations!

1. Community scaffolding, sans the community.

• When there’s a large amount of community scaffolding on a project that’s very new and doesn’t have any actual community activity — code of conduct, issue templates, and at least half the README is a “how to contribute guide”.
• The README has more badges, feature lists, and scaffolding than actual technical detail.
• Things that leave me with a feeling the project is more focused on “community growth” than delivering software.

1. Obviously AI–generated announcement post or README.

• This one should go without saying.
• Emoji overuse.
• Way too much bold text per bullet point.
• Light on technical details, and the feature list includes stuff like “lightweight CLI” and “one–click install”.

1. Is related to AI tooling in any way.

• This one may seem a bit unfair; that’s why this list is subjective.
• I’m sure there exists actually good AI tooling, but I’ll be honest, if I see a project whose description involves “LLM” or “MCP” literally anywhere, my immediate assumption is that the whole thing is vibe–coded garbage. And frankly, so far, that impulse has been correct.

1. Assumes GitHub is synonymous with git.

• Occasionally, I’ll run into projects that bill themselves as “git utilities”, just to find that they only support GitHub through its proprietary API, and make no effort to integrate with… well, git.
• When projects claim “git integration” and then make no effort to support any provider other than GitHub, it tells me the author doesn’t understand the ecosystem they’re claiming to participate in.
• If your tool only works on one corporate platform and breaks the moment someone uses Codeberg, you haven’t built a “git tool”, you’ve built a GitHub client dressed up as something more serious.

1. Seems more focused on the stack than the result.

• If your README lists “written in Rust for blazingly fast speeds 🚀” before even telling me what it does, I’m immediately leaving.
• If the most interesting thing to say about your program is the language it’s written in or the tech stack you used, I’m going to assume there isn’t anything else worth engaging with.

1. Announced before the project even exists.

• When the project has a logo, name, reserved domain, website, roadmap, etc, but little to no implementation.
• This tells me that the author is more interested in the image of being a maintainer than in shipping anything real.

what good foss looks like

You may already know the smell of garbage, so let me also share a brief, affirmative vision. As before, these are subject “green flags”, not some authoritative list.

• Small tools with small scopes.

• README is short, accurate, written after the fact.

• (It should be long only if there’s actual substance to document).

• No community scaffolding until a community actually exists.

• Author clearly uses their own project.

• Website (if any) is functional, plain, documentation–focused.

• No hype, no emoji fireworks.

the argument for gatekeeping

Gatekeeping should not be about skill Level. Good OSS can be written by a beginner, and good OSS can still be bad code. Similarly, Bad OSS can be written by a senior engineer: it could be “good code” that follows “best practices”, but still be a garbage project.

Project slop isn’t about junior mistakes, it’s about dishonesty and performance. We shouldn’t care about resume prestige, programming language purity, or whether someone knows the “right” patterns. We care whether the author respects what open source is. So gatekeeping, here, is defending a cultural ethic, not excluding new people.

Gatekeeping is a responsibility, not a superiority complex. I’m not some FOSS titan. I maintain a handful of projects that solve problems for me and a few other people. I receive the occasional issue, email, issue, and contribution.

That’s enough. Because I care about this community, I have a stake in keeping it healthy. Being a steward of open–source doesn’t require fame or success; the only credential I care about is an indication that you care about this ecosystem.

Gatekeeping can be a form of cultural transmission. Healthy communities have boundaries which are meant to teach newcomers how to participate. Gatekeeping is how people learn the rules:

• DON’T publish things that solve nothing, UNLESS you’re explicit about it being a learning project.
• DON’T pretend your toy project is something revolutionary.
• DO describe your project with honesty and integrity.
• DON’T expect feedback, but DO expect respect if you receive any.

Gatekeeping is what keeps these norms alive. Otherwise, the culture is diluted by people that don’t actually like software, just the aesthetics of being seen as someone that does.

Protecting the OSS culture is a shared responsibility because OSS is a commons. Repositories, discovery platforms, community feeds, these all get destroyed without stewardship. Slop is pollution, and gatekeeping is conservation.

By doing our part to reject low–effort slop from our communities, we protect newcomers from thinking slop is normal & emulating bad patterns, maintainers from drowning in noise, and users from garbage tools with misleading claims.

We can create a culture where small projects are respected, “boring” tools are valued, honesty is rewarded, craftsmanship matters, and developers feel safe to publish imperfect but real work.

In other words, we can protect those who contribute in good faith.

keep the commons clean

If you want to publish something unfinished, fine. If you want to learn in public, great. But don’t lie. Don’t market a half–finished weekend script as the next revolution. Don’t pretend you’re contributing when you’re really just performing.

Gatekeeping is just calling that out.

Everyone benefits from a culture built on honesty instead of cosmetics, beginners especially. Nothing sabotages new developers faster than the belief that vaporware and empty branding are normal parts of the craft.

If your project has substance, the culture will catch you. If it doesn’t, no amount of emojis or boiler plate can save it.

The fix is simple: make real things.

Or don’t.

Just stop pretending.