Thoughts on the recent Debian GR

Community
41

The closest comparison I can think of is elementaryOS. It seems to be very similar to GNOME in many ways, but is on a much smaller scale. Although I don’t know how its community received it.

Regarding a referendum, I don’t think that makes a lot of sense. That would imply that banning LLM use and allowing it are both equally valid, and that if enough people just ignore the issues – or more realistically, acknowledge that they exist and say that they’re important but not actually consider them – and vote to allow them that’s perfectly fine. But I don’t know how we should handle it instead.

5 Likes
42

I think Proposal E is the most level-headed approach, and I’m happy to see Debian pass it. I would hope for something similar if GNOME adopts a policy. In my own day-to-day work as a software developer, I’ve found that, in good hands, the benefits of LLMs (esp. the current state-of-the-art ones) are simply too substantial to ignore. I also think that for open-source volunteer developers there is a lot of potential for making better use of their limited time, and I’ve quietly noticed this happening in places already. That said, I do acknowledge the issues with LLMs, especially in careless hands, and the burden they may cause for maintainers specifically.

Wholeheartedly agree with this. Whatever the direction ends up being, I hope we can at least not end up treating each other as enemies.

2 Likes
43

Some examples I’m aware, not sure if there are more:

5 Likes
44

I’ve been reading this thread on and off with a little bit of interest and a bit of concern. I’ve seen plenty of discussion about the negative repercussions of LLM use, some of which I’m sympathetic to. These do fly in the face of what I personally see, and perhaps a different point of view may provide some balance to the discussion.

Now I’ve been developing software for coming on forty years, including various contributions in a limited sense to things like seed, and the occasional bug report on Vala and GTK. I have only been using LLM technology for the last year, and I’m based away from the tech bubble area both online and offline, so obviously some of the arguments you are coming up with are not something I’ve seen before.

However, my present view comes more from the enjoyment of using LLM technology. It has made a considerable difference over the last 6–9 months. I have serious concerns about RSI, and ergonomic keyboards are only a delaying tactic. I also don’t consider my value as a software engineer as someone who can type lots of code; it’s more in the intelligence of designing interfaces, classes, etc., and understanding how a system goes together, which is why I’m a little confused about why LLMs would be regarded as competition when they are generally terrible at it.

They are, however, insanely useful at doing the drudge work of software engineering—namely writing tests, running repeated tests, and doing the mundane work of looking up an interface (which honestly usually doesn’t rely on much intelligence to find out how to spawn a process, but still, if you don’t do it often, takes time and trial and error quite frequently, which LLMs significantly remove).

I also mentor junior developers in my company who are given access to LLM technology, as well as advice and encouragement. They do not actually use it as much or as heavily as I do, as they are still gathering knowledge as they grow as developers. However, it still benefits them, and I would not tell them not to use it, nor that they have to. I would want them to find their own way to make optimal use for their preferences.

Now, as far as developing guidelines, it would be very difficult to come up with anything that would please everyone. It would sadden me to see an outright ban, as it would probably just end up with people either ignoring it or not contributing, and the community not benefiting from the new ideas that could be implemented with LLM technology. A prime example, I guess, being one of my pet projects doing RPC of GNOME Shell to get rid of JavaScript crashing the compositor, or the various WebKitGTK projects that enable me and anyone else who wants to program using GTK technologies to not have to deal with Windows or Android. But these are all personal preferences, as I understand.

I am also very aware of the pain of maintaining a project where you’re shifting very low-quality reports en masse pushed by LLMs, which is a horrible way to abuse a maintainer. So there is not actual conclusion to this - but I just wanted to make sure that a good range of views was visible.

2 Likes
45

Relevant comment in a similar discussion in another project: Any official position on the use of AI? - #104 by ploum - Delta Chat

I believe that the proAI/antiAI from the point of view of users and developers are widely discussed.
But I want to consider the problem from a strategical point of view.

…

being anti-AI is a policy that can be changed later if we realize the world evolves toward ethical and reliable LLMs (try to read this sentence again but without laughing).
While the opposite is false

10 Likes
46

I am the maintainer of GNOME Commander. And while we are the opposite of a large project, we’ve adopted a strict “no LLMs” policy four months ago (reasoning explained in detail there, overlaps with many points made in this thread). The merge request template has a checkbox to confirm that no LLMs were used. So far I had to reject one merge request, which was arguably a good thing: this potential contributor explained that they lacked the knowledge to write a patch themselves, so they used an LLM to create some bad code which lacked basic understanding of what the issue actually is.

And even if you ignore the ethical concerns here (which you definitely shouldn’t), the issues are very obvious IMHO: LLMs make people overestimate what they can do and what they actually achieve. They feel very empowering, but they tend not to reduce cost but merely to move it. They can move it from contributors to maintainers. Or from maintainers to testers. Or even to the users who will be confronted with hard to reproduce edge cases in code that nobody understands.

Edit: Prior to this policy change a previous contributor committed lots of LLM-generated code to the project, and I’ve been busy for months cleaning up this mess, with no end in sight. So I very much second the sentiment above: once LLM contributions are endorsed, it is very hard to go back.

12 Likes
47

Very much agree with what you’re saying here @adamagicat.

I wrote about this topic on planet.g.o. The tl;dr is I think (a) we can use these tools to forward our mission to bring a free software desktop for everyone, (b) we need to find ways to do that while maintaining our values and community, and (c) the changes to how software is built are inevitable (and so (a) and (b) are a more positive way to deal with that change).

48

So far, I have been of the opinion that the assisted-by etc. tags are not very useful, and that not having them more strongly signals to submitters that they are responsible for the changes being submitted.

That said, between your comment, and the argument being made in this post by the SFC, I can see some value in having information on what tools were used in producing the work.

49

I came across this talk from Greg KH about his opinions on LLMs in the Linux kernel and thought it was interesting enough to share here as another opinion on the topic. (The talk is 35 minutes with 20 minutes of QA.)

50

In case anyone missed it, @alatiera proposed “The GNOME LLM Policy That I Want”, which for what it’s worth I fully endorse:

The GNOME Project prioritizes the social and human aspects of
collective software creation. Therefore:

1. LLMs ("AI") can not be used to create or modify
anything submitted to GNOME, or hosted on GNOME infrastructure.

You might be asked to prove your code meets this requirement.
You might be banned for trying to circumvent this policy.

The copyright angle

GNOME already requires that contributions be properly licensed. We know for certain that the copyright status of LLM output is uncertain. So we know for certain that if someone submits an LLM-generated contribution, they cannot be certain that they have the legal right to license it under the project’s licence.

Therefore GNOME’s licensing policy already prohibits all LLM-generated submissions.

12 Likes
51

IANAL, probably worth looking at the SFC’s section on copyright in their document on LLM usage.

52

Thank you for writing this, it’s brought me some hope for Gnome. I’ve felt very defeated reading about the policies in other projects, and I’m really proud of a lot of the Gnome team for focusing on a human-centric stance.

I’m only a user, but I’ve been actively searching for projects that are taking action against AI and particularly in the desktop front this has been quite the tiring endeavor… especially with a lot of projects taking a “users don’t matter” approach to feedback, or assuming every new account is a brigader and not a user who previously had no worries deciding to make an account to voice their thoughts. I don’t really feel comfortable using projects that don’t value their user’s feedback. Feels like the very thing I left Windows for.

No hate to any projects, I just feel betrayed by many.

9 Likes