Now I see communities being affected. When you kill PRs, you not only kill the code contributions, but also massively impact the other, non-tangible contributions like ideas, eyes on code, etc. That feels way worse.
I'm conflicted, confused and afraid, HN. Look at what I just wrote, yet I use claude and deepseek and all the skills and complex harnesses and MCPs and whatnot... But all now seems like a transition phase. Transition to f-ing what though?
A lot of questions cannot be answered unless we dedicate a meaning to our lives. Human touch? Too late? Also: I liked a song and it was sonos. I unliked it after discovering. I feel so stupid, so often.
Sorry for the unhinged digression.
I love Ladybird (have a sticker on my laptop to prove!), I hope they thrive.
These "contributions", while they did exist in small quantities, mostly were not actually what you've described there.
Instead, those boiled down to unsolicited opinions, hostile takeover attempts, value extraction, general drama and just overall overhead over simply building code.
This was not always the case, but the GitHub model of building FOSS (and removal of all friction) certainly made it the new default.
Said model was always unsustainable, but the burn rate made it sustainable enough so that we could just throw more humans at the problem to replace the burnt-out ones.
AI pushed the burn rate over the replacement rate.
=> We will likely see more projects adapt this or a similar stance I think.
What do you mean you just spent a week implementing something in secret?
AI just makes it extra silly because now you can craft up your unsolicited code change in minutes, making it extra obvious that code changes should spawn from real discussion and agreement.
TFA is just part of looking for new processes that actually work. Dunno why people are having such rose tinted glasses about pull requests. Open an issue, talk to people. Have an idea? Then get people to cosign it.
Now they can drop a multi thousand line poorly understood PR day 1.
I don't really have anything useful to add here, I think, just that you aren't alone in feeling conflicting feelings here. New things usually are like that, comes with incredible benefits in some areas yet seem to strip humanity away from others, some people use it to produce fluff and crap, others essentially gain new abilities and use those to build even better stuff. I don't think there is any universal truths here, sadly.
Maybe your legislative feels bought out, that sucks, but that's not the situation nor the feeling everywhere in the world, certainly not where I live, so also doesn't seem to be related although if I assume where you live, I totally understand why you're currently feeling like that.
Do you expect your government to navigate whatever transition might await us in a manner that works out well for the vast majority of your countrymen? What about the governments of other major world powers? Even if your local government does all the right things, will the world as a whole end up in a good place?
That said, I'm not sure that there's much in the way of actionable options, at least not with clearly defined outcomes.
No, but I expect them to do the best they can, with the information they have available, as always, as they just like me, are just humans. Trusting the legislative branch of my government is different from "so you think it'll work out well for everyone then huh?", btw.
> What about the governments of other major world powers?
Why does it matter how much I trust the legislative branch from other countries? They do as they wish, we continue to do as we wish.
> Even if your local government does all the right things, will the world as a whole end up in a good place?
My experience and opinion is that generally the world is getting better almost every day, vast difference even compared to ten years ago, how much better the world is today, for most people. There are some few countries which lately been going in the wrong direction, but for the most part, we (humanity) are getting incrementally better.
I'm also conflicted but take a glass half full approach basing myself on the fact that when I'm feeling like "this time is different" it's probably my ego wanting my lifetime to happen at an interesting time in history, so my brain wants the current events to be the most transformative.
No. Electricity didn't raise the skill floor all that much. Certainly nowhere near the human skill ceiling.
> the internet would kill all street level businesses
That was never going to happen overnight, if at all. But online retail (and food delivery, etc) does seem to be slowly but surely eating away at local shops so it definitely seems as though it's within the realm of possibility.
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.
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. People see this as mostly a matter of time and energy, but I reckon it will soon be a financial issue.
I think we'll need to revert to artificial barriers such as bonds, e.g., if you want to do a PR to my repository you need to pay a 10 dollar bond. If the PR is good and I want future PRs, you keep your bond. If it's slop and spam, I get 10 dollars for my time.
The previous barriers worked because they were organically perfectly in line with a contributor's internal incentives. A contributor gains very little benefit from submitting a patch; the likelihood is infinitesimally small they'll ever get any career advancement, financial recompense, or even much community recognition for it. At most, it shifts the burden of maintaining the code they're contributing from themselves to the community / long-term maintainers. The real incentive for a contributor was making the patch, because they get to see the feature or fix they want made for the software. The previous barriers were in making the patch, and contributors would overcome that friction to gain the benefit of having the patch they want. Moving the barrier to merely submitting the patch after it has already been made will simply result in people not bothering, because there is very little incentivizing them to deal with the friction.
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.
- Receive a huge vibecoded PR for complicated new feature.
- Complain that this needs some design doc to figure out the right approach first.
- Author says no need for design doc, easier to have vibed implementation and discuss the concrete code instead of abstract document.
- I disagree (obviously), but review the PR with feedback along the lines: this entire approach is flawed, throw this out and start over.
- Author gets defensive, says "but this is already working and ready, let's just merge".
- I tell them there is no chance in hell this is getting merged. They go sulk to their manager that I'm not interested in helping them launch.
The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.
It's 100% an issue with the people with submitting these PRs. So, if someone has a history of having no issue with breaking project rules (let alone being arrogant about it), it should be a massive red flag about the person for any possible employer or future collaborator checking their profile, etc.
Why people are wilfully destroying their own reputation like that is beyond me. It's infinitely better to have no activity at all on your profile than to create a track record of bad behaviour.
I would be more sympathetic if they actually spent meaningful time on these contributions and could maybe see an argument for wanting their work to be given due consideration (lots of caveats here), but from what I’ve seen that’s the exception rather than the rule with a lot of these case.
> 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.
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.
Before the rise of github, open source projects were heavily walled gardens. Little clubs that gave you a stare when you entered the room. Github commoditized getting in touch and lowered the barrier for how much effort you have to put in or even how much you have to care before you contribute. This is gone now and you have to build trust now before you can contribute to anything.
This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.
So I do not see a problem with Ladybirds decision, in contrary, IMHO it strengthens the human aspect of software development and puts the brakes on AI free riders
If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view.
Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source project. The path is now closed, and I don't see a way in, outside of creating a popular open source yourself
Returning to the topic at hand, the challenge for new developers is to earn trust. I bet there are ways to do so aside from the muddy swamp of GitHub's (AI) bazaar.
I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.
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.
"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds."
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
We'll have more such disruptions and we'll learn to live with it.
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).
Yes, this is the takeaway for me. A PR can no longer be a reasonable proof of work.
"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.
I see all projects moving this direction. Makes more sense to hash out a plan together.
That is exactly the issue. Projects that are end-user applications - as opposed to libraries or development tools - probably see far more slop than actual work like you've described. The yields are too low for it to make any sense to try to figure out which is which, their time is better spent doing the work.
> 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.
a code owner may choose a very different way of fixing things, even for what looks like a trivial fix.
You state these things as if they are facts, but they are completely contrary to the lived experience of open source maintainers - not only my own and the TFA's but quite a large number of others who have shared similar pieces.
Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years that forms the basis of your expertise on this matter?
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.
Exactly. You want others to change to fulfill your needs. Their priorities and needs are different. In this case, it was evaluated and found not to be useful (cost > benefits).
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"
(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 do not think we should be eternally grateful for monopoly building.
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.
Integrating some kind of proof-of-stake system might be the way forward for open source. Nobody wants to shuffle through a pile of low-quality PRs written by LLM.
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.
On the other hand, Ladybird is gearing up to become a production-ready browser for real users. Adding fun features for the sake of it, and hand-rolling code to parse PNGs and the like, has become a liability for the project.
The elephant in the room is so many projects already operate like this without formally announcing it.
If you look at Blender, one of the biggest and most successful OSS projects out there, it's effectively run as source available. Some PRs make it through, but for the most part there have been heavy barriers to entry to get your work into the product. In this example, it's been key to such a large and complex project with millions of users staying afloat. It's an inconvenient truth.
It's one of those unspoken things in open source - the bigger the project the less you can accept or vet contributions. The less able you are to respond to users because there are too many. The amount of code you need to own balloons. The signal to noise to too much. LLMs have massively exacerbated this issue.
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?
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.
Maybe not?
I just got the impression that there are a _lot_ of obscure drivers that have to be carried, and are eventually removed causing annoyance. An ABI for the people who cared about that random driver might localise the maintenance burden.
I don’t disagree with their choice, but it’s not sustainable in the long term.
For now this makes sense.
Feature requests are valuable because they tell you what users want.
Error reports are valuable because they tell you under which circumstances the code fails.
But the code that implements those features and fixes those errors can now be written by AI. AI follows all the rules for how code is supposed to be written in your project. Is already producing very high quality code. And soon it will produce a quality that no human can match.
For an open source project that isn't a business, that's really the only way to recruit people
Couldn't an agent monitor feature requests and bug reports, reason about them, and then implement and fix the ones it deems important?
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.
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.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
Unfortunately AI tools are breaking the open community dynamics, it has become more and more expensive to run open community oriented projects due to the noise, it’s really a shame. It’s a lot to expect volunteer project members to triage the increasing amount of AI garbage
And submitting a PR is almost wholly dissimilar from a conversation between friends over dinner or drinks. If you want to have a community around an open source project, it always has taken more than just accepting patches.
Also they are not changing the licence or preventing forks.
It is a pragmatic solution to a real problem that can really clog down progress on the project. I hope they (and other open source projects) will figure out how to filter in good, responsible contributors but I guess it will take time.
Is this a sponsored project where maintainers are just hired?
I guess they will have to introduce some kind of trust-based system.
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 is probably the best, most succinct explanation of what we're seeing happening in the OS world right now.
We usually call open source software without open collaboration source available software.
This is terrible news, defeating core beliefs people had in Ladybird. Not an open browser I wished for.
This is just the cathedral model to open source, as opposed to the bazaar you clearly prefer, but it's still open source.
Of course, if they are also concerned about the quality of external PRs then that does not help.
That way new contributors are forced to start small.
They may, at this point, go ahead and remove "get involved" block from their website https://ladybird.org/, since it's not possible to contribute anymore.
> Source-available software is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open-source.
https://en.wikipedia.org/wiki/Source-available_software
> Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose. Open-source software may be developed in a collaborative, public manner.
https://en.wikipedia.org/wiki/Open-source_software
And as said here, SQLite was operating like this forever.
I'm surprised this isn't yet a thing. Heck, this can be made independent of GitHub/Gitlab, like a portal which tracks your rep. Could also help you got hired. Think Stackoverflow rep mixed with LinkedIn but for actual code contribution.
Yes I'm aware it sounds Black Mirror-ish. But we need more meritocracy in the world of OS that is otherwise highly anonymous and with very little public authority.
How is this the top post on my favorite website?
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.
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.
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.
https://ladybird.org/#contribute
I hate this change and agree with your PR comment. This change makes me sad as well.
My hope is that public contributions can resume in the future. Part of their justification for this step is that they are trying to stabalize the project to produce a stable public alpha. Fair enough. And many Open Source projects have begun to voice concerns over the burden that the massive increase in contributions is causing, often from AI. Linus Torvalds has certainly been flagging this. The Open Source world in general is going to have to navigate this and come to a solution that works without the entire Open Source ecosystem becoming read only.
Once Ladybird ships a "stable" browser out to the world, I am hoping they can adopt whatever the "best practice" for Open Source has become to be able to accept public participation again.
Applies so, so widely. Glad they’re taking (very necessary) action here.
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.
It's not an impossible problem, but it's a resource allocation problem, and they don't seem to have a way to address it at the moment besides closing all PRs.
Though in retrospect we should have seen it. It's been an angle of attack since forever, it only took a lot of effort.
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.
Maybe also limit the size/scope of external contributions (only small bug fixes allowed for your first few PRs)
Why? This seems to be a strengthening move, not a weakening one.
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.
It's not source-available, it's open-source.
It's heartbreaking, my two favorite things about the internet are dying off because human interaction can't outscale AI slop.
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.
Webkit absolutely takes third party submissions. https://webkit.org/contributing-code/ .
I believe this is an external PR merged a few hours ago at the time of this writing. https://github.com/WebKit/WebKit/pull/66507
Safari does not accept third party submissions, but the chrome has never been open (even before Google Chrome recycled the term).
The open source definition was created in that mind. It does not state or imply open development or a community are requirements.
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.
I think your thought was cut off. What is the project no longer?
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.
Why people keep saying that I'm advocating for AI use? I'm not happy with the decision of Ladybird maintainers, but that doesn't mean I'm willing to spam them with AI slop.
LLMs in general change the balance of how much effort generating content takes, sometimes by orders of magnitude. They unfortunately do not significantly change how much effort it takes to understand and evaluate the quality of that content. The result is that the base value of a piece of content (including code) is plummeting.
And it has nothing to do with the perceived "only influential people can do it". You're always welcome to fork any and all projects and run your AI on those
I already replied to the forking thing here: https://news.ycombinator.com/item?id=48410121
That assumes everyone does that. Instead, with LLMs everyone just does "do a thing, no mistakes".
And when that backfires, uses LLMs to start an automated bullying and smearing campaign: https://cybernews.com/security/openclaw-bot-attacks-develope...
Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.
> For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.
The solution, IMO, is a strictly worse version than what we chose in the Zig project (banning LLM contributions).
> AI tools have changed the economics of this very quickly. We use them ourselves every day, but 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.
Things that worry me about this choice:
- open source is a tough business and you need to leverage the good things about it to make it worth doing. contributors bring in a huge amount of value that they offer you essentially for free (see contributor poker: https://kristoff.it/blog/contributor-poker-and-ai/), on top of being a hugely valuable recruitment funnel. They're rejecting all of that, which seems insane to me.
- one could argue that LLMs could fill that gap but, first of all they could have just banned LLM usage only in PRs from untrusted contributors, and second even the best LLM: 1. is a cost, not just free value, and the price of tokens is increasing 2. the code has to be reviewed anyway, unless you think that just passing tests is good enough for a browser 3. ultimately can't become a trusted core contributor able of taking ownership of a part of the codebase
- removing the influx of code that comes from PRs means that over time the whole project will have a small number of contributors that own all the code, making it easier for the project to do a license rugpull. when copyright ownership is well distributed this kind of thing is harder to pull off.
Overall, this is not good in my opinion. They're making open source a more problematic business model for them than it has to be, while at the same time making it harder to recruit more core contributors, as the code ownership coalesces to small group of people.
This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors is playing a mean game of Secret Hitler. I guess only time will tell.
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?
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.
To my eye, this change does not appear to be driven by a change in corporate governance or profit motive.
They explain that the change and the timing is driven by two things.
1 - The burden and of processing public contributions has increased with the rise of AI
2 - They need to focus and stabliize the code base in preparation to introduce a public alpha
Those reasons ring true enough for me that I do not need to go looking for other motivations. I do not like this change but I can see why they would.