Ladybird Browser Stops Accepting Public Pull Requests (ladybird.org) 24
The Ladybird browser isn't opposed to AI coding tools, but it's just brought a new change to their code-contributing policies.
February 23: "Ladybird adopts Rust, with help from AI." Our first target was LibJS , Ladybirdâ(TM)s JavaScript engine... I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go... The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand.
June 5 (Friday): We will no longer accept public pull requests... A pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds....
We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution... Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
As part of this change, we will close all currently open public pull requests. We are grateful for the work people put into them, but keeping the existing queue open would keep that contribution path open in practice. There is no perfect time to make this change, so we are making it now. Going forward, pull requests will only be available to project maintainers. There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks...
Outside involvement still matters: clear bug reports, reductions, website testing, standards discussion, design discussion, security reports, and technical feedback all help move the project forward. This is the right change for Ladybird now. We are preparing to ship a browser to real users, and our development process has to match that responsibility.
February 23: "Ladybird adopts Rust, with help from AI." Our first target was LibJS , Ladybirdâ(TM)s JavaScript engine... I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go... The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand.
June 5 (Friday): We will no longer accept public pull requests... A pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds....
We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution... Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
As part of this change, we will close all currently open public pull requests. We are grateful for the work people put into them, but keeping the existing queue open would keep that contribution path open in practice. There is no perfect time to make this change, so we are making it now. Going forward, pull requests will only be available to project maintainers. There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks...
Outside involvement still matters: clear bug reports, reductions, website testing, standards discussion, design discussion, security reports, and technical feedback all help move the project forward. This is the right change for Ladybird now. We are preparing to ship a browser to real users, and our development process has to match that responsibility.
Subject (Score:3)
> The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
You know the pull requests dont get automatically merged, right
Re: (Score:2)
I think the obvious has to be stated, that "write a backdoor into this function and obfuscate it" is all that is necessary to destroy the trust in a project.
AI use in programming is probably "good enough", but I sincerely doubt it's "good quality enough of the time" and that's the point. Open source projects shouldn't blindly accept pull requests, and since users using AI can overwhelm any open source project with pulls of various quality, and there might be more than one actor behind an account, it's no lo
This is more than just a halt to pull requests... (Score:3)
This is more than just a halt to pull requests...
There will not be a separate process for submitting patches by other means.
...this is an end to all public contribution whatsoever.
While this is their project and they are free to do that, I take issue with labelling it as an end to pull requests when it's actually an end to any public contribution.
There is an answer to disingenuous pull requests. That is doing the work to review the code before it's implemented. Whether that's other AI tools, manual code reviews, or sandboxing and testing on a VM, nothing less than all of this should be being done anyway.
A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds....
This has been the case exactly never. Now, they may have used size = effort = metric-of-good-faith, but that was their assumption and their mistake. Again, shutting down pull requests and public contribution is not the remedy for the fact this false assumption was made in the past. That remedy is a return to (or start of) vigilance.
...and other thing... (Score:2)
I typically like my posts to stand on their own, but in this case, after re-reading the source article, I just had to add, it's no wonder I've never heard of Ladybird Browser before today. Nor will I likely hear about it in the future again either.
Re: (Score:2)
By the developer who made Serenity OS.
But a browser that runs on Linux but accepts no contributions is no better than any of the closed source Chromium derivatives. No distro is going to bother carrying un-upstreamed patches in their packages. Revisit in a couple of years if the project reaches maturity.
I guess they can still pry Firefox from my cold dead hands. Or pipe-dreams of Servo on Redox OS (rust all the way down).
Re: (Score:2)
I still use Librewolf for now, but I hope Ladybird makes it. I totally understand their denial of public pull requests in this environment. The LLM age has made things toxic and ain't nobody got time to groom through all the slop.
Servo is held by a shit company at this point. Fuck Firefox and let's hope for a decent Ladybird.
Re: (Score:3)
You will hear about it again, or at least we should all hope everyone does.
Re:This is more than just a halt to pull requests. (Score:5, Insightful)
There is an answer to disingenuous pull requests. That is doing the work to review the code before it's implemented.
That's true, but when it takes Joe Random Hacker 10 seconds to generate a plausible-looking pull-request, which requires Joe Project Maintainer to spend 30 minutes reviewing the code-changes in that request, and Joe Project Maintainer isn't getting paid for his time spent doing the review, you've got all the ingredients for a distributed-denial-of-service attack on your project's maintainers. Perhaps AI code-reviewers can restore the balance, but I don't know how many project maintainers would trust their codebase's integrity to them (yet).
Re: (Score:3)
They specifically outlined the trojan horse rationale for denying public contributions. Someone plays the long game by submitting patches and gets privileged access to the project and repository, then turns around and backdoors it on the behalf of a state actor.
Example:
https://www.atlanticcouncil.or... [atlanticcouncil.org]
"The XZ saga began when the original maintainer of XZ Utils was pressured by other contributor accounts into adding user JiaT75 as a maintainer of the project. JiaT75 had been contributing to the XZ Utils com
Re: (Score:1)
That's true, but when it takes Joe Random Hacker 10 seconds to generate a plausible-looking pull-request
It's not quite that easy, even with AI.
First you need a pull request with a plausible sounding purpose. In fact, you need a stated purpose which is both plausible and interesting.
Which means the maintainer:
1) Determines whether the purpose is interesting enough on its face to warrant attention
2) Then investigates whether the code does what the purpose says it does, which is in the broad strokes is much much easier than just investigating a random piece of code.
Perhaps AI code-reviewers can restore the balance, but I don't know how many project maintainers would trust their codebase's integrity to them (yet).
You don't implement code at the recommendation
Re: This is more than just a halt to pull requests (Score:2)
Re: (Score:2)
So what if it is actually an end to public contribution? Who said that all Open Source projects have to be open to code contributions by all and sundry random people?
>> There is an answer to disingenuous pull requests. That is doing the work to review the code before it's implemented.
Nice idea but we see many reports of Open Source projects being inundated with pull requests in recent times. Many AI generated garbage. It is not reasonable to expect the project developers to wade through all the slop.
Re: (Score:2)
OSS security has involved whistling past the graveyard and hoping for the best bsically all along.
but if you know... Linux kernel can deal with pull requests... I don't think they're going to convince me "critical software" can't have public contributions.
tbh I'm not sure they're wrong... maybe the ROI isn't there for the project...
but I also think Mr President there should have slept on it and word smithed more, because as it stands it radiates MUCH assholity, imo.
They say they are open source, but (Score:2)
Re: (Score:2)
A pull request is not "downloading the source code," it's "submitting a suggestion for a change to the source code." It's someone requesting the project "pull" their changes into the project.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's only a stupid name considering the all-inclusive platforms. Originally you had your repo (separately) online and requested someone to pull your branch for merging.
Re: (Score:2)
Emphasis added:
...to pull your branch for merging.
Re: (Score:2)
Not every branch needs to be merged. I can ask you to pull my branch and offer it in your repo without you needing to merge it (yet).
Re: (Score:2)
The responsibility of a browser (Score:2)
Who you are matters (Score:2)
Some FOSS projects have forgotten that, some are too underfunded to do it, bit there really is no way around it. LLM-type AI just has made that more obvious.