Collectivists with power tools

Diego wrote a post this week about the LLM policy fights in GNOME and KDE. He splits FLOSS into two camps. “Collectivists” are in it for the shared journey, the mentoring, the friends. “Completionists” treat software as a product and other people as speed bumps. In his telling, LLMs are the lever the second camp uses to push the first one out.

I’ve spent most of my adult life on the collectivist side of that line. A decade at Mozilla, mostly on community building. Then co-founding Libre Space Foundation, where the whole point was that a bunch of volunteers with antennas on their roofs could build a global satellite ground station network together. So I read Diego’s post nodding along for the first half.

Then I got to the conclusion, and I had to write this. You can be a collectivist and use LLMs. The tool doesn’t pick your side. You do.

Where Diego is right

Let me start with what I agree with, because it’s a lot.

The failure mode he describes is real. Someone who already thinks of themselves as the expert points a model at a codebase, gets 80% of a feature, fills in the rest, and opens a merge request. The review becomes a formality. If you push back, you’re not arguing with a person anymore, you’re arguing with “the machine plus the expert”. Nobody got mentored. Nobody learned anything. The maintainer now has to review a pile of code the author only half understands. That is a bad trade for any community, and “expert slop” is a good name for it.

He’s also right that every tooling decision is political, and that a project should ask for whom it wants to go faster. I’d sign that sentence.

Where we part ways is on what causes the problem. Diego’s post blames the tool. I think the tool only amplifies what the person already does. The completionist who treats reviewers as obstacles was doing it before 2023 too. They just did it with 4,000-line patches written at 3am and a “trust me, I know this subsystem”. LLMs made that behaviour cheaper. They didn’t invent it.

The binary is in the wrong place

Diego’s two camps are useful, but he draws the border along the toolchain. I’d draw it along behaviour.

A collectivist, as I understand the word, is someone who:

Nothing on that list says anything about how the first draft of a function got written. You can do every one of those things with a model in your editor. And you can fail every one of them with nothing but vim and a very high opinion of yourself.

The book club analogy from the GNOME discussions is a nice one: we read the book because we want to read it, not to discuss a summary. Fair. But a book club doesn’t ban people who read the audiobook, or who needed a dictionary for the hard chapters, or who read it in translation. It asks that you show up having engaged with the thing, and that you talk to each other. That’s the right bar for a contribution too.

Hand-written code as a gate

There’s a quieter assumption in the post that bothers me more than the rest. The “big brain engineers” who “avoid reading documentation, writing boilerplate, learning unfamiliar code” are the villains. The implied hero is the person who does all of that by hand, because that’s what real engineering is.

I’m an architectural engineer. I’ve spent years around people building satellites, ground stations and radio software, and most of them are not leet coders either. They’re RF people, mechanical people, ops people, astronomers, students. In the SatNOGS network, plenty of the people who made stations work understood antennas far better than they understood Python. For most of FLOSS history, the price of entry for those people was: first become a decent programmer, then we’ll listen to your domain knowledge.

That price was always a filter, and it filtered in a familiar direction. It favoured people with free time, a CS education, fluent English, and the confidence to post a patch and take a beating in review. If the collectivist project is about “overcoming language and social barriers”, as Diego writes, then the barrier of having to type every line yourself deserves the same scrutiny.

Engineering was never the typing. It’s understanding the problem, choosing the trade-offs, testing against reality, and owning the result when it breaks. A structural engineer who uses analysis software is still doing engineering. A surveyor with an RTK receiver instead of a chain and a theodolite is still surveying. The judgement is the job. When we say that only hand-written code counts, we’re telling a lot of people who were finally able to build things that they don’t belong. That is a strange position for a collectivist to take.

A case from my own bench: vathra.xyz

So here’s a concrete one, since this debate needs fewer hypotheticals.

Greece has about 25,000 trigonometric points from the Hellenic Army Geographical Service. They’re concrete pillars on hilltops, the physical backbone of the country’s old geodetic network. Nobody really knows how many of them are still standing. Some have been destroyed over the decades, some are fine and just forgotten.

I wanted a map where hikers, surveyors and anyone curious could find these points, visit them, and report what they found, with photos. That became vathra.xyz. I built it entirely with LLMs. Backend, frontend, map, auth, data pipeline. I’m not a web developer and I wasn’t going to become one for a side project.

Did I lose the joy of making something? Not for a second. I made every decision that mattered: what a “condition report” is, how to handle the old Greek coordinate system, what gets published and under which license. I argued with the model, threw away its bad ideas, read the code it wrote, and fixed what it got wrong. It felt a lot like working with an eager junior colleague who types very fast and needs supervision. The creative part, the part that’s actually fun, stayed mine.

