Ladybird Browser Stops Accepting Public Pull Requests (ladybird.org)
- Reference: 0183623366
- News link: https://news.slashdot.org/story/26/06/06/2025214/ladybird-browser-stops-accepting-public-pull-requests
- Source link: https://ladybird.org/posts/changing-how-we-develop-ladybird/
February 23: " [1]Ladybird adopts Rust, with help from AI ."
> I used [2]Claude Code and [3]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.
[4]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.
[1] https://ladybird.org/posts/adopting-rust/
[2] https://docs.anthropic.com/en/docs/claude-code
[3] https://openai.com/codex/
[4] https://ladybird.org/posts/changing-how-we-develop-ladybird/
This is more than just a halt to pull requests... (Score:2)
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 sh
...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)
> 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
Re: (Score:2)
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:
[1]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
[1] https://www.atlanticcouncil.org/content-series/the-5x5/the-5x5-the-xz-backdoor-trust-and-open-source-software/
Re: (Score:2)
> 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
They say they are open source, but (Score:2)
if the public can not pull the source, are they? Is this what they are saying? Maybe I don't understand.
Subject (Score:2)
> 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