Thoughts on the recent Debian GR

Community
1

Hello,

Our friends in Debian recently ran a vote to decide a project-wide stance on “LLM usage in Debian”, from a set of 8 proposed options. The votes are now counted and the winning policy is proposal E. Here’s an except from proposal E:

Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance, or documentation of software, packaging, documentation, and other media published within the Debian Project. We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration.

The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor’s responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian.

In the GNOME + Freedesktop world we haven’t spent much energy on this kind of debate so far. As far as I can see we’ve been staking out individual positions, mostly aiming to prevent wasting volunteer time on gratuitously bad AI-generated submissions e.g. for Flathub, GNOME Shell extensions and GNOME Circle.

I think the spirit of these project-specific policies is similar to the spirit of the new Debian GR: treating LLMs as just a tool, and enforcing responsible use of them.

As I observed in my last blog post, people contribute to open source for different reasons, sometimes that reason is activism, and seeing a project you contribute to decline to pursue a particular cause might lead you to disconnect entirely from that project. Debian has already seen one such resignation since the vote.

The Debian vote was close run, three other options were close to winning: proposal F proposal B and proposal D. Each of these read to me like a variation of the same thing: “A cautious approach to generative AI”, “Allow AI-Assisted Contributions with conditions”, and “Accept AI contributions for Debian specific work”. Of course there were options to prohibit use of generative AI, two of these could have won in a parallel universe : proposal G “Avoid the use of LLM: climate destruction is a deal breaker” and proposal H “Debian is created by humans”.

I don’t have any agenda here, but I do have some thoughts and I’m interested to hear yours. The Debian vote has taken a lot of time and energy to come up with a policy that, to me, basically says “let’s go with the flow”. Do you agree with that interpretation? Would you be happy or unhappy if GNOME went through a similar discussion period and produced a similar result? Can you imagine a parallel universe where one of the other Debian proposals had won, and made the world meaningfully better?

1 Like
2

A good read on “just a tool”: There's no such thing as Just a Tool | deadSimpleTech

In general, I found the discussion on the Debian side prior to the vote to be dispiriting, even if the result was a foregone conclusion. I’d hope to have a better discussion on the GNOME project—even if I personally find any discussion about LLM use in a technical community to be utterly wasted time while the market remains a combination of irrational and fraudulent.

When the GTK developers discussed an LLM policy, my stated objective was harm reduction rather than a blanket ban, which is why I pushed for disclosure and extra effort on the review side, with any hint of slop being immediately disqualifying for contributions. If that same discussion happened five months later, I would have probably pushed for an LLM policy based on the Rust policy, but removing the “experimentation” carve out—there has been some experimentation inside GTK, which yielded very mixed results, and I don’t think it’s worth the time/effort/funding.

In any case, if we want to have a GNOME-wide policy on LLM use—and I think we ought to, at this point—we should look at an RFC for it.

9 Likes
3

In my opinion, this is something that should be decided at the project level, not GNOME level. It should be up to the maintainers of the project to decide whether they want LLMs in their projects or not. Then I would support including something like “follow project’s guidelines about LLM usage” in CoC.

At this moment it seems to me that many people are more leaning towards not using LLMs, but at same time there are many people who use it as if it was their best friend.

1 Like
4

We already are, but we need some sort of baseline.

Plus: we are desperately trying to get away from the tyranny of the project maintainers and towards a consolidation of responsibilities, with the establishment of teams and using RFCs. Deferring to individual project maintainers—who are, inside GNOME, most likely maintaining multiple projects by themselves—is just going to make an already messy minefield even more messy.

Having a GNOME-wide baseline allows establishing very obvious carve outs, if needed, as opposed to having to navigate through multiple policies.

3 Likes
5

