Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

541–550 of 602 posts

Re: Changing how we develop Ladybird

#541
post #9

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.

Patches were coming less and less often for years prior to AI; it turns out that decreasing inflation-adjusted wages Y-o-Y plus ending desktop computer education in schools is the unnoticed death knell that AI highlighted. When no one can afford to hack on programs in their free time using skills they can’t afford to train (both due to monetary and time-versus-jobs costs) then of course open source will fade.

Re: Changing how we develop Ladybird

#542
post #90

Earlier 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.

I argue that it’s no longer proof of being invested in a project beyond whatever benefit one derives from the PR. It wasn’t fully to begin with, but now it definitely isn’t at all :)

Re: Changing how we develop Ladybird

#544

I'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…

I’ve seen bounties for re-adding C# to web exports to Godot 4. [1] It’s something that’s had some technical roadblocks for the engine’s developers, and looks like it might take a bit of time. [2]

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...

[3] https://github.com/godotengine/godot/pull/119972

Re: Changing how we develop Ladybird

#545
I think there's a lot of confirmation bias in this thread coming from two groups: anti-AI activists and cathedral-development proponents. They take what was written at face value and use it to further their narratives that AI is ruining the world and "social coding" is unsustainable, respectively.

What 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

#546
I wasn't aware of the Ladybird project before this story, and probably would never have reason to use it. But it portends the beginning of the end of software collaboration and the community that goes along with it. If AI is going to do all the coding, then it becomes a pointless exercise. The software tools that we use today will be obsolete in a few years. Nevermind the need for a browser - the paradigm of the GUI desktop won't be necessary either. It will all be verbal instruction. The remaining programmers will just serve a caretaker role during the transition period until their services will no longer be necessary.

Re: Changing how we develop Ladybird

#547
post #371

Earlier 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…

I missed the part where you weren’t going to belittle the contributions.

Re: Changing how we develop Ladybird

#548

Earlier 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…

> another engineering discipline

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
post #63

> 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…

> I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.

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.

Post reply on HN