CourtBouillon

Why We Create and Maintain Open Source Software

The world of free software has always been more than writing code. Even if the root of open source is code, there’s always been a lot of topics that gather people: licenses, freedom, ethics, languages, community rules, quality, tests, architecture questions, ideas, drinks, friends…

Different communities have been built around different projects, and contributors usually like the values shared by the community. If they don’t like it, they can join a different community, or even fork the project to build a new community around it.

My first contribution to open source was the French translation of Coccinella, an instant messaging application. That was more than 20 years ago, I didn’t know how to code, even if I already was a Linux user for quite a long time.

Why did I contribute? Because I wanted a French translation of Coccinella. That was obvious. I remember how Mats Bengtsson, the maintainer, was really happy when I first sent the translation. I remember all his messages starting by "Gentlemen", and all his kind words. And I remember me thinking: if developing free software is spending my time to discuss with people like Mats, then I want to contribute to free software during my whole life.

And I did.

Contributing was cool. I could spend a few minutes correcting typos in documentation I was reading. I could spend hours fixing a small logic problem in an app I used. I did spend days debugging my BIOS and adding a few random lines in the Linux Kernel to get hibernation working on my laptop.

And then I created software, and I built communities. I was lucky enough to talk with many people of the open source community, from newcomers to rock stars. Sometimes we agreed, sometimes we disagreed. I learned so much from their code, from their messages, from their thoughts and ideas. I hope they did a little bit too. And I’m so grateful.

I am so happy to live from this job. Or… At least I was.

A Lot of Uninteresting Work, Done for Free

Things changed fast.

At FOSDEM 2026, I attended the keynote of Daniel Steinberg. He was talking about how bad he feels each time there is a security report, and how bad he felt when he woke up on the first Monday of January with 7 security reports.

A lot of people laughed during the keynote, because Daniel made jokes. But Lucie and I were feeling bad for him. I am sure that these jokes were no real jokes. They were a way not to cry. I feel this.

Reading long and complex security reports is exhausting. It takes a lot of time and energy, it must be done fast and well. This is not fun.

What’s worse than that? Most of the security reports are not real reports. The problem doesn’t exist for real. The code the report quotes doesn’t exist. The script that is supposed to reproduce the problem actually doesn’t.

What’s even worse? The person behind the report doesn’t exist.

curl maintainers took extraordinary measures. Why? Because this situation is not possible anymore. A lot of free software maintainers spend a lot of time to work for free, because they love the code, the community, the craft. And it’s OK, sometimes, somehow. But what happens when maintainers spend days reading soulless code, soulless reports?

This work takes more time, more energy, and is awfully uninteresting.

Nobody Learns Anything

Bad code, bad reports, bad issues, bad comments. In open source communities, there has been complaints about these topics since forever. There are good contributors, there are bad contributors, and everybody should at least RTFM.

Some maintainers are known to have a particularly harsh relationship with "bad" contributors. Linus Torvalds is one of them, he has strong ideas, and he can use strong words in his messages. Code is law, and bad code deserves angry feedback, so that users can learn how to write quality code the hard way. Technical merit is the only scale used to value contributions.

I don’t like this way of thinking, but I admit that it has a major advantage: the rules are clear, only the code matters, tools and people behind this code are not relevant to accept a contribution. If the contributors are not happy with these rules, they can find a new project to contribute to. If maintainers are not happy with new contributions and new tools, it’s their responsibility to make them help, instead of causing pain.

This is where I strongly disagree.

Even if you don’t care about people, even when you really don’t, this technical-merit-only way doesn’t work for some contributions anymore.

There was a security report for one of our projects. The name of a variable was misleading, and could give a false impression of security. The report was long, listing lines in code, including a proof-of-concept script and bullshit possible impact bullet points.

I spent days, I mean real days, trying to understand what was wrong. I wrote long messages, explaining that there was nothing wrong. I proposed the contributor to open a security fork repository, to show me what they have in mind. I reviewed all their commits, even if some of them were extremely stupid. The answers I got were contradictory and meaningless.

At the end, nothing changed. I got the famous "OK, you’re right, I was wrong, I’m terribly sorry." All of that was 100% useless.

The contributor is nobody. This is a machine with no brain behind. None of the code or the messages had a meaning. Nobody learned anything.

I repeat: even if you don’t care about people, the technical-merit-only way of doing doesn’t work for some contributions anymore. Humiliating people, like Linus Torvalds did (does?) is not a solution anymore, because nobody gets humiliated. New contributors will never fear your insults on the public mailing list, because they will never read them. Machines don’t care, they have no purpose. They will randomly propose stupid code, with long and complex walls of bullshit that make them look deep and smart. And after some time spent to read this statistically meaningful piece of crap, for nothing, my hate answer will reach the only place it can reach: the void.

