The way that this is written strikes me as wildly over-optimistic and dangerously credulous towards slopmongers' claims about capabilities.
-
One of the very difficult tensions around this problem is that the extrusion enthusiast culture itself is deeply obnoxious, bordering on predatory. So enforcement of boundaries may sometimes need to be pretty confrontational. And it really shouldn't be incumbent upon maintainers themselves to need to constantly re-litigate basic project policy in every single PR, because that is a recipe for burnout. As a recent and striking example, consider *this* disaster:
Katerina Marchán (@zkat@toot.cat)
Attached: 1 image ominous "something happened here"
Toot.Cat (toot.cat)
Thankfully my maintenance portfolio exists in a backwater of obscurity and irrelevance, so I am able to think about this from at least a *partial* remove from the immediacy of the catastrophe. But even I can see a plethora of evidence—like the above—where it really looks like the extruders turn people into aggressive, unrepentant assholes. At least, they create a constituency of unrepentant assholes who are also LLM users.
-
Thankfully my maintenance portfolio exists in a backwater of obscurity and irrelevance, so I am able to think about this from at least a *partial* remove from the immediacy of the catastrophe. But even I can see a plethora of evidence—like the above—where it really looks like the extruders turn people into aggressive, unrepentant assholes. At least, they create a constituency of unrepentant assholes who are also LLM users.
If you are an enthusiast yourself who is interested in a sustainable open source culture, you should consider maybe dedicating some time to help a no-AI project you like fend off such people. Allowing this kind of direct abuse to take place with no pushback from your faction kinda tars you all with the same brush.
-
If you are an enthusiast yourself who is interested in a sustainable open source culture, you should consider maybe dedicating some time to help a no-AI project you like fend off such people. Allowing this kind of direct abuse to take place with no pushback from your faction kinda tars you all with the same brush.
On the resistance side, we need to figure out ways to talk to people who think that this is an acceptable way to conduct themselves in public understand that:
1. they should believe in their own abilities more
2. if they want a feather in their resumé cap, there's no credit or glory in getting an LLM to do the work, even if it gets the code into the project; it just marks you as a plagiarist
3. almost no project with *any* degree of popularity needs "more PRs", it needs more *maintainers* -
On the resistance side, we need to figure out ways to talk to people who think that this is an acceptable way to conduct themselves in public understand that:
1. they should believe in their own abilities more
2. if they want a feather in their resumé cap, there's no credit or glory in getting an LLM to do the work, even if it gets the code into the project; it just marks you as a plagiarist
3. almost no project with *any* degree of popularity needs "more PRs", it needs more *maintainers*To me, what this calls out for is a new type of contributor role, a person who can run interference to help the core technical maintainers actually maintain some enthusiasm and momentum for their own projects. FLOSS has long been starved for issue and PR triagers already, but the spampocalypse is escalating the deficiency into a catastrophe.
-
One of the very difficult tensions around this problem is that the extrusion enthusiast culture itself is deeply obnoxious, bordering on predatory. So enforcement of boundaries may sometimes need to be pretty confrontational. And it really shouldn't be incumbent upon maintainers themselves to need to constantly re-litigate basic project policy in every single PR, because that is a recipe for burnout. As a recent and striking example, consider *this* disaster:
Katerina Marchán (@zkat@toot.cat)
Attached: 1 image ominous "something happened here"
Toot.Cat (toot.cat)
@glyph > So enforcement of boundaries may sometimes need to be pretty confrontational.
A fairly obscure project of mine somehow gained the attention of some LLM thing, and I started getting multiple terrible PRs and issues every day. I rarely curse in writing, but the only thing that stopped the trend was closing each one with a simple "f****** bot" message.
That's been the best way to get from AI CS chatbots to a human a number of times as well.
Such dismal interactions.
-
On the resistance side, we need to figure out ways to talk to people who think that this is an acceptable way to conduct themselves in public understand that:
1. they should believe in their own abilities more
2. if they want a feather in their resumé cap, there's no credit or glory in getting an LLM to do the work, even if it gets the code into the project; it just marks you as a plagiarist
3. almost no project with *any* degree of popularity needs "more PRs", it needs more *maintainers*@glyph I find that (especially recently) so many people in my immediate vicinity are using ChatGPT or Claude and making artifacts and the like that helping these people out (either by legit CS/programming mentoring and showing the fundamentals and how to do things “by hand”, or just by letting them know they should reach out if they struggle or before they put things into production) feels to me the most effective.
I’ll especially focus on helping them build software that severs ties with the cloud (for example, most of the things people build can usually be a html file using opfs, or a container I can host for them/they can host on their own), instead of a lovable app or whatever ai platform they might be using. And design the software in such a way (APIs, etc…) that the things they will want to change are either easy to do by hand, or easily promptable without nuking the codebase (for example with local models). So… traditional engineering, really.
-
To me, what this calls out for is a new type of contributor role, a person who can run interference to help the core technical maintainers actually maintain some enthusiasm and momentum for their own projects. FLOSS has long been starved for issue and PR triagers already, but the spampocalypse is escalating the deficiency into a catastrophe.
@glyph has anyone tried simply banning discussion of the no-AI policy and banning anyone who wants to debate it?
-
To me, what this calls out for is a new type of contributor role, a person who can run interference to help the core technical maintainers actually maintain some enthusiasm and momentum for their own projects. FLOSS has long been starved for issue and PR triagers already, but the spampocalypse is escalating the deficiency into a catastrophe.
@glyph I think we're going to see tools that split contributions into multiple channels. A "trusted/verified" channel makes clear sense. I could also see two more channels along the lines of "possible human" and "likely AI slop".
I don't see many platforms prioritizing this, so I'm guessing it's going to be something we have to build ourselves.
-
To me, what this calls out for is a new type of contributor role, a person who can run interference to help the core technical maintainers actually maintain some enthusiasm and momentum for their own projects. FLOSS has long been starved for issue and PR triagers already, but the spampocalypse is escalating the deficiency into a catastrophe.
@glyph Couple of quick thoughts.
- "Slop-haunted world" is very good.
- The original post is a masterclass in FOSS myopia, focusing only on code and ignoring the social implications of the code or its provenance.
Assuming agents can produce reasonable code output (hardly guaranteed), is more of it "good" for FOSS? I am unclear if that's even true, since I agree with your point that what most projects need are maintainers, not more PRs. But I also think of FOSS as part of a larger social justice project, and in that context, I am really not so sure that happy acceptance of model-generated code as a norm is ultimately "good" for the movement. At least, not as currently constructed.
-
@glyph has anyone tried simply banning discussion of the no-AI policy and banning anyone who wants to debate it?
@mcc @glyph based on how the Olivia Hill rule goes, this would be shockingly effective
eg, this thread: https://ngmx.com/@pathunstrom/115545419415666949
-
@glyph has anyone tried simply banning discussion of the no-AI policy and banning anyone who wants to debate it?
@mcc I have to guess "no" if not even zkat has done so, even after *multiple* comments from the offender in the above post.
This strikes me as a situation where different approaches make sense in different contexts. Some projects should probably take that approach, and maybe even collaborate on blocklists to kick out transgressors. Other projects with higher emotional bandwidth might want to have an explicit goal of rehabilitation.
-
@mcc I have to guess "no" if not even zkat has done so, even after *multiple* comments from the offender in the above post.
This strikes me as a situation where different approaches make sense in different contexts. Some projects should probably take that approach, and maybe even collaborate on blocklists to kick out transgressors. Other projects with higher emotional bandwidth might want to have an explicit goal of rehabilitation.
@glyph the blocklist idea is interesting to me
-
One of the very difficult tensions around this problem is that the extrusion enthusiast culture itself is deeply obnoxious, bordering on predatory. So enforcement of boundaries may sometimes need to be pretty confrontational. And it really shouldn't be incumbent upon maintainers themselves to need to constantly re-litigate basic project policy in every single PR, because that is a recipe for burnout. As a recent and striking example, consider *this* disaster:
Katerina Marchán (@zkat@toot.cat)
Attached: 1 image ominous "something happened here"
Toot.Cat (toot.cat)
@glyph How dare you have boundaries! /s
I don't know how common this is, but there are quite a few places which have adopted (with various wording) "sealioning, intentional or not, will be destroyed with extreme prejudice". This seems to have preemptively reduced or outright stopped this sort of thing before it takes hold
I'm reminded of a very practical treatise written years ago by Joel Spolsky
https://www.joelonsoftware.com/2003/03/03/building-communities-with-software/After all these years, it's amazing how much of it holds up
-
@glyph the blocklist idea is interesting to me
@glyph i wonder if codeberg could be convinced to, instead of allowing participation by default, allowing something like an onboarding pass like Discords have. where you have to do something to get added to an allowlist before you can submit (issues/PRs/comments/whatever).
-
@glyph Couple of quick thoughts.
- "Slop-haunted world" is very good.
- The original post is a masterclass in FOSS myopia, focusing only on code and ignoring the social implications of the code or its provenance.
Assuming agents can produce reasonable code output (hardly guaranteed), is more of it "good" for FOSS? I am unclear if that's even true, since I agree with your point that what most projects need are maintainers, not more PRs. But I also think of FOSS as part of a larger social justice project, and in that context, I am really not so sure that happy acceptance of model-generated code as a norm is ultimately "good" for the movement. At least, not as currently constructed.
@mttaggart @glyph "FOSS as part of a larger social justice project".
THANK YOU. THAT
-
@glyph Couple of quick thoughts.
- "Slop-haunted world" is very good.
- The original post is a masterclass in FOSS myopia, focusing only on code and ignoring the social implications of the code or its provenance.
Assuming agents can produce reasonable code output (hardly guaranteed), is more of it "good" for FOSS? I am unclear if that's even true, since I agree with your point that what most projects need are maintainers, not more PRs. But I also think of FOSS as part of a larger social justice project, and in that context, I am really not so sure that happy acceptance of model-generated code as a norm is ultimately "good" for the movement. At least, not as currently constructed.
@mttaggart I think that most projects should maintain hard boundaries around rejecting any LLM output, for the reasons that you suggest, although obviously we have a long way to go on convincing people of that. However, "AI PRs not accepted" is not the same policy as "hurl expletives and insults at everyone who tries". *Some* of the people who are trying just don't know any better, and might be amenable to a friendly invitation to try again with code they wrote themselves.
-
If you are an enthusiast yourself who is interested in a sustainable open source culture, you should consider maybe dedicating some time to help a no-AI project you like fend off such people. Allowing this kind of direct abuse to take place with no pushback from your faction kinda tars you all with the same brush.
@glyph I've suggested this as a sort of "good faith" filter. Do they care about consent? Can you redirect them to thinking about consent? I'd be curious to know if it works.
Phie Lux (@sabrina@fedi01.unicornsparkle.club)
@zkat @xgranade I have an idea. If somebody tries to use the "unenforceable" argument, ask them if they would break the rules. If they say yes, they've outed themselves and that's an easy ban. If they say no, push them to see if they can identify the type of person they think would break the rules. Push back the ideological front lines and direct their attention to the bad actors they should be working against.
fedi01.unicornsparkle.club (fedi01.unicornsparkle.club)
-
@glyph i wonder if codeberg could be convinced to, instead of allowing participation by default, allowing something like an onboarding pass like Discords have. where you have to do something to get added to an allowlist before you can submit (issues/PRs/comments/whatever).
@mcc I am stuck on github for a bunch of reasons but if codeberg actually added clear, automation-assisted workflows for marking people as [potential contributor
️ contributor ️ auditioning maintainer ️ maintainer ️ core team ️ emeritus that might be a feature I need badly enough to switch -
@mcc I am stuck on github for a bunch of reasons but if codeberg actually added clear, automation-assisted workflows for marking people as [potential contributor
️ contributor ️ auditioning maintainer ️ maintainer ️ core team ️ emeritus that might be a feature I need badly enough to switch@mcc re: the blocklist, I think that it's something that would need to be handled very carefully, as we have previously seen that Making Lists can get us all into trouble very fast. but there's probably a way to do it without turning it into a professional blackball machine when the hype rebounds
-
@mcc I am stuck on github for a bunch of reasons but if codeberg actually added clear, automation-assisted workflows for marking people as [potential contributor
️ contributor ️ auditioning maintainer ️ maintainer ️ core team ️ emeritus that might be a feature I need badly enough to switch@glyph codeberg could probably be persuaded to add this if they got a PR for it. especially if you want a complex Jira-like flow like that, even if they had the time to architect it out they probably would not come up with the exact design you're looking for.
