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.
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.
I look forward to the book: The Cathedral, The Bazaar and The Junkyard.
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.
An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
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...
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
(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.)
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).
I see all projects moving this direction. Makes more sense to hash out a plan together.
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.
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.
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.
Is this the direct result of a monolithic kernel? And would moving more drivers out-of-tree mitigate this?
I don’t disagree with their choice, but it’s not sustainable in the long term.
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.
Is this a sponsored project where maintainers are just hired?
> 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.
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're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.
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"
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 way new contributors are forced to start small.
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.
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'.
And this we should have had already before AI.
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.
Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.
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.
This is the way to go to reduce supply chain vulnerabilities and to reduce time of mainters reviewing LLM slop.
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.
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.
Though in retrospect we should have seen it. It's been an angle of attack since forever, it only took a lot of effort.
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.
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.
Why? This seems to be a strengthening move, not a weakening one.
It's heartbreaking, my two favorite things about the internet are dying off because human interaction can't outscale AI slop.
Then the linux kernel is doomed. /s
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?
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.
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.