Changing how we develop Ladybird

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.

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.

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.

Why is it surprising that some people who expect results without spending any effort also feel entitled to receiving gratitude without putting in any thought?

There tend to be a lot of drive-by AI PRs attempt to “re-add” the feature, often not quite addressing the situation comprehensively. It seems like a bit of a local minima trap for the bots. [3]

[1] https://app.opire.dev/issues/01J8YJ06HPSY7ZAMAW08T83YBD

[2] https://godotengine.org/article/live-from-godotcon-boston-we...

[3] https://github.com/godotengine/godot/pull/119972

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.

https://youtu.be/LDSwP37y_W4?si=fMIsdQ2yjoiGChb6

I don't think that follows. They expect things to improve, they do something about it and might (unreasonably) be frustrated by what they think is a policy that stands in the way of quicker progress. The first part is certain, the second part less so, and the third is just speculation.

It's clear that open source project are struggling to understand what is going on and coming up with plans – like everyone else – but clearly there are better and worse ways to proceed in this new world, if popularity, adoption and progress are things you want to focus on.

I dunno. If that lump of code makes the program do things it wasn't doing before, I'd say there's a lot of value in it. We can definitely scrutinize the code's quality but there's no way anyone can argue with working code that makes the program better or more featureful than it was before.

If a feature and ignored, it can forked to provide more value to the users.

If unaccepted bugfixes, the maintainers are just silly. They need to be forked off.

We still need some mechanism for determining which humans have enough long-term commitment to become maintainers. Source contributions are no longer a reliable signal for that, and I don't know what future signal we'll use going forward. That's going to be a hard problem.

But, who knows, if AI really does make programmers radically more productive, maybe successful open source projects don't need a large maintainer team.

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.

(Also, as a sibling comment implied, the archetypal "bazaars", like the Linux kernel project, now appear quite cathedral-like in conparison to the free-for-all GitHub model!)

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.

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

How about this. Somebody forks the project and submits their patches to the fork . If the fork is successful (there are users actively using it), upstream can selectively go fish for the patches themselves. The maintainer of the fork eventually gets recognized.

Not ideal, I know, but building a reputation is meant to take time.

I suspect if you exclude by default but have a manual process for requesting access and permissive standards for granting access, you can eliminate most of the bullshit without really excluding anyone.

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.

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.

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?

You're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.

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 can do all that, and make a bug report with a fix.

What happens next is up to the maintainers. If they reimplement from everything you gave them, and sculpted the fix into its final shape, that’s a great outcome for everyone.

Yes, and this has always been the case - see also: XY problem

> Reviewing code fixes is strictly easier than coming up with them yourself.

This wasn't even the case before the slopocalypse.

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"

I do not think we should be eternally grateful for monopoly building.

Chromium? You mean the browser engine controlled by the Be-Evil corporation Google, which recently killed support for a huge swatch of important extensions (manifest-v2)? And thus prevents much of adblocking?

Gecko... now that's something less people are aware of, but let's just say if you know how the Mozilla ecosystem is governed internally, I believe you would be rather aghast.

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 this position a bit: the notion that AI-generated code has no value. I think it's easy to generate zero-value code, but I don't agree that all AI-generated code is zero-value. I've been working on my side projects in OpenCode, and I spend quite a bit of time prompting, setting up the right files, descriptions of the product I'm trying to build, and the roadmap for it. I have a tight validation loop that lets me run through a bunch of automated checks after each change, and then I do a bunch of manual testing through edge cases that the generated feature might screw up, and then I iterate. It's a different kind of work, but I can make progress more quickly than I could coding by hand. Validation loops are the main critical component.

My experience doing this over the past months is that using AI to code is a skill, and I learn new techniques and get better at it as I try stuff. But that also suggests that, when done well, it can produce something of value.

All of this is to say: while I take issue with your first sentence, I completely agree with your second sentence. What we've lost is the ability to distinguish easily between something well-thought out and something generated thoughtlessly. Focusing on cheap validation would help here immensely, as well.

I see all projects moving this direction. Makes more sense to hash out a plan together.

I'm 100% on the side of maintainers here, but this is BS. If you could "just prompt Claude yourself" the AI productivity boosts would be in hundreds if not thousands of percent, which is demonstrably and self-evidently not the case (at least as of June 2026).

Initially I thought AI would be great for FOSS because suddenly open source projects could get up to speed with paid options. UIs could get better (albeit boring/soulless) with Claude Design, etc.

But then I guess someone has to pay for all of those tokens. It's "easier" to devote your time but much harder to justify spending $300/mo on contributions to open source.