Nobody learns anything. This is truly meaningless. I do care about people, I love them, I really do, they’re the main reason why I create open source software. But many contributors are not people anymore.

This example is one among many. The vast majority of my work is now triaging issues written by nobody, arguing with nobody, reviewing the code of nobody, reading comments written by nobody, rewriting pull requests of nobody.

One day, we got 21 pull requests, and at least as many comments on issues. Yes, in one day, by one contributor, who never contacted us before. It took me countless days to try to understand all these pull requests, reject most of them, rewrite some, and merge a few. And before you ask, they "were not random noise […], they were derived from real engineering work." Let me translate this for you: You didn’t write this code, but you reviewed it personally and seriously. Guess what? I don’t believe you. You may really believe this, but you lie to yourself.

Talking to Machines to Build Phony Resumes

Some cynical people may say: "But all contributions are good for the project! Even if machines write code, it improves the project, there is no reason to complain."

No, they’re not all good, for many different reasons.

First of all, killing the will of maintainers is bad for the projects. From the number of maintainers writing blog entries or contribution rules on the web, I can say that I am not alone hurt by the flooding.

And there are deeper reasons. The quality of the code proposed by new contributors is bad. Not because machines can’t write good code. Not because people always write good code. Because contributors don’t care.

Some new contributors don’t know how to code. They have a problem with WeasyPrint, and instead of opening an issue, they open a pull request with code that they don’t even understand, and a 1000-word wall of text that explains the problem that fits in 3 sentences in their heads.

These people really want to help, but they don’t. Their code is bad, and that’s normal, they have no idea of what they’re doing. But I have to read it. Their comments are long and useless, but I have to read them to find in them the original 3 sentences the user had in mind. And I admit that I hate reading someone or something trying to explain to me how the software I’ve been designing for 15 years works, listing versions of libraries that ceased to be dependencies of my project in 2020, with code that never existed, and diffs that both remove and add the same line of code at the same place (and I swear, all these details really happened, in just a few months).

Hi doctor, you’ve been studying medicine for more than 10 years, but let me explain you the disease I have and the pills you will give me. I read that on the Internet. The PDF of the prescription is already generated, with your signature, just print it, we’ll both save our time.

And…

Here is one last reason why this is bad.

A new type of contributors arrived. They never used the project, never read the documentation. They open a pull request with code they didn’t read, that solves a problem nobody has ever had.

Why do they do that? To improve their resume. Having a contribution to a project with a lot of stars is useful to show their future companies how good they are. Is the contribution useful? Nobody cares. The contributor doesn’t care. The company doesn’t care. The machine doesn’t care.

But, look at this impressive list of contributions I have on my automatically generated user page on GitHub! So many cool emojis, huh?

These new contributors may have good reasons. Getting a CVE in an open source project was their homework. Getting a job anywhere soon was needed to pay their bills. Whatever.

But, at this moment, these new contributors only care about themselves. They use machines to add artificial lines to their phony resumes. They use maintainers, their time, their will, their projects, for themselves only.

Free software maintainers have been complaining for long against big companies that use their code without any contribution. But this is worse, because copying a maintainer’s code is easy, whereas copying a maintainer’s time is not possible. These new actors suck the life out of free software developers, and that’s no exaggeration. They feed on us, like vampires. They don’t really want to kill us, but they have good reasons to do so, as a side effect.

There Is No Fatality

Hopefully, there are solutions.

First of all: no, I won’t be using machines to automatically handle the issues written by machines. Think about that, with your brain, just 2 minutes, for real. Configuring machines. To answer comments and code written by other machines. Instead of talking to humans. No. I have a higher consideration for humanity.

A lot of open source projects now refuse contributions that are not written by humans, with various details in rules. Loupe is a good example, with interesting discussions, and other projects following its lead among the GNOME ecosystem.

Another example is holidays, for curl maintainers for example: the summer of bliss. No vulnerability report accepted during one month. This is a drastic solution, but this is possible: they did it. Who will complain?

Other ideas can be investigated. Leaving GitHub, that acts as a no-brainer platform, could help. What if contributors had to create an account on another website, with a lot less visibility? What if their tools were just configured to work with Microsoft’s platform?

Reading how SQLite is managed is also refreshing. "Open-Source, not Open-Contribution. All of the code in SQLite is original, having been written specifically for use by SQLite. No code has been copied from unknown sources on the internet." That’s a strange idea, but it works, at least for them.

To be honest, we don’t know yet what we will do. But one thing is sure: we won’t let this problem break our motivation for long.

Our first step is to write a few guidelines for contributors, in our code of conduct. These are simple rules that will make our life better for issues that follow them, and will give us a great link to share when closing issues that don’t follow them.

At least that’s a start, and for sure, this is not the end.