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 surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
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 post-ai world. They were always out of line & continue to be.
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.
Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from someone cargo-culting code from tutorials that, out of sheer luck, achieved a base level of functionality.
Moreover, as these tools become more expensive, people with money to blow on tokens will be able to drown maintainers that don’t have enough token-cash to help them deal with it.
There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs.
It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.
It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.
On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.
On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
> it will also make it more difficult to identify who to invite to join the priesthood
The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.
fwiw I asked Claude to look at GP's post and write me a story titled "The Cathedral, the bazaar and the junkyard" and I have a pretty good time reading his riff.
In the post, the ladybird maintainers say that they trust pull requests less than they used to, because many pull requests are authored by AI now. A big pull request no longer signals that the submitter put in a lot of work into it and it's committed to developing and maintaining quality code.
Not sure if this happened to ladybird, but the amount of junk vibecoded AI-slop pull requests has been putting an immense amount of strain on many open-source maintainers. Reviewing stuff like that is intensely energy draining an most of the time your comments will just be copy-pasted into claude code and the "contributor" will put in 0 effort themselves to try to make the code readable or maintainable.
Before AI, being open source and having to manage issues and PR's was already a huge task, burning out maintainers left and right. Now with AI, anyone with a terminal and a claude code subscription can open PR's...
This is direct result of AI as you can see in many other public repos.
before AI like 1 in 1000 would spend their time fixing something they had no idea about and even then considering how much time you spent and how few of those happened it made sense to review/talk about it.
now every "dev" with claude submits prs having absolutely no idea what they are even doing.
most of them would not even be able to create PR without AI in the first place.
and on top of that add slop bots that "fix" issues in the loop and create hundreds of PRs daily
Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.
(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)
It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.
(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)
Those corporations are not doing that out of the good of their hearts. They are doing so to assert control, in order to protect their business value. If it stopped being economical for them, they would stop tomorrow.
I do not think we should be eternally grateful for monopoly building.
I can understand where they come from. If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves.
I think the whole game of software engineering, open source or not, has completely changed. A lump of code doesn't mean or imply the same thing as it did 2 years ago.
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 compiles and passes tests.
Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).
"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"
As the FT summarizes,
> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.
So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.
And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.
The code just isn’t the main effort of work anymore. Anyone can generate the implementation, so it makes more sense than ever to instead hammer out the what, why, and how that underlies any code change.
I see all projects moving this direction. Makes more sense to hash out a plan together.
LLMs might be part of why Ladybird is making this decision, but they aren’t the only possible one: SQLite, for example, has been developed this way pretty much forever. To each their own, I guess.
This seems quite misguided and is sad to see. They have every right to do this, but I was looking forward to continuing testing Ladybird as it improves and contributing in the future. I hope servo stays open to contributions, as it seems like it's all we have left.
It makes sense when you have a somewhat fixed core team size. Frankly, in some regards, this is the responsible thing to do.
It means they’ll never grow modules or the codebase beyond what the team can reasonably maintain.
However on the other hand.. What does this mean for the existing team, are maintainers now worth considerably more to the project? What does this mean for the codebase, or the momentum of the project?
It’s an approach I would have expected for the likes of curl, or single-purpose libraries. But this is a mammoth decision for a mammoth project.
Linux has WAY more maintainers, and many of them just reviewed other people's commits for years. They had a crazy amount of contributions even before AI.
I think we're past beginning to warn, we've now reached the point of accepting Linux needs to remove drivers and features, because the maintainers just can't keep up.
This is not helped by everyone using the same LLMs to find the same vulnerabilities and flooding maintainers with duplicate reports to be the first to get that CVE and branded vuln on their resume.
Not really - it changes how the lines are drawn between components, rather than removing any of them.
The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.
The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.
There are numerous advantages of microkernels over monoliths, but even if Linux were a microkernel it wouldn't necessarily change the review pressure that the above commenter is talking about, because you still have the same number of components (filesystem, networking, drivers, etc) to develop and review patches for (although you do have more well-defined interfaces between components, which eases security).
I don't like this, but I understand it.
I've contributed to the LB project several times, and I have made friends IRL with people who have also contributed to the project. ( we are now friends at uni )
It feels like a stepback because instead of 30-45 contributors every month, you have 15...
i feel like there should be a way to trust a PR ID verification or in-person verification at FOSDEM/DEFCON/Chaos Communication Congress,UNI's, for example.
It says something about the fragility of contemporary software that a fragment of bad code could result in doom. I think we need to move to much more restrictive computation architectures, inherently partitioned, functionally pure, and resistant to type confusion, pointer manipulation, memory issues etc.
I don't disagree with the desire for more inherently secure architectures, but I don't think it's the most relevant issue here.
You're always going to have to trust some core same-privilege code--a browser renderer is a great example of this: it has to be able to see the entirety of the DOM it's rendering, right?
Higher-level languages can still help code review--for example, memory safety makes it harder to hide a backdoor via unsafe memory operations leading to code injection. But you're still, fundamentally, trusting these community contributions.
I think the real problem (as others noted here) is that:
- writing code is now much, much cheaper than ever
- understanding and designing code is still fairly expensive
So doing the former (in the form of a PR that compiles and passes CI) is not a good "staking mechanism" to prove someone has done the latter.
It saddens me to see the communities surrounding free software projects going dark because of the threat posed by AI tools, but I don't know what other solutions there are that would mitigate the threat, particularly when browsers are such a compelling target. Perhaps some kind of trust system a la arxiv.org, where existing users have to vouch for new submissions before a user is themselves trusted? Definitely still vulnerable to abuse, but perhaps less so.
> 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 rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.
It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.
> a pull request no longer tells us as much as it used to about the person submitting it
Nobody should need to know anything about any person submitting a pull request.
Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.
Reviewing code fixes is strictly easier than coming up with them yourself.
This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.
As a project you can always ignore or close a PR you want to write yourself instead.
But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.
Reviewing code in PRs is not a no-effort action. If there are 3 people working in the project, and thousands of people submitting bugfixes, then no matter how useful those bugfixes might be, the 3 people will be totally overwhelmed by the sheer number of PRs.
There might be value in your bugfix, but maybe that value is not greater than the cost of reviewing and accepting it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
This is completely false, for any sufficiently complex project. The fix might be a single line change, but the consequences might be far reaching.
> As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software?
Please don't! You don't owe the project anything. The other side of that equation is that the project also doesn't owe you anything. As simple as.
Firefox and Chromium are running much larger teams, let alone the Linux kernel, that other people suggested as a model. Maybe they can afford accepting your contributions.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
You can still tell them how you did it, just not in the form of code/patches. You should be able to describe it in prose so that the maintainer understands your solution approach.
They could make two kinds of pull requests and add much more strict criteria for public contributions. For example, they could say that the PR has to be smaller in size and well-documented for human review, otherwise it's closed by an automation.
And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to get it in.
Blocking public contributions means that they want to have complete control of the project and AI is likely a good excuse to do that.
That doesn't solve the volume or quality problem. LLMs can split one giant PR into 50 smaller PRs just as easily and "well-documented" isn't something you can determine automatically.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
Wasn't the entire goal of Ladybird to have an open and independent browser engine? Making it effectively closed to contributions makes it.. Not independent anymore. It's now dependent, on few people who work on it, just like any other closed-source or corporate-controlled browser.
I don’t think that changes the project independence, when a project is open to PRs you have the same dependency on maintainers accepting changes into main. And the project is still open source. But that does make it less community oriented
But opensource has always been about community. This way it becomes "source-open", even if you could make changes to it and run those changes yourself, the latter doesn't sound "opensourcy" to me.
It's not the only solution but it might reduce PRs by a decent amount I would think.
If you see a PR and the guy is verified, you can check his name, his linkedin and where he works, at least there is some accountability if he introduces malicious code.
If the goal is to reduce slop, define slop. As a maintainer of a project you should be able to tell if something is slop.
If you don't have time to read PRs (which is the real issue here) that's fine too.
My guess is they want to reduce the amount of PRs, and ensure that the quality of the PRs passes an extremely high bar.
I think it's not the issue with the added PR count, but the fact they have to review them. 1 big PR review is the same as 5 small PR reviews if you have to look at how it holds, edge cases and what not...
Well, then add some backpressure. Each contributor gets only a few small PRs a month, until they prove themselves. Contributors that don't have a credible online presence are automatically rejected. Etc
This is not really a valid criticism for an Open Source project. I built Ladybird from source yesterday and I am typing this comment in it now. So, I assure you that the Ladybird browser exists.
Of course, Ladybird is not production ready yet. Feature-wise, it is getting close. I can use it to do most of the things I want to do with a browser. Speed and reliability are another matter. I has gotten dramatically faster but normal users would still find it slow. But the biggest problem is reliability. I would not use it in its current form for anything that matters.
But for a complicated application that was started from scratch, not being ready yet is not an indictment. They claim it will be ready for regular users to try sometime this year and, from where I type, this seems realistic.
It's surprising to me how many people here seem offended that someone might just not want their code.
I guess it takes quite a lot of experience as a maintainer to realize that 'free' in 'free code contributions by strangers' is like 'free' in 'free puppy'.
What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway. Ladybird is not SQLite, it's under development and very likely will be forever. To me it looks like they are transitioning into a company, where this model makes sense.
A bit sad to see this. Of course they are free to do it the way they prefer, and there are successful projects like this (Notably SQLite) but there has to be a reasonable middle ground between "everyone can just flood us with 30,000-line 'Claude implement feature X make no mistakes' PRs" and "we're not open to outside contributions"
How would you decide what is the middle ground though? If a project allows some AI-generated PR if its good quality, then it is a burden on the reviewer on what is considered good or not.
I wonder how can a new browser engine survive with the source available model. Like, why would anyone support this, unless they have business association with the Ladybird developers?
It's not source available. It's OpenSource(TM) because of the BSD-2 license.
This is not unheard of. The most famous models are emacs & SQLite. SQLite doesn't accept outside patches, emacs is developed opaquely and only releases are put forward.
You can do this with GPL, too. You put out tarballs of the releases only.
There's a great misconception between Free Software, Open Source, and Open Development (bazaar model). They complement each other, but they are completely independent things.
Addenda: Looks like emacs' Git repo is publicly accessible now, but it's not a requirement for GPL or Free or Open Source software.
Indeed, while there is communication that the situation with merging external pull requests should improve, the reality is that it's easier to land a patch in Linux, than in Zig.
While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
> Now opensource will become a thing that only "influential" people can contribute to.
No. Having access to a slop generator doesn't entitle you to acceptance to any and all open source projects. You're still responsible for the quality of your contributions. Something that is completely lost on bullshit artists.
Don't put words in my ~mouth~ (keyboard) that I didn't ~say~ (type), I'm not saying I want my contributions to be accepted on equal footing even if they are generated by AI. What I'm saying is that solving this problem this way is going to make opensource much worse. We need a better way, and I'm not sure which is the better way, sorry.
I don't know about you, but as for me, when I contribute to opensource it's because I find some improvement that makes the project better because it probably polishes some rough edge around a kind-of particular use case (that maybe few people face, but still, it makes the project better for them; it amplifies the range of usecases that it can span to). If everybody does the same with their small improvements, the project becomes better for everyone, but none of the contributors of these small changes would have time to embark on maintaining a fork. Mantaining a fork is hard work, not only because software breaks over time (dependencies going obsolete or insecure, builds stop working because of old toolkits), but also because not pulling the latest changes from master would mean that your fork gets stagnated (and thus not worth to run it).
I truly understand why this step was taken, but it is still sad to see the death of open source or rather open contribution. Every project that turns away from open contributions is a project lost to the whims and fuckery of AI Bros.
What I realy want to know how sustainable a model like this is. How does one find new maintainers when old ones leave. When you cannot contribute anymore.
That's not entirely true. It's certainly the case that Ladybird is still under an open-source license, but the whole idea of the "Open Source" label was to move the emphasis away from having a free license to actually being open to patches in practice.
> Moving to a closed development model => opensource is just a gimmick,
How so? Many projects are open source (GPL, MIT, whatever) while closed development, and no one calls those a gimmick.
In any case, most open-source is going to move towards a closed-development model; there simply isn't the resources to review thousands of lines of PRs per hour.
Maybe, or maybe not. But it will certainly kill the community they've built up, and squander a huge amount of goodwill. Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that's only source-available? Not to mention how the sponsors might feel about this.
Too early to say. Once they enter "we now accept everyone to use Ladybird as daily driver" then there will be the real test phase. And, IMO, only after that phase has started and continued for some months, perhaps even few years, can a final conclusion be made. If ladybird fails then the Google empire has won permanently. Skynet slop will then be under control of Google, just as they stole all the advertisement money.
> 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.
It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project.
I think I didn't put the emphasis right in my comment above. The code is still fully open source, but the project that produces the code isn't. It's not dissimilar to other projects producing open source software.
This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.
AI contributions are only a part of the issue. Another part is where a contributor decides they want a specific feature and contributes it but then disappears off into the sunset when it comes to needing maintenance later.
"A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it."
Cool - how about fewer perma-bans on github for participating in discussions?
Also, as I have pointed out before, they seem to develop too slowly for a solid beta this year. You only have to look at the issue tracker and check for URLs not working or even crashing the browser. Ladybird may have gotten better in the last months, but imagine if 50.000 people are using it, you will see more bugs. How do they then handle bug reports?
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 surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
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 post-ai world. They were always out of line & continue to be.
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.
Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from someone cargo-culting code from tutorials that, out of sheer luck, achieved a base level of functionality.
Moreover, as these tools become more expensive, people with money to blow on tokens will be able to drown maintainers that don’t have enough token-cash to help them deal with it.
There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs.
It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.
It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.
On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.
On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
> it will also make it more difficult to identify who to invite to join the priesthood
The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.
If you grew up in a junkyard, getting adjusted to the social norms of a bazaar might feel like your way of life is being threatened.
In your analogy, is the junkyard the development model of vibe coding?
I look forward to the book: The Cathedral, The Bazaar and The Junkyard.
fwiw I asked Claude to look at GP's post and write me a story titled "The Cathedral, the bazaar and the junkyard" and I have a pretty good time reading his riff.
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.
They have rewritten a huge change of their project using llms.
How is it really related to AI? there have been issues with open-source and maintainers for a long long time
In the post, the ladybird maintainers say that they trust pull requests less than they used to, because many pull requests are authored by AI now. A big pull request no longer signals that the submitter put in a lot of work into it and it's committed to developing and maintaining quality code.
Not sure if this happened to ladybird, but the amount of junk vibecoded AI-slop pull requests has been putting an immense amount of strain on many open-source maintainers. Reviewing stuff like that is intensely energy draining an most of the time your comments will just be copy-pasted into claude code and the "contributor" will put in 0 effort themselves to try to make the code readable or maintainable.
Before AI, being open source and having to manage issues and PR's was already a huge task, burning out maintainers left and right. Now with AI, anyone with a terminal and a claude code subscription can open PR's...
My friend, the very article we are talking about this mentions this directly
This is direct result of AI as you can see in many other public repos.
before AI like 1 in 1000 would spend their time fixing something they had no idea about and even then considering how much time you spent and how few of those happened it made sense to review/talk about it.
now every "dev" with claude submits prs having absolutely no idea what they are even doing. most of them would not even be able to create PR without AI in the first place.
and on top of that add slop bots that "fix" issues in the loop and create hundreds of PRs daily
Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.
(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)
It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.
(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)
Those corporations are not doing that out of the good of their hearts. They are doing so to assert control, in order to protect their business value. If it stopped being economical for them, they would stop tomorrow.
I do not think we should be eternally grateful for monopoly building.
Chrome is Google's loss leader.
I can understand where they come from. If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves.
I think the whole game of software engineering, open source or not, has completely changed. A lump of code doesn't mean or imply the same thing as it did 2 years ago.
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 compiles and passes tests.
Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).
Also, this paper seems relevant: https://www.nber.org/papers/w35275
"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"
As the FT summarizes,
> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.
https://www.ft.com/content/8e9ae7a4-7209-4e2c-aa36-f3af77d6c...
So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.
And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.
The code just isn’t the main effort of work anymore. Anyone can generate the implementation, so it makes more sense than ever to instead hammer out the what, why, and how that underlies any code change.
I see all projects moving this direction. Makes more sense to hash out a plan together.
As they say, just send me the prompt instead, at least that's more useful.
yeah but they could get free token usage from the community
Yeah, but then it’s either an arduous manual review or incurring a bunch of token usage to review something that may be slop.
Ladybird going source-available is quite unfortunate, seems like Gecko is the only production-ready independent browser engine we're left with.
LLMs might be part of why Ladybird is making this decision, but they aren’t the only possible one: SQLite, for example, has been developed this way pretty much forever. To each their own, I guess.
Lua is the same IIRC: open source but not open development.
It’s MIT licensed, and the maintainers are always grateful for bug reports, but all the code in the project was written by just 3 people.
This reminds me sqlite.
This seems quite misguided and is sad to see. They have every right to do this, but I was looking forward to continuing testing Ladybird as it improves and contributing in the future. I hope servo stays open to contributions, as it seems like it's all we have left.
It makes sense when you have a somewhat fixed core team size. Frankly, in some regards, this is the responsible thing to do.
It means they’ll never grow modules or the codebase beyond what the team can reasonably maintain.
However on the other hand.. What does this mean for the existing team, are maintainers now worth considerably more to the project? What does this mean for the codebase, or the momentum of the project?
It’s an approach I would have expected for the likes of curl, or single-purpose libraries. But this is a mammoth decision for a mammoth project.
I guess we’ll just have to see.
Why don’t they take the Linux approach? A browser is like an OS. Linux continues to accept public contributions, through an esoteric process that discourages lazy contributors: https://www.kernel.org/doc/html/latest/process/submitting-pa...
Linux has WAY more maintainers, and many of them just reviewed other people's commits for years. They had a crazy amount of contributions even before AI.
The only problem with that nowadays might be that AI can do all the incantations that formerly acted as gates to contributors.
Maybe not. Sqlite has some kind of hand-written license-agreement waiver procedure.
The Linux approach is under pressure too. Maintainers are beginning to warn about too many contributions and too much churn to review it all.
I think we're past beginning to warn, we've now reached the point of accepting Linux needs to remove drivers and features, because the maintainers just can't keep up.
This is not helped by everyone using the same LLMs to find the same vulnerabilities and flooding maintainers with duplicate reports to be the first to get that CVE and branded vuln on their resume.
I know is a naive question, but it's genuine!
Is this the direct result of a monolithic kernel? And would moving more drivers out-of-tree mitigate this?
Not really - it changes how the lines are drawn between components, rather than removing any of them.
The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.
The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.
There are numerous advantages of microkernels over monoliths, but even if Linux were a microkernel it wouldn't necessarily change the review pressure that the above commenter is talking about, because you still have the same number of components (filesystem, networking, drivers, etc) to develop and review patches for (although you do have more well-defined interfaces between components, which eases security).
I don't like this, but I understand it. I've contributed to the LB project several times, and I have made friends IRL with people who have also contributed to the project. ( we are now friends at uni ) It feels like a stepback because instead of 30-45 contributors every month, you have 15...
i feel like there should be a way to trust a PR ID verification or in-person verification at FOSDEM/DEFCON/Chaos Communication Congress,UNI's, for example.
This rather feels like it's completely stepping away from the thing that made the community around Serenity and Ladybird so good.
I lost all trust in the project since the LLM rewrite. This new step is another red flag to me.
what rewrite? I thought it would switch to Rust but I still see it to be C++
It says something about the fragility of contemporary software that a fragment of bad code could result in doom. I think we need to move to much more restrictive computation architectures, inherently partitioned, functionally pure, and resistant to type confusion, pointer manipulation, memory issues etc.
I don't disagree with the desire for more inherently secure architectures, but I don't think it's the most relevant issue here.
You're always going to have to trust some core same-privilege code--a browser renderer is a great example of this: it has to be able to see the entirety of the DOM it's rendering, right?
Higher-level languages can still help code review--for example, memory safety makes it harder to hide a backdoor via unsafe memory operations leading to code injection. But you're still, fundamentally, trusting these community contributions.
I think the real problem (as others noted here) is that:
- writing code is now much, much cheaper than ever
- understanding and designing code is still fairly expensive
So doing the former (in the form of a PR that compiles and passes CI) is not a good "staking mechanism" to prove someone has done the latter.
It saddens me to see the communities surrounding free software projects going dark because of the threat posed by AI tools, but I don't know what other solutions there are that would mitigate the threat, particularly when browsers are such a compelling target. Perhaps some kind of trust system a la arxiv.org, where existing users have to vouch for new submissions before a user is themselves trusted? Definitely still vulnerable to abuse, but perhaps less so.
I think a trust system is the only way. Ladybird will need new/different maintainers at some point in the future. How are you going to find them now?
I don’t disagree with their choice, but it’s not sustainable in the long term.
This is needed for more projects than just ladybird, and I'm sure will be worked out.
For now this makes sense.
> 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 rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.
It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.
> a pull request no longer tells us as much as it used to about the person submitting it
Nobody should need to know anything about any person submitting a pull request. Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.
Reviewing code fixes is strictly easier than coming up with them yourself.
This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.
As a project you can always ignore or close a PR you want to write yourself instead. But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.
Reviewing code in PRs is not a no-effort action. If there are 3 people working in the project, and thousands of people submitting bugfixes, then no matter how useful those bugfixes might be, the 3 people will be totally overwhelmed by the sheer number of PRs.
There might be value in your bugfix, but maybe that value is not greater than the cost of reviewing and accepting it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
This is completely false, for any sufficiently complex project. The fix might be a single line change, but the consequences might be far reaching.
> As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software?
Please don't! You don't owe the project anything. The other side of that equation is that the project also doesn't owe you anything. As simple as.
Firefox and Chromium are running much larger teams, let alone the Linux kernel, that other people suggested as a model. Maybe they can afford accepting your contributions.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
You can still tell them how you did it, just not in the form of code/patches. You should be able to describe it in prose so that the maintainer understands your solution approach.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
You're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
You can still submit a bug report and tell them exactly how you did it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
Unless it's hundreds or thousands of AI slop PRs each pretending "here's a bug I fixed it"
For every person wanting to do good in the world there are ten windup merchants of which at least one has darker motives
They could make two kinds of pull requests and add much more strict criteria for public contributions. For example, they could say that the PR has to be smaller in size and well-documented for human review, otherwise it's closed by an automation.
And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to get it in.
Blocking public contributions means that they want to have complete control of the project and AI is likely a good excuse to do that.
That doesn't solve the volume or quality problem. LLMs can split one giant PR into 50 smaller PRs just as easily and "well-documented" isn't something you can determine automatically.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
I don’t understand how you’re supposed to cultivate new maintainers if you shut down contribution.
Is this a sponsored project where maintainers are just hired?
You are also not cultivating any new contributors by just accepting slop the submitter did not write or understand.
I guess they will have to introduce some kind of trust-based system.
Wasn't the entire goal of Ladybird to have an open and independent browser engine? Making it effectively closed to contributions makes it.. Not independent anymore. It's now dependent, on few people who work on it, just like any other closed-source or corporate-controlled browser.
I don’t think that changes the project independence, when a project is open to PRs you have the same dependency on maintainers accepting changes into main. And the project is still open source. But that does make it less community oriented
But opensource has always been about community. This way it becomes "source-open", even if you could make changes to it and run those changes yourself, the latter doesn't sound "opensourcy" to me.
Exactly! It's not opensource anymore: it's fork-or-transparent source.
Accepting contribution has never been a requirement for open source.
We need stricter verifications / credentials behind GitHub accounts and PRs.
And this we should have had already before AI.
How does that help? People gladly post slop PRs under their real names.
It's not the only solution but it might reduce PRs by a decent amount I would think.
If you see a PR and the guy is verified, you can check his name, his linkedin and where he works, at least there is some accountability if he introduces malicious code.
If the goal is to reduce slop, define slop. As a maintainer of a project you should be able to tell if something is slop.
If you don't have time to read PRs (which is the real issue here) that's fine too.
My guess is they want to reduce the amount of PRs, and ensure that the quality of the PRs passes an extremely high bar.
Surely you can just autoclose any PRs from 1. People you don't know and 2. That are over 100 or even 50 lines?
That way new contributors are forced to start small.
I think it's not the issue with the added PR count, but the fact they have to review them. 1 big PR review is the same as 5 small PR reviews if you have to look at how it holds, edge cases and what not...
Well, then add some backpressure. Each contributor gets only a few small PRs a month, until they prove themselves. Contributors that don't have a credible online presence are automatically rejected. Etc
This project gets a lot of publicity for the product it has to show (which, as far as I know, is effectively still inexistent).
This is not really a valid criticism for an Open Source project. I built Ladybird from source yesterday and I am typing this comment in it now. So, I assure you that the Ladybird browser exists.
Of course, Ladybird is not production ready yet. Feature-wise, it is getting close. I can use it to do most of the things I want to do with a browser. Speed and reliability are another matter. I has gotten dramatically faster but normal users would still find it slow. But the biggest problem is reliability. I would not use it in its current form for anything that matters.
But for a complicated application that was started from scratch, not being ready yet is not an indictment. They claim it will be ready for regular users to try sometime this year and, from where I type, this seems realistic.
It's surprising to me how many people here seem offended that someone might just not want their code.
I guess it takes quite a lot of experience as a maintainer to realize that 'free' in 'free code contributions by strangers' is like 'free' in 'free puppy'.
What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway. Ladybird is not SQLite, it's under development and very likely will be forever. To me it looks like they are transitioning into a company, where this model makes sense.
Are they going to be using gerrit or a private repo and push changes back regularly?
Sometimes the discussions on PRs are equally valuable to see how a commit was arrived at, and I'd be sad if that got lost in this change.
A bit sad to see this. Of course they are free to do it the way they prefer, and there are successful projects like this (Notably SQLite) but there has to be a reasonable middle ground between "everyone can just flood us with 30,000-line 'Claude implement feature X make no mistakes' PRs" and "we're not open to outside contributions"
How would you decide what is the middle ground though? If a project allows some AI-generated PR if its good quality, then it is a burden on the reviewer on what is considered good or not.
I wonder how can a new browser engine survive with the source available model. Like, why would anyone support this, unless they have business association with the Ladybird developers?
It's not source available. It's OpenSource(TM) because of the BSD-2 license.
This is not unheard of. The most famous models are emacs & SQLite. SQLite doesn't accept outside patches, emacs is developed opaquely and only releases are put forward.
You can do this with GPL, too. You put out tarballs of the releases only.
There's a great misconception between Free Software, Open Source, and Open Development (bazaar model). They complement each other, but they are completely independent things.
Addenda: Looks like emacs' Git repo is publicly accessible now, but it's not a requirement for GPL or Free or Open Source software.
Zig is moving to this direction is well.
Indeed, while there is communication that the situation with merging external pull requests should improve, the reality is that it's easier to land a patch in Linux, than in Zig.
While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
> Now opensource will become a thing that only "influential" people can contribute to.
No. Having access to a slop generator doesn't entitle you to acceptance to any and all open source projects. You're still responsible for the quality of your contributions. Something that is completely lost on bullshit artists.
Don't put words in my ~mouth~ (keyboard) that I didn't ~say~ (type), I'm not saying I want my contributions to be accepted on equal footing even if they are generated by AI. What I'm saying is that solving this problem this way is going to make opensource much worse. We need a better way, and I'm not sure which is the better way, sorry.
> Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.
I don't know about you, but as for me, when I contribute to opensource it's because I find some improvement that makes the project better because it probably polishes some rough edge around a kind-of particular use case (that maybe few people face, but still, it makes the project better for them; it amplifies the range of usecases that it can span to). If everybody does the same with their small improvements, the project becomes better for everyone, but none of the contributors of these small changes would have time to embark on maintaining a fork. Mantaining a fork is hard work, not only because software breaks over time (dependencies going obsolete or insecure, builds stop working because of old toolkits), but also because not pulling the latest changes from master would mean that your fork gets stagnated (and thus not worth to run it).
I truly understand why this step was taken, but it is still sad to see the death of open source or rather open contribution. Every project that turns away from open contributions is a project lost to the whims and fuckery of AI Bros.
What I realy want to know how sustainable a model like this is. How does one find new maintainers when old ones leave. When you cannot contribute anymore.
Opensource doesn't mean open to contributions. The source code is available, you can fork it and apply your patches there.
This is the way to go to reduce supply chain vulnerabilities and to reduce time of mainters reviewing LLM slop.
> Opensource doesn't mean open to contributions.
That's not entirely true. It's certainly the case that Ladybird is still under an open-source license, but the whole idea of the "Open Source" label was to move the emphasis away from having a free license to actually being open to patches in practice.
I feel like the project just died.
> I feel like the project just died.
Why? This seems to be a strengthening move, not a weakening one.
Moving to a closed development model => opensource is just a gimmick, especially with a BSD licence.
> Moving to a closed development model => opensource is just a gimmick,
How so? Many projects are open source (GPL, MIT, whatever) while closed development, and no one calls those a gimmick.
In any case, most open-source is going to move towards a closed-development model; there simply isn't the resources to review thousands of lines of PRs per hour.
Maybe, or maybe not. But it will certainly kill the community they've built up, and squander a huge amount of goodwill. Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that's only source-available? Not to mention how the sponsors might feel about this.
> Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that's only source-available?
It's not source-available, it's open-source.
Too early to say. Once they enter "we now accept everyone to use Ladybird as daily driver" then there will be the real test phase. And, IMO, only after that phase has started and continued for some months, perhaps even few years, can a final conclusion be made. If ladybird fails then the Google empire has won permanently. Skynet slop will then be under control of Google, just as they stole all the advertisement money.
"Gain trust through plausible contributions" is a new angle on AI-produced PRs I haven't seen yet.
Though in retrospect we should have seen it. It's been an angle of attack since forever, it only took a lot of effort.
This is one way to rephrase "we don't want your AI slop, thanks.".
> 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.
It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project.
It's still open source, but not open for public contributions. That's pretty much how it was before the advent of these forges.
I think I didn't put the emphasis right in my comment above. The code is still fully open source, but the project that produces the code isn't. It's not dissimilar to other projects producing open source software.
This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.
AI contributions are only a part of the issue. Another part is where a contributor decides they want a specific feature and contributes it but then disappears off into the sunset when it comes to needing maintenance later.
Legit
I think we are going to see a lot opensource project switching to Humans Need Not Apply Mode.
LLMs are killing open source just like they're killing online discussion forums.
It's heartbreaking, my two favorite things about the internet are dying off because human interaction can't outscale AI slop.
"A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it."
Then the linux kernel is doomed. /s
Cool - how about fewer perma-bans on github for participating in discussions?
Also, as I have pointed out before, they seem to develop too slowly for a solid beta this year. You only have to look at the issue tracker and check for URLs not working or even crashing the browser. Ladybird may have gotten better in the last months, but imagine if 50.000 people are using it, you will see more bugs. How do they then handle bug reports?
Can we see some discussions that got people perma-banned?