So maybe some people see this almost as a donation? Hey, I paid for tokens and generated a PR - be grateful for my donation!

And then they completely disregard the fact that reviewing the generated slop becomes way too much for the contributors. They would probably have appreciated a monetary donation more.

It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly.

Quoting obama, "reality has a way of catching up with you".

I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no one does, if anything people are complaining that existing functionality is breaking down. So it can't be true that we're at 10x productivity, and this fact will eventually catch up with us.

Let's be human, and remember that many people are emotionally invested. Juniors want this to be a chance to shine in a market that otherwise rejected them. CEOs placed their bet on AI and don't want to walk that back. Seniors want to signal that they are not obsolete. AI companies will poison discourse. But all this smoke will eventually clear.

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.

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.

As in cheer for the humans because they've been liberated from the drudgery they have lost?

The future is a bit fuzzy, always. That said, here's my take on it.

> Transition to f-ing what though?

Not jobs. Those will be gone once ai can do them cheaper than humans. ai can already do many (most?) of them better than humans. The jury is still out on the cost aspect. Judging by r/LocalLlama, the lower cost is not that far off. There may be some structural adjustments around compute pricing before that happens, though.

In the EU, humans will probably be ok. They have a strong tradition of focus on human needs. Because of lower average salaries [1] than the US [2], human employment will likely carry on longer as well.

In the US, those folks that have capital will likely be ok. They'll be able to purchase services from ai companies and invest in ai companies and corporate armed forces (ai-populated, not human) to protect the Haves. Those that don't have capital? Who knows? America hates poor people, women and minorities.

China? No idea. Though I hear that their demographics are upside-down, so there'll be fewer people to support over the long-term. That they'll supply the robotics and goods for the rest of the world is not in doubt: cheaper electricity from solar/wind, advanced ai and robotic tech, science and industry moving forward while the US regresses, hard.

India? Hard to say. No social net of any consequence. Not enough capital to go full ai/robotics, human labor way cheaper than ai/robotic labor at the moment, so maybe they'll survive as that last major bastion of human work for some time to come. But their economy is growing, and they have a lot of people, so at some point they'll come to that same fork in the road. Hopefully they'll have serious social safety nets by that time.

Africa? In a lot of ways, they're similar to India on the human labor costs side, so their future hasn't been written yet either. India can probably fend off an invasion by rapacious US corporates with ai/robotic armies looking for resources because of sheer numbers, but Africa, fragmented, is a different story. Maybe China will be their friend? If you think this scenario is outlandish, look into the history of European companies colonizing the world. You didn't think the East India Company with its massive private armies were government-owned, did you? Likewise with the Spanish/Dutch/Portugese expansions. The govt. takeovers didn't happen until much later, tens of decades later.

South America? They're an interesting case. Brazil may take a trajectory similar to the EU. Chile, Ecuador, Uruguay too. The others are a ?

[1] https://en.wikipedia.org/wiki/Economy_of_the_European_Union [2] https://en.wikipedia.org/wiki/Economy_of_the_United_States

This is asinine. Keep depriving yourself of things you enjoy I guess?

how was open source managed before GitHub ? you had to find a mailing list, be involved in the mailing list - ask questions, make a proposal, then create code after -- code goes through x rounds in the mailing list. finally it is merged if it suits direction of the project.

this willy nilly of opening pr's while not being an active member of a community I would say decimated open source.

Maybe, just maybe, you're not thinking rationally/logically about the situation and instead are mostly operating on emotion and feelings?

> 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.

[1] https://github.com/awesomekling

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.

I don’t disagree with their choice, but it’s not sustainable in the long term.

As a Servo maintainer, I'd like to remind people that @ServoDev continues to welcome contributions from everyone. We actively mentor newcomers, help people learn Rust and browser engine development, and review community PRs.

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.

Does it? Seems the only sane option. The other being being drowned in AI slop PRs.

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.

Any rando armed with an LLM is not a community.

Not just the changes, you'd push the responsibility, too, for supporting a whole new compilation target. I don't know how big this is, but if it's a big enough hassle to keep maintaining this yourself, then consider that this maintenance work is really what you were hoping to push. So, depeding on which, you might be fine maintaining this, or the maintainers might have rejected the change, anyway.

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.

Ladybird’s blog post is arguing that it used to be tolerable to spend the amount of time evaluating this for every PR, now it’s just unmaintainable for their effort-time.

EGCS was created because Cygnus, a company whose business was based on GCC, wasn't getting their patches to GCC, maintained by non-company FSF.

Cygnus outcompeted FSF by so much that FSF folded and made EGCS maintainers new maintainers of GCC.

