The biggest threat to open source is not the availability of LLMs to quickly generate large amounts of mostly working code. Rather, it is the appearance of users with a decisive sense of entitlement and a lack of communicative skills in open source repositories.
To be clear, LLMs by themselves are not unproblematic, and I don’t want to downplay the issues which many of my colleagues in the open source ecosystem face. Various projects had to restrict the ability of outside users to propose code changes due to the sheer amount of low-quality contributions. This is wearing the maintainers thin and makes maintaining projects even more burdensome as it already is. This is an issue and I want to recognize it as such.
But I believe that this is merely a symptom of an underlying phenomenon that is enabled by the availability of LLMs. I’m a sociologist, and as such I cannot help but always look at the social interactions to understand if there are issues coming from that direction. Having seen several harmful interactions on the Zettlr repository in the past two years, I think I am slowly starting to understand what is happening.
The current issues faced by most open source projects are decisively human. Even though LLMs act as a catalyst for them, the issues would not go away if all LLMs would stop working tomorrow. Instead, the non-availability of LLMs has kept the problem at bay via the simple fact that people who cannot code could not spam open source repositories with low-quality code. But the people who are now proving to be an issue for so many projects were problematic even before the advent of LLMs. These tools have merely lowered the threshold for such people to open PRs and attempt to gain a foothold in popular repositories. However, as the title indicates, there have always been entitled people with a lack of communicative skills, especially in an atomized society such as ours. LLMs have just made them much more visible.
Entitlement
The first of the two deadly sins is a sense of entitlement. Open source maintainers have long painted the “entitled user” as a menace that comes as part of the job; users who complain that there is a bug and feel like they are entitled to a fast-track access to the maintainers to get their own single use-case up and running; and who act very confused when their particular issue isn’t solved immediately.
But, to be frank, I think that is an almost harmless part of the job by now. Typically, providing a hint to a person that they are not the only user of an app suffices to make them realize their entitlement. I only had one or two really harmful interactions involving foul language on the repository in the ten years that I have been working on the app. But most people are very harmlessly entitled. They just didn’t think of the fact that they are not the only person under the sun, and can often be reasoned with. Dealing with that does cost me time, but typically only a few minutes.
The entitlement we are faced with right now is of a different kind. It is still entitlement, and there is still a sense of self-centeredness in the contributions. But it is a much more dangerous type of entitlement. Because I’m not talking about users who at least do realize that they don’t write code, and only want someone to quickly fix their problem. I’m talking about users who, embellished by their newfound superpower to turn natural language descriptions into mostly working code, decide to not even wait for a maintainer to tend to their issue, but instead “just fix it.” And then they are appalled if their PR gets closed without including their proposed changes into the project. “But I did make Claude write the code that fixes my issue. I tested it out, and if I click that button, it works exactly as I want it. Why don’t you just merge this?? Why do you hate me?!”
This is a form of entitlement not simply for quick help, but to become part of some piece of software, and they frequently don’t take no for an answer. There is a very short path from realizing that anybody can just make code changes to being frustrated that this is not as easy as they thought (or their LLM told them). And it shows. Comparing the discussions in user-reported issues to discussions in AI generated PRs, users who have little ability to code but a costly Claude Code subscription tend to be more persistent. Unlike complaining users, they did something – or at least they think they did. And when the questions start — “What does this code actually do?”; “Do you really expect us to read through 10,000 changes?” — they become aggressive much more often.
And this leads to the second deadly sin: because they could essentially “fast-track” contributing to open source via LLMs without even having to learn to code, they miss a second crucial feature: a sense for the rules and culture of a community.
Culture
Open source projects are only in part about the code. Sure, without code there would not be some app that users could use for free. But around each project, a community emerges. It is rarely a lone ranger endeavor. Most projects attract a community of both users and contributors who discuss where the project should head, how to implement new features, and generally lead a lively discussion around the tool. Users help users, some form communicative bridges between users and maintainers that translate the very different language we all speak, and everyone just tries to have a good time.
Over time, the interactions within the community and between community and maintainers ossifies into rules and norms. Certain interactional rituals emerge, and these rituals are different for each project. This is what is often daunting to newcomers who learned some code to contribute: they want to help, but are afraid of violating some unwritten rules. Over the years, this has led to me using very explicit language in my contributing guidelines to take this fear from newcomers away. Crucially, the only necessary prerequisite to starting to contribute to an open source project is to communicate and be empathetic to everyone around you. You know, basic skills we should have all learned in school.
Before the advent of LLMs, people who wanted to contribute code had to go through a learning experience to get to know the community and, en passant, learn the rules of the game. Then, when they actually made their first contribution, it was smooth sailing. After their first change got merged, I think, many feel proud and accomplished.
LLMs, however allow people to skip this learning process. They let people change apps directly, without discussing the pros and cons of the approach, and propose these changes directly. And once their changes actually work as they want it, they decide to open a PR so that others may also benefit from this. And that PR is often the first contact with the community of an open source project for these people. What they don’t know is: what is a good PR? How large should it be? What are things the maintainers typically want to see? By skipping this learning process, by skipping any exposure to the culture surrounding a project, it is very easy to craft a PR that fails at basic expectations.
Ultimately, LLMs make already atomized individuals even more lonely. Because people are now more capable than ever to fix things entirely without communicating with anyone but a generative language model, they forget that behind every program there is a community of people. And this has led to a wave of PRs that have only one of two outcomes: either the author opens the PR and then vanishes without a trace, or they become aggressive when they have to interact with other people who may see things differently than they themselves. In both cases, it is akin to dropping a bag of poo in front of my door, ringing, and by the time I answer the door, they’re already gone.
The issue has never been about LLMs. It was always about the culture. Respect the project, its community, and the rules of the game, and then you’ll be fine. Just show me that you see me and my position. That’s all I want. Regardless of how much LLMs you used to prepare the PR.
Rules and Regulations
This may now lead to a question: why do we have all of these rules and regulations in the first place? Technically, it is indeed possible to just push code, merge it automatically, and automate everything. So why should you be expected to respect some norms and rules that you had no part in writing? Isn’t this a waste of time?
Let me illuminate a bit on the rules surrounding projects, and why they are in place. From your perspective, a PR might involve fixing an issue, writing some code and then opening the PR. That means you’ll probably spend one to two hours implementing everything, and you are only concerned that this particular issue is being fixed. When a maintainer then takes a look at your suggestion, they have an entire barrage of concerns that they keep in mind while looking over your PR:
- Did you unknowingly break a seemingly unrelated feature?
- Do other workflows suffer from your change that the maintainers only know about because they spent years talking to users of the app?
- Did you accidentally include a security concern?
- Will your change be maintainable in the future?
- … etc.
As you can see, there is a lot more to every PR than it seems from the perspective of someone who just contributes a single time. So the expectation that you communicate by yourself and demonstrate that you did your part by trying to understand what exactly your code does is the first step to ensure that the contribution you wish to make is probably safe. The code review is the second step in which the maintainers ensure that the code fits the rest of the app, and is easy to maintain. This is the second time they expect you to do some work. But every hour you spend working on your contribution, they spend two to three hours. This is just part of the job. But in turn, this is why they can expect you to try to understand what you are doing, and communicating properly.
By dragging out each PR process just a little longer also means that there are more chances to spot potential hazards and fix them before the code gets into the repository. And by having you communicate frequently and honestly, you show the project that you’re not a malicious person who wants to implement some backdoor into the program. Because this also happens quite a lot. (The most recent case was that of xz where a contributor showed no red flags, but it turned out that they followed a years-long plan to insert a backdoor into the software and almost succeeded.)
So if you think that the rules around open source projects are harsh or strict, this is not because the maintainers want to insult you personally, or make your life harder. And, to circle back once to the culture part, nothing stops you from joining the community and directly asking: “Hey, could I make this contribution?” That’s the best way to ensure that your PR will succeed, because again, it demonstrates that you care.
Final Thoughts
Many complain that open source is under attack right now; with an almost unmanageable influx of low quality code contributions that are predominantly written by LLMs. But I’d argue that this is just a symptom of a much more human problem. LLMs are tools, and many people use them as such. But when the tool is met by a person with a strong sense of entitlement and a lack of knowledge about how open source “works,” that is when a nuisance becomes a serious issue.
Open source will prevail, because the reasons for why there is open source go deeper than that. Just as LLM code contributions are merely functioning as a lens that amplify bad human behavior, open source is also driven by the human urge to be productive without the need for monetary remuneration. And this urge won’t go away just because we can now see an influx of bad people into the ecosystem. Because once these people realize that they won’t get far with their attitude, they will go away. Either they will get themselves banned explicitly, or they will stop feeling the urge to harass volunteers, or they realize what they are doing and switch into a more honest and helpful attitude and become good contributors themselves.
Right now, we are merely inside a transitory period, a Sattelzeit, if you wish, because the mechanism through which anti-social behavior manifests itself has changed. But once the community finds efficient ways to deal with this new formulation of a quite ancient problem, things will probably go back to normal pretty fast. But of course, no one knows the amount of trust that might get destroyed in the process.