Allowing AI for code authorship has been quite helpful in the projects that I work on, although I’ve seen some serious negative impacts as well. The benefits outweigh the risks, but I understand why some maintainers do not agree and choose to prohibit it. Letting project maintainers decide seems fine to me. A baseline that applies to all projects is not going to work because maintainers do not agree. The value of allowing (or prohibiting) AI-generated code is surely lower than the value of keeping GNOME maintainers happy.

I would like to establish a baseline for issue reports, though. AI is excellent at finding software bugs, including security vulnerabilities. Humans are awful at writing secure code – especially in C, C++, and Vala – and GNOME maintainers are no exception. Even the best GNOME projects with relatively high-quality code will currently fare quite poorly against an AI that’s looking for problems. AI-authored issue reports are now essential to improving software safety and quality, and it is manifestly unserious to claim otherwise. GNOME projects should not prohibit issue reports solely on the basis that they are authored by an AI or contain AI-generated content. I wrote more on this here. This is an opportunity to significantly improve GNOME’s code quality. Prohibiting problem reports is akin to shooting the messenger.

I don’t expect maintainers to fix issue reports, only to allow them. (Expecting volunteers to do work is not fair, and if your project is scanned by an AI, then the volume of issues might be quite high, especially if it’s written in an unsafe language.) And of course it’s fine to close bad issue reports. Some will be quite bad. But nowadays the overwhelming majority are good, and even the bad ones have often found a real problem that should be fixed. Please don’t ask humans to rewrite issue reports: that is impractical and unreasonable at the volume AI can report them. Also, consider that AIs will often provide patches to resolve the problem; if your project has banned all AI-generated code, then you probably shouldn’t look at the AI’s patch, but the temptation do so will be considerable. Perhaps adding a carve-out or exception for such patches would be reasonable.

GNOME projects should also allow AI for the purpose of translation, so users who do not know English can participate in our community.

5 Likes
6

No. Hard pass.

Translation is completely different than coding. I would always prefer quality over quantity and if translator cannot understand English than they cannot determine whether the output is valid or not.

2 Likes
7

This is a very interesting one.

I haven’t seen anyone arguing that AI should be banned for translation – if you count existing tools like Google Translate as AI. Those work pretty well if you put in a bit of effort yourself. So far I’ve found it very hard to chat to people who are rewriting their text completely with LLMs, though. I suspect people generally do this because they somehow think their English “isn’t good enough” or it’ll sound “more professional” to use the LLM.

So I would just like to state clearly: I’d much rather have a direct conversation with a person using basic English they wrote themselves, than a proxy conversation via LLM output where they are prompting the LLM with text and feeding my responses back into the LLM.

I realize I come from a place of privilege because my native language happens to be the language everyone uses in open source. I don’t think its helpful to talk about banning things in this context. But folk should be aware that I’m just not very interested in having a conversation that obviously has an LLM in the middle; while I am perfectly interested in having a conversation with someone who is at an early stage of learning English.

3 Likes
8

Apologies: I meant we should allow use of AI (e.g. Google Translate) to translate your own comments in GitLab and Discourse and such. I have no opinion on whether we should use AI for localizing GNOME software. GNOME has many localization experts, and I am not one of them.

Me too.

That said, this would be tricky to regulate because people who paste responses from LLMs don’t admit to doing so. They’ll admit to using AI for “research only” or “translation only” even if the entire pull request was written by Claude, and even if they are themselves an OpenClaw bot.

9

It’s pretty easy to tell if there’s any critical thinking in the loop, though. Link them to https://sendmeyourprompt.com/ and ask to see the prompt for example. (Disclaimer: I haven’t actually tried this yet, but I’m sure I’ll get there :- ).

Anyway, we drifted a bit away from my original question… It sounds like you’re not necessarily against GNOME following in Debian’s footsteps in principle, but pessimistic about whether it could actually improve matters in the project?

10

I don’t have any strong opinions on whether we should hold a vote, like Debian has done.

Probably it would be nice to have some sort of GNOME-wide AI policy. But if so, I suggest flexibility to accommodate maintainers’ differing preferences.