And then the collectivist part happened, which is what I really want Diego to hear. People showed up. As I write this, 114 registered users have filed 914 condition reports covering 829 points, and found 148 markers destroyed or missing. The dataset gets published as snapshots on Zenodo under CC BY 4.0, and the code is public. Hikers talk to surveyors who talk to people who just like old maps. None of them know or care how the API routes got written. They care that the thing exists, that it’s open, and that their reports go into a commons.

Without LLMs, vathra would not exist. It would be one more idea in a notebook. With them, it’s a small community doing citizen science on a piece of shared national infrastructure. I have a hard time filing that under “progress at all costs”.

About the bill

The second half of Diego’s post is about externalities: data centres wrecking towns, energy and water use, speculation driving up prices, pension funds exposed to a bubble. I don’t want to wave any of that away. The concentration of this technology in a handful of very large companies is a real problem, and I’d rather not pretend otherwise because I happen to find the tools useful.

But I think a contributor ban is the wrong lever for it, for three reasons.

First, it doesn’t move the needle. A GNOME-wide ban will not change a single data centre’s water permit. The companies building them aren’t waiting for our patches. What does move things is regulation, procurement rules, and pressure on where public money goes. Those are fights FLOSS people are good at, and we should be in them.

Second, we already don’t apply this test to anything else. Our projects run CI on cloud providers, mirror to platforms owned by the same companies, and ship on hardware with supply chains nobody would call clean. We make pragmatic calls about infrastructure all the time. Singling out one tool as uniquely disqualifying looks more like identity than principle.

Third, and most important: if we care about who owns this technology, walking away from it hands it to exactly the people we’re worried about. The collectivist move is to do what we did with operating systems, browsers and compilers. Build open models, open datasets, local inference, community-run infrastructure. Use them, improve them, and make them good enough that nobody has to rent intelligence from a hyperscaler. You don’t get there by declaring the whole field unclean.

On productivity, Diego links the METR study that found experienced developers were 19% slower with AI tools while believing they were 20% faster. It’s a good study and the perception gap is a useful warning. It’s also 16 developers working on large, mature repositories they already knew inside out. That’s the one setting where you’d expect the least help. It says very little about an architect building a map app, a translator fixing a string pipeline, or a student trying to understand a codebase for the first time. For vathra, the question was never “19% faster or slower”. It was “exists or doesn’t”.

What a collectivist policy could look like

Jordan Petridis, in his draft, is honest that a ban is unenforceable and works mostly as a statement of values, like a Code of Conduct. I think that’s exactly right, which is why the values it states matter so much. “Your tools make you unwelcome” is a different message from “your behaviour makes you unwelcome”. Only the second one is about community.

So here’s what I’d rather see written down:

  1. You own what you submit. You can explain every line, answer review questions yourself, and maintain it afterwards. “The model wrote it” is never an answer.
  2. Say how you worked. A short disclosure line in the MR. Not as a confession, just so reviewers know what kind of review to do.
  3. Respect the reviewer’s time. No drive-by patches of generated code nobody asked for. Small, focused changes. Maintainers can close anything that looks like output was pasted in without being understood, no discussion needed.
  4. Talk before you build. Big changes start in an issue or on Matrix with humans, same as always. A model can help you prototype, it can’t give you consensus.
  5. Mentoring stays human. Newcomer issues are for people learning the project. Solving them with a model to farm a contribution count misses the point.
  6. Prefer open. Where there’s a choice, prefer open-weight models and local or community-hosted inference, and help make those better.

Notice that almost none of this is new. Swap “model” for “a big patch you copied from Stack Overflow” and it reads like any good CONTRIBUTING file from 2012. That’s the point. The norms that protect a community were always about behaviour.

Closing

GNOME didn’t need LLMs for thirty years of great work, and it doesn’t need them now. Agreed. But “we didn’t need it” is also what people said about every tool that eventually let more people in. Graphical installers, web-based review, translation platforms, even Git itself.

I’m a collectivist. I build things with other people, and I believe the stuff we build should belong to all of us. I also use LLMs every day, and they’ve let me build things I couldn’t have built alone, which then gave other people something to gather around. I don’t see a contradiction there, and I don’t think I’m alone.

If the FLOSS world draws the line at the tool, a lot of people like me will quietly end up on the other side of it. Not because we stopped caring about community, but because someone decided that caring looks like a particular way of typing. Let’s draw the line at how we treat each other instead. That’s the line that was always there.

Sources