Philosophy & Contrarian Thinking

I opened a pull request once, enjoyed writing it, and watched it sit for three years. I am not complaining. I was a guest in someone else's house. That is the deal: you may offer, they may refuse, and "nope" is still the contract.

What changed is not that maintainers suddenly became colder. What changed is that I can now run the same experiment for a fraction of the cost.

That gap. cheap production, expensive attention, is the actual story of open source in the age of language models. Most arguments about "slop" and "empathy" are people standing on opposite sides of that gap and using moral language for an economic problem.

Two honest urges

On one side: I use the software. I hit a wall. The official path is "fork it" or "use this unofficial hack." Forks are fine if you have time, taste, and a build pipeline. A lot of people don't. They just want the tool to talk to the KMS they already pay for. For example...

So you build a prototype. Not because you think the maintainers owe you a merge, but because a working thing in a branch is a better conversation than another "+1 would be nice." Before language models, that prototype was an expensive, faith-based experiment. You could spend a weekend, show up with something shaped more or less like a solution, and anyone in the thread could say "nope." That was acceptable. That is the social contract.

On the other side: maintainers don't starve for ideas. They starve for hours. Every extra backend is a dependency, a security surface, a release note, a user who will file a bug in three years when the cloud vendor changes an API. A plugin system is not "yes, add my provider." It is "we will live with this interface after you have moved on."

Both urges are legitimate. They do not automatically produce a good thread.

What "slop" is pointing at

"Slop" is a lazy word, and also not a meaningless one.

It does not mean "a machine touched this." A lot of good code is typed with assistance now, the same way a lot of good code used to be typed with Stack Overflow open. I have shipped plenty of both. The tell is not the tool. The tell is when the artifact asks the reader to do the thinking the author skipped.

In a pull request that usually looks like this:

• a large diff that arrives as a conclusion, not a question
• prose that sounds confident about tradeoffs the project already rejected
• tests that exercise the happy path and leave the scary path to the reviewer
• a tone that optimizes for "look, it works on my machine" instead of "here is why this belongs in this tree"

People say "lacking empathy" when they mean that. They don't mean you failed a feelings exam. Some of my exes told me that, but that's another story. They mean the comment or the PR did not budget for the other person's attention.

That usage is loaded. It is also closer to the old engineering meaning of courtesy: don't make the next person hold the whole design in their head because you didn't want to cut the work into reviewable pieces.

I care about results. Does this introduce fewer problems than it solves? That test still matters. It is not the only test. In a shared repository, "it works" is the start of the argument, not the end.

The cost inversion

The old bottleneck was implementation. You had to understand the codebase well enough to change it, or you didn't ship.

The new bottleneck is absorption, the cost of taking a patch into the tree. Anyone can produce a plausible patch. Almost no one can cheaply decide whether that patch should become load-bearing infrastructure.

So the social contract needs a footnote, but not a rewrite.

It is still fine to say "nope."

It is still fine to prototype in public.

It is not fine to confuse "I reduced my cost of trying" with "I reduced your cost of reviewing." Those are different bills. AI pays the first one. It does not pay the second. Cheaper prototypes do not entitle you to a cheaper "nope." They entitle you to try again, smaller, or somewhere else.

This is why a proof of concept and a merge candidate are different objects. A POC can be a bit ugly. It can be one commit called wip: can we even do this. Its job is to resume a conversation. A reviewable change is small, motivated, and shaped to the house style. Mixing the two, dumping a conversation-opener and then being surprised that nobody wants to rubber-stamp it, is how threads go sideways.

I would rather be told "this is hard to engage with" than hear nothing at all. That sentence is useful data. It is not a verdict on whether the problem is real. A clear "nope" beats silence every time.

Empathy, without the sermon

If empathy means "anticipate how this lands," then both sides owe some of it.

Contributors can:

• say what is a prototype and what is asking for review
• point at the decision, not the novelty: in-tree hook versus out-of-tree plugin, protocol, key type, compatibility
• cut the first patch until a tired person can read it on a phone
• accept that "already possible, albeit hacky" is sometimes the correct official answer
• stop narrating how much joy or pain went into the work. Effort is not a claim check.

Maintainers can:

• close things. Silence is more expensive than a short no, and a short no is cheaper than a grudging merge
• separate "we don't want this in core" from "you were wrong to want it"
• keep the workaround visible, so the next person doesn't have to invent the same hack
• remember that some of the volume they hate is downstream of years of no decision

Neither list requires anyone to become nicer in the abstract. They require people to treat attention as a limited reagent.

What I think is actually worth keeping

I like that models made the faith-based experiment cheaper. I like that someone who is not a full-time systems person can stand up a working backend and put it next to a three-year-old issue. I like that users who will never maintain a fork still get a chance to see a path.

I wrote about the artisan's Mk 45 recently: forty-five iterations on a chisel that is still not perfect yet. A prototype is allowed to be Mk 1. A merge request is the chisel you hand to someone else to swing. Different objects. Same shop, different job.

I do not like the emerging habit of using that cheapness as moral leverage: I produced a thing, therefore the project should metabolize it. That was never the contract. The contract was: you may offer, they may refuse, the software remains someone else's house.

The interesting future is not "AI PRs versus human PRs." It is whether projects grow an immune system that can tell a cheap experiment from a cheap mess.

A healthy version looks boring:

1. Issue first. One paragraph on the problem, one on the constraint, one on the rejected alternatives.
2. Prototype in a branch or a sidecar repo, labeled as such.
3. If maintainers want it, a sequence of small patches that each survive a skeptical reading.
4. If they don't, the prototype still exists for the people who need the unofficial path.

That last point matters. Official purity and user need can both be true. Documenting the hacky integration is often a better gift than arguing about whether core should grow another cloud vendor.

The golden age of forks... it might be another blog.

The part I had to write down so I wouldn't post it on the issue

English is not my first language. Words like "slop" and "empathy" arrive already hot. It is tempting to unpack them in the thread, explain the old PR, explain the model, explain that you would have done the same work by hand in 2022, explain that you are a heavy user and also an author of OSS, explain that you are only trying to help the people who cannot keep a fork alive.

Don't.

The future reader of that issue came for a key type and a protocol. They did not come for your theory of collaboration. If the theory is worth anything, it belongs in a separate place, where it can be wrong in public without blocking the patch.

The patch still has to answer the only question that gets code merged:

Does this solve more problems than it introduces — for the people who will still be here after the excitement dies?

If yes, make it small enough to check.

If not, leave the prototype on the porch and don't demand that the household rearrange the furniture around it. The door can stay closed. Nope is still a complete sentence.

If you built something useful, users will use your fork. Solve your own problems first. You might help some other vagrant user with the same one down the line.

Ciao!