I just don't see average open source project being forked and improved by so much that it eliminates the original.

This requires 3 rare things to happen:

- the project is important enough

- the project is half-dead

- someone is willing to out-compete the original project

That won't happen to e.g. Laydbird. Yes, it's important but it's making rapid progress and they also use ai, so you can't outcompete them just using ai. It's a full-time project for at least one person (Andreas Kling) so unless you manage to find a band of great, unemployed programmers I don't see how you would compete.

Just to make a point: I could throw out SQLite as a project that bans open contributions and is wildly successful.

Also, as others pointed out, Linux is technically open contribution bazaar style by 2000s standards. But if you look at how to actually get involved, there’s way more friction compared to the average GitHub project.

I actually think GCC falls into the same category. Even though it’s technically open contribution these days, it’s not exactly a free for all where any AI agent can open a GitHub pull request and get it reviewed.

You have to mail patches to a mailing list and follow a bunch of super specific and arcane rules set by the grey beards.

They probably could do that as part of the hiring process.

    1. Free Redistribution
    2. Source Code
    3. Derived Works
    4. Integrity of The Author’s Source Code
    5. No Discrimination Against Persons or Groups
    6. No Discrimination Against Fields of Endeavor
    7. Distribution of License
    8. License Must Not Be Specific to a Product
    9. License Must Not Restrict Other Software
    10. License Must Be Technology-Neutral

Not at all. You are of today’s lucky 10,000 [0]. Open source refers to OSI-compliant licenses, not open to contributions. SQLite is open source but not open to contributions.

[0] https://xkcd.com/1053/

This is just the cathedral model to open source, as opposed to the bazaar you clearly prefer, but it's still open source.

Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?

I guess they will have to introduce some kind of trust-based system.

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.

The policy makes sense to me given the security concerns for the project.

I do think closing off contributions is a big step and would rather most projects find a middle ground, but it's definitely understandable why they did this.

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.

If we were at all competent we would have focused on the issues you mentioned. Architecture, intent, definitions, validation, actual proof that our work does what it needs to do. We didn't care because we were too busy showing ourselves and the people we look down on - the "suits" and other programmers using different styles/languages/frameworks - how superior we are and how clever we are that we can internalize and navigate Rust's syntax and C++'s foot-guns.

Unfortunately, or perhaps fortunately depending on your perspective, I think that strategy is dying. It might be best for us to keep the eyes on the ball. What does the system need to do and how do we validate that it in fact does what it says on the tin? All the rest is noise and that includes "code". If a million monkeys on typewriters get the job done within acceptable parameters so be it.

Newspapers are adopting it too, so soon we may see slop dominate even high brow publications.

Feels like a huge shift in human intellectual capabilities. Honestly quite worrying, I don’t think it’s a Luddite position to say that removing writing is removing thinking.

Why? This seems to be a strengthening move, not a weakening one.

For an open source project that isn't a business, that's really the only way to recruit people

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.

> 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.

The point of OSS though isn’t that nobody gets paid. It’s that if they charge for contributions, they get paid to release their work as Open Source software. They get paid for the labor of producing the artifact, and not necessarily paid a royalty for future sales of the copies.

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.

I wonder if any of you AI boosters have any actual knowledge of how software is written, why bugs exist and how to mitigate tech debt. I wonder if you guys even know what tech debt is.

Somehow it’s always very young accounts which made me wonder if I’m talking to exuberant teenagers or people that have done a one week Python code camp 10 years ago and now think they’re John Carmack with their Claude subscription.

Ladybird uses AI to code. This is not them banning AI. This is them not wanting to take responsibility for the code WE write with AI. They think outside code contributions are raising their risk and slowing them down.

I dislike this change but it does not track to what you are saying at all.

Like always with Open Source, if you really believe what you are saying, fork the project. Outrun them if you can.

why would you want this. this sounds terrible

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.

To that mind, why hasn’t chrome itself become 1000x better?

There is a disconnect between the narrative and reality.

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.

We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers."

Seems like a good bottom-line-up-front to me.

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.

Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.

Comments in this thread that insist open source has nothing to do with community, that it's simply a licensing matter, is disappointing and shows a lack of understanding of what's it's all about. Similarly with the community of mathematicians. Some people reduce it to "Math is just a tool", which is just ignorant and sadly misses the beauty, wisdom, camaraderie, and the humanity of the endeavor which is what matters.

When I first read this I checked the license and saw that a rugpull would be permitted. However, if someone wants to continue the project after the rugpull they could do something thing like the redis rename to redict.[0]

[0] https://andrewkelley.me/post/redis-renamed-to-redict.html

(Seems I ran out of edit time!)