Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
Changing how we develop Ladybird
541–550 of 602 posts
Re: Changing how we develop Ladybird
#542Earlier quoted context omitted.
I think this is the key point. A few years ago, if I send a complex PR that compiles and passes tests, that implies a certain amount of time and cognitive investment on my part. It seems likely that I wouldn't invest that if I didn't also understand the codebase, the feature or bug I'm working on, etc. Now, that understanding is roughly as expensive as before, but AI has vastly reduced the cost of generating the code…
> that implies a certain amount of time and cognitive investment on my part Yes, this is the takeaway for me. A PR can no longer be a reasonable proof of work.
Re: Changing how we develop Ladybird
#543"I would have written a shorter letter, but I did not have the time." -- Pascal, 1657
Re: Changing how we develop Ladybird
#544I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…
There tend to be a lot of drive-by AI PRs attempt to “re-add” the feature, often not quite addressing the situation comprehensively. It seems like a bit of a local minima trap for the bots. [3]
[1] https://app.opire.dev/issues/01J8YJ06HPSY7ZAMAW08T83YBD
[2] https://godotengine.org/article/live-from-godotcon-boston-we...
Re: Changing how we develop Ladybird
#545What the Ladybird maintainers did here was messy and a punch in the gut to actual contributors who liked the project and the openness of it. There was no effort to shore things up, just a boilerplate message from a maintainer account then closing of your PR. Of course, Ladybird maintainers have no obligation to outside contributors but it shows a lack of grace nonetheless.
Reading between the lines, there seems to have been a stark shift in attitude from Andreas which is concerning. Ladybird started from SerenityOS (a hobby OS) and he always encouraged everyone to submit a patch. Sure, LLMs have increased the amount of slop PRs, but I feel like those are easy to spot and close accordingly. I don't have links handy, but maintainers would point to a section about AI usage in their CONTRIBUTING.md then close the PR whenever obvious slop was submitted. This idea that people "own" the code they contribute is strange to me; the code would be determined worthy of acceptance at review time, why does someone have to "own" it?
All that is to say: I think there's much darker things going on here and AI+security is a nice scapegoat. Time will tell, but this reeks of a rugpull in the future. Disappointing day.
Re: Changing how we develop Ladybird
#546Re: Changing how we develop Ladybird
#547Earlier quoted context omitted.
> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs). There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed. From the o…
Thanks for your work on nixpkgs but I think that shapes your perspective quite a lot - its a very different project from Ladybird. Not to belittle your contributions there but the majority of commits there are a few lines of code and much of it is declarative. I'm sure a lot goes into review of entirely new packages and there are some complex interactions between dependencies to consider on some changes but not in a…
Re: Changing how we develop Ladybird
#548Earlier quoted context omitted.
The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort. In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a…
> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem. It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't…
I think we're more like car mechanics in a lot of ways. The same way they might learn cars by working on their own, we learn computers. But I suppose that's still background of a sort.
Re: Changing how we develop Ladybird
#549> There will not be a [..] process for submitting patches by [any] means > Outside involvement still matters: clear bug reports So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it. Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly. As a user-and-eveloper, why would I sink time into a project with such…
You can do all that, and make a bug report with a fix.
What happens next is up to the maintainers. If they reimplement from everything you gave them, and sculpted the fix into its final shape, that’s a great outcome for everyone.
Re: Changing how we develop Ladybird
#550What should probably be done is PRs are treated as “reimplement requests”.
“You had your agent write some code? Great, we’ll take it from here, and reimplement it ourselves.”