Changing how we develop Ladybird
ladybird.org
ladybird.org
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.
1) more reliance on systems to track reputation across projects. I'm sure Microsoft, in the form of GitHub, will love to sell you a partial fix to the same problems it so enthusiastically helped to create. But there are the familiar problems of surveillance, identity theft, office politics, and system-gaming, and it doesn't on its own offer an onramp for new players.
2) in-person coding tests at the same Pearson test centres where people take most of their Cisco (and accounting, and ...) exams today. Not as expensive or inconvenient as you might think, but not the cheapest and easiest, and it certainly has the same concerns re. surveillance and identity theft
It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't have the actual engineering background required to do the work.
If I had to push this take to the extreme: software engineers never learned class solidarity and it's now biting the industry in the ass.
I can go on YouTube and get step-by-step instructions on how to safely wire an entire house. In many jurisdictions I would even be allowed to do that.
I can get instructions on how to completely redo a bathroom, down to the studs and up through the waterproofing and tiling. I can get instructions on how to do foundation repair, which might be a bit much for me but can help me ask the right questions to keep the contractor I hired honest.
These are all examples of experts acting as “traitors” to their particular group. In reality, technology enables both specialization and despecialization. Some people try to cling to their specializations and cry “class warfare” when threatened.
Who claimed that?
That was the context:
"Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, "
> I’m pointing out what I believe to be ridiculous gatekeeping.
I am not gatekeeping. I am stating that we collectively exist in a professional caste and that will go away or lose influence if you let it do so. Other professional castes do this exact same brain exercise and that is why they have protections in place.
> Some people try to cling to their specializations and cry “class warfare” when threatened.
I'll be blunt and just state that I am post money and not remotely threatened by this stuff anymore. I am observing that software engineering as a profession is blindly giving away a ridiculous amount of leverage in the world - in the form of dollars and influence, the value of their labor - and more crucially doing it to themselves.
I will be fine whichever way this shakes out, and I don't really have a dog in this fight short of having spent decent time in the OSS space and finding it sad what it is turning in to.
I consider this mode of thinking selfish and anti-progress. It’s pretty much exactly what Americans decry about unions.
If you consider a union to be a "bad thing" then we are likely going to talk past each other for eternity.
I am fortunate that software has paid me well to work on problems I am enthusiastic about solving. I understand that a lot of people on e.g. the Ford assembly line are not there because they want to make excellent cars, they’re there because they need a job. I acknowledge that I have no idea what it’s like to structure one’s life and priorities this way; it is just completely alien to me to align oneself with the task rather than the mission. And I believe that task-identification mindset is why we hear about resistance to electrification because EVs require fewer assembly steps, or Teamsters cutting power cables at trade shows if the vendor dares to plug in a TV themselves.
Software developers should not ossify. Nowhere have I said that LLMs as a tool - used by those in this profession! - should be shunned. I was pointing out that people being totally okay with those outside our profession, those without the necessary skillsets, directly doing our work not only devalues our work.
It's not meant to be taken negatively, and is purely a term that I was choosing to represent "hey, you all need to consider better coordinating/representing/holding the line as a group".
What is sad about oss? What is it turning into? I will say far before ai came in oss was a few arms deep in the techfluqncer culture where motivations were driven by gh stars and follow counts rather than a genuine interest. Or maybe what was a genuine interest became twisted as the culture changed.
I do care, it's why I commented what I commented. ;P
I already acknowledged that "caste" is an incorrect word choice and I could've done better there, but my core point remains unchanged.
Considering the reactions, it was a very amusing "mistake" to make (a bikeshedding lightning rod so to speak).
Though I guess "caste" is a bit more sensitive in some cultures, which might explain why some commentators hyperfixate on that part of your comment.
Sure, and I'd be comfortable doing that with my house. I wouldn't be comfortable with some random person off the street coming up and saying to me, "hey, I watched a bunch of YouTube videos about wiring; you should invite me in to rewire your house".
That is the proper analogy here.
Fun conversation with a high end coder: ME: I would write it from scratch rather than introduce a dependency. It's not that I don't trust people but I just don't trust people to live up to the specific standards for the specific job. HIM: For what I cost no way I could justify that. ME: It looks like a circus this thing of yours. HIM: Keep the secret!
I've often thought that it would make sense to have a DIY electrician's certificate, proving that you know how to do basic home wiring, such as outlets, switches, ceiling lamps, basic solar (DC and AC), installing new wire, load calculations, and connecting to breakers in a service panel
I have no problems pulling a permit and going through an electrical inspection.
That said, I've seen plenty of work from experienced certified electricians that was complete garbage. Not just a few things, more than half their work.
Things like, they cut half way though the wire removing insulation. When you pull the socket out of the wall the wire breaks. So you have to strip it again but they also cut it to short so you have to pull a new wire into the tube. Then you discover the tube is a bunch of segments behind the wall or it has multiple sharp 90 degree corners and the wire wont move or the new wire wont go in. Then you have to open up the walls, new plaster, new paint, do you want one wall with wall paper that doesn't match or will you go for new wall paper for the entire house/floor? All because they did multiple terrible things.
I'm not an electrician, just a DIY enthusiast (and the parent commenter) - but in North American construction, romex in conduit is basically unheard of in residential builds - it's stapled to the framing during construction, so once you cut wire short, you've immediately put yourself in a pickle.
I wish professional electricians use pigtails and wago lever nuts instead of wire nuts. Working an old house, I've had to cut way too many wires almost too short just to add another neutral or ground.
Ideally you bend the pipe as little as possible and make the corners as smooth or as blunt as possible. If done properly you can later add extra wires. If not done properly you only get the illusion you can.
With romex you have to anticipate future changes.
Well, that's already the case because you cant just call yourself an engineer and start signing off on projects. It's a legally protected title in a lot of places. You need a professional license, and can face legal liability for your decisions.
Software engineering is not engineering. Software craftmanship or even architecture would be a more accurate term. There are no devs that will go to prison if what they produce has, say, a major vulnerability. That alone disqualifies it from being engineering. There's no licensure, there's no liability, so already software development is not gatekept in any way like other engineering disciplines.
I mean, just go into an aerospace engineering office and say you want to move fast and break things, you'll get laughed out of the room.
No idea what you mean by class solidarity. There are only two; the capital owning class, and then everyone else (the working class). Most devs are working class just like everyone else.
Unless you're proposing that software should be gatekept to the level of other engineering disciplines?
This was part of the implication of my point, yes.
> No idea what you mean by class solidarity. There are only two; the capital owning class, and then everyone else (the working class). Most devs are working class just like everyone else.
Yes, albeit a highly compensated portion of the working class. Software engineers should protect their own field a bit more.
> Unless you're proposing that software should be gatekept to the level of other engineering disciplines?
I do not like or want to use the term "gatekeeping" here, but yes, I think that software engineering should be held to a higher standard. You can't have it both ways.
The only problem in your theory is that none of those things has anything to do with "engineering".
You're arguing that a surgeon who removes a burst appendix in a hygienic environment isn't "practicing medicine" if they aren't licensed to do that in the jurisdiction where it happens. You'd have to be insane to believe that.
Engineering means solving problems. A license is a license. They're unrelated concepts.
Firstly: class solidarity. The apparent death of (or at least notable decline in) class solidarity is popularly lumped upon software engineers because they're relatively highly paid, but it's equally as absent in newly created positions (mainly within the IT sector) at all salary levels. There's been a concerted effort to erode class awareness in the private sector for the past 40+ years & it's been effective across all sectors, mostly in newly created job categories without pre-existing union culture. It's in no way specific to software engineering as a role nor to high salary positions.
Secondly: ai & llms. Currently these technologies are monopolised by corporate entities, with models generally being far too inefficient to democratise, so it's obviously tempting to conflate their very existence with their owners, but if you're singling out ai usage as some kind of affordance to the capitalist class you're missing the woods for the trees. You need to separate ownership from existence/usage.
Yes, I agree. We are, however, on a site and in a thread that is dedicated to the role of software engineering, so I don't really care about the wider discussion at the moment.
My sole input here is that software engineering has not protected itself as a field, and it will now pay the price for that.
& my point in raising that this is not an issue that's unique to software engineering is to argue that the demons you're proposing software engineers protect themselves from are distractions from the root cause. You're proposing software engineers need to protect themselves from something that's specific to their field when the problem is holistic.
I have not said it's specific to their field. I've just been specifically commenting on that field.
(The lack of solidarity is perhaps specific to the field)
I think we're more like car mechanics in a lot of ways. The same way they might learn cars by working on their own, we learn computers. But I suppose that's still background of a sort.
Well, that would be because you don't really need to be a real engineer for what people call "software engineering". 50 years ago - maybe, 30 - maybe, but way less.
But for the last 15 years at least - you don't really need a degree to build meaningfull software.
Maybe you need it to build a new compiler or to work on a "close to metal" project etc.
But thats is. Most of people in the industry are called engineers, but let's be real - we are not the same kind of engineers as people who build brindges or airplanes.
No shit. I'm arguing that we should be held to similar higher standards.
When's the last time you saw a software engineer prosecuted for criminal negligence after a design error took down Cloudflare or whatever? Attitudes in software development will not change until that becomes a viable scenario that people anticipate when making design and implementation decisions.
The answer: require a written proposal for changes before a patch will even be considered unless it is sufficiently small.
Also fight AI with AI: have a bot auto reject patches unless they can link to a previously approved enhancement document. Folks who commit minimal effort will f*ck right off.
Then the cognitive burden is focused on the ideas, and code authors should have at least conveyed the intent. If they actually care to invest their skin in the game then they need to collaborate and not just drop garbage on the front door.
1. my company also employs its fair share of folk that would fit into the so-called "idiot" category of my post - I just thought it was of note that I have encountered exceptions to this stereotype
2. I fully support what Ladybird is doing here & find it unfortunate that they have to. I didn't intend my post to criticise their move - my example is definitely the rare exception in a sea of unmaintainable garbage. I do think however that it was already a challenging prospect to manage garbage oss prs in the pre-llm era (see umpteen posts on maintainer burnout) & I wouldn't have faulted any open source project for doing what ladybird is doing even pre-llm.
it's time for there to be some really nice workflow tooling that people can plug into their GH repos that does this and other things.
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.
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.
- 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.
I think that's probably the key - sounds like you are at a place that rewards "launches" and not long term maintenance and so you are ruining their KPOs or promo packet or whatever.
"You ship it, you take the pager. Once it's stable, then SRE org will take the feature. If it gets unstable again, SRE will hand it back."
If someone vibe codes something, and it works, then no reason not to merge it. So just set it up so if it doesn't work, they're on the line to fix it.
Along with their oh-so-supportive manager.
But also, if you have the clout, doing what you're doing nips the problem in the bud earlier, and so is more efficient. Good that you have the clout.
But what happens if:
* You're not the only possible reviewer, and they get some patsies / kool-aid drinkers to approve the PR?
* Their manager is also the code repository owner?
:-(
I never trust my own code. And one of the motivations of trying to be fluent with my editor, is to be able to quickly look at it when a bug is reported. I also don’t trust another person with their description of their code. Any surprise, and I’m looking at the source if it’s a available.
Them's fightin' words.
A person who says that to me - I ban them from... well, actually, I don't believe in banning people from platforms. Let's say I put them in my basket of deplorables.
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.
(And the whole "miffed AI wrote a shitpost" thing)
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.
There's no other correct fix - why do you care which pen I used to write it?
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.
Fork away. If you want to put in the meaningful effort required to maintain and improve upon a project as significant as Godot, and feel that AI is a mechanism you want in order to do so, go for it. Clearly, the maintainers don't feel that that's the best approach to create the product they want to create, and they are not required to accede to the sense of entitlement of the community.
Nowadays it's even more trivial.
And a community is more of a burden than an advantage nowadays. Users are ok, but a community not so. See python, perl, ruby, node and countless others.
In two or so years time, we can find out if heavily AI produced projects become more maintainable, ship more features and dominate the open source landscape. Or if human written and maintained code has a long term advantage. (Or more likely somewhere in between)
Either way, whatever anyone claims, none of us know, but we'll find out son enough.
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?
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.
Doesn't change the fact that working code does have value. If your program didn't do something before and it does now, that absolutely has value.
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...
- https://github.com/godotengine/godot/pull/115280 Implement C# .NET Integration via Headless Glue Bypass (Build 7ae8ec974) by Eliene-byte
- https://github.com/godotengine/godot/pull/107146 [.NET] Add web export support for C# projects in Godot 4 by Enrique726
- https://github.com/godotengine/godot/pull/117787 Readd .NET web export support by santosparra651-arch
- https://github.com/godotengine/godot/pull/119405 WIP: Add Web C# export pipeline pieces by acidstorm2024-star
- https://github.com/godotengine/godot/pull/119119 Allow building Web platform with C#/.NET module enabled by AndresFpdhi
- https://github.com/godotengine/godot/pull/119330 Cross runtime Solution to Enable C# Web Exports by tommygrammar
- ... and more (some of the claims on he opire thing seem to have been scrubbed, though, or they never opened PRs).
"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds."
https://rfd.shared.oxide.computer/rfd/0576#_llms_as_writers
> LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.
I think assuming a writer had your best intentions in mind has been unwise for quite some time. Murdoch built an empire exploiting this assumption.
And to be clear, it is reasonable to expect an author to invest more effort than a reader, because the work in question will reach many more readers and demand time and attention from all of them.
This principle was a part of basic netiquette back in the days of Usenet. I wish I could find the document (maybe it was a FAQ?) where I first saw it stated succinctly.
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.
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.
I look forward to the book: The Cathedral, The Bazaar and The Junkyard.
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.
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.
It was different, to be sure, but it was not worse. We are living through a transition, but people do that all the time and we adjust our behaviour and we find new equilibriums. We will do that with open source too, and if it ends up looking more like open source in the 80s or 90s, it’s gonna be fine.
Maybe some people who got really good at gaming their Github reputation are going to lose out, but that was never the point. Anyone who likes this kind of work and wants to get involved will find a way.
It is. Unfortunately, its not happening with open platforms. Communities are migrating to private discord servers, and less is discussed in public/in the open.
I think we should still separate "working in the open" from "allowing or not outside contributions." Outside contributions are fine to be denied, however I think work and discussions should still more or less happen in the open for the benefit of all.
One day discord will cease to be, and there will be years of institutional knowledge and lore lost.
I much prefer the old school forum style. Forums could be locked down to be invite only to contribute, but for the most part were still world readable.
I've heard of people within the argument directing SWAT raids at each other, or contacting employers, but I've not heard of it being driven by uninvolved observers.
Now... I've heard of people posting things on social media that others found offensive, and losing jobs/gigs over it, so that sorta supports what you're saying, but even in these "edgy" social media cases (which weren't "arguments" per se, in the cases I've heard about), I've not heard of SWAT/police reactions.
This is definitely a microcosm of what's happening to the entire 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.
That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
Boom. Maintainer. Easy.
Why would normal people even want to become an unpaid janitor for someone else's stuff?
Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.
Is the goal to produce high-quality software, or is the goal to produce an apprenticeship scheme for developers who are interested in the project but not so interested that they are willing to write an email to introduce themself or otherwise engage in normal human social interactions?
Normal people will still be able to get involved if they want to, just like normal people can get jobs. You learn about the organization you’re interested in joining, you try to meet some people and introduce yourself, you gain trust and prove your worth. It can be true that a pull request once embodied some of these tasks, but it is not true that being unable to submit a request means that these tasks are no longer possible to perform. It just means you’ll have to do them differently, just like the rest of humanity does when they want to get involved in an organization.
there isn't much evidence that this is happening. When you eyeball the average age of maintainers on mailing lists these days for prominent open source projects like the linux kernel, it's been steadily creeping up, to somewhere in the 50s now I'd guess. There's a complete dearth of people in their 20s or even 30s in particular in positions of responsibility, there's no next generations of leaders.
That's fatal in the long run. You need to have an apprenticeship system or something like a vocational pipeline to engage people in a structured way so that you can produce talent and also be objective and systematic. Something like a guild system you have in the DACH region where companies survive centuries, and that's not because random people write mails, it's because there's a industry wide support system and training process.
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've done it, personally. I've made all kinds of little utilities for myself kind of like a woodworker making their own jigs. While not purely "vibe coded," AI has let me actually finish a ton of personal projects that have been in my "eh, maybe I'll get to that someday" list. Now that there is very low marginal cost to make these tools, they can be highly specific, and they aren't all that useful to others unless someone else has the exact same problem as me, and well if so they can try to vibe code their own tool.
We'll get to a point where most of the open source projects are reserved for large scale infrastructure, as a cathedral not a bazaar, and then the vast majority of end-user level software will be highly personalized, custom utilities that generally aren't shared.
(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!)
i think the claim is that more projects are locking up contribution paths ~currently
(Sorry, accidentally negated my meaning there, what I meant is that they have only seen this current world. Or never seen a world where it isn't the case, to use a confusing double negation.)
A lot of stuff isn't. It may be open source, but the number of contributors is small and many large projects are cathedrals with people volunteering to lay some stones. The large projects often have core teams who organise and manage it, but then accept some contributions. It's closer to the organised Cathedral, than the chaotic Bazaar.
Now LLM spam has made it harder, so now there are fewer situations where it makes sense, and projects are switching to a cathedral model.
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.
> 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.
You're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.
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.
In one memorable case, by presenting it as problem+tempfix and inviting discussion, the developer argued that I should focus on repairing the other software that was the cause of brokenness. I agreed with them, we mutually closed the issue, and my code was (correctly) discarded.
Code is a secondary and optional part of the feedback process. Yes, it can be a more precise language for conveying a problem report. No, it is not necessarily a boon. Code never carried significant intrinsic value — the motivation of the author to show up and interactively participate with the project that was infinitely more valuable than any one patch! — and now with AI, code carries negative intrinsic value, indicative of drive-by patches with no likelihood of future participation.
The most effective contribution I made this month to a project was to spend three weeks reproducing a bug and then informing them of the process to repro it themselves. They were head over heels grateful, not only because I bothered to write a bug report, but because I followed up a week later when I managed to create a second repro case of the exact same issue under wholly different circumstances. The issue is, at its core, a reasoning error about a protocol handshake-setup-command process across 2+ devices, and patching their code to fix it is meaningless compared to the value I provided by simply showing my work in tracking down the problem.
Pull requests are, these days, more often an expression of entitlement ('I deserve praise, be grateful for my code, comply with my designs, or else') than of free-time invested into the project ('Hi, we've been working together in various bug reports for a while, and I saw this problem and felt like it would be a fun side project to hack on') and so I wholly endorse their decision to refuse them.
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"
Can you? The announcement says "There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks".
So I, as a human, describe in prose which changes I made to e.g. 20 files?
How is that in the spirit of fighting LLM slop?
Also, if I can do that, the LLM slop contributers can also ... do that.
That you can still report bugs
> So I, as a human, describe in prose which changes I made to e.g. 20 files?
Rarely does a bug require a description of what needs to be done in 20 files
> Also, if I can do that, the LLM slop contributers can also ... do that.
Yes, they can. Yes, they will. And yes, it's a problem.
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?
The real value we get from being open source is high quality bug reports and trust from our customers, not the external contributions. The only reason we welcome external contributors is marketing and generally being welcoming. If LLMs make this cost even higher for us then we might have to stop accepting external PRs.
Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs).
There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed.
From the other side, I have spent thousands of hours debugging and writing PRs to over 100 FOSS projects (e.g. glibc, busybox, util-linux, lz4, GHC and tens of Haskell packages, Jenkins, Chromium, GTK, Consul, OpenCV, Signal, many more).
Many of them are small or medium fixes ("drive-by fixes"), where you propose a PR, the owner reviews, says "great, thanks", and the bug gets fixed.
This is a fundamental workflow for open source work. The project gets free contributions and time investment outsourced to "the community" who fix its bugs, the developer-users/community get their problems fixed upstream, permanently.
This not possible for projects that don't have an easy way to submit code with low effort for both sides.
Accepting drive-by fixes is what clears up developer time and helps clear out the countless small issues in software.
If AI slop PRs are a problem, it seems better to establish clear rules and reject contributions that don't follow them with a single click, rather than banning developer contributions altogether. It seems to work acceptably for nixpkgs so far.
It is simply a fact that most commits are small - that is the nature of that kind of project. I looked at the commit history. It still takes a lot of work and it is valuable, but it has very different review requirements.
Ok, how come your little comprehension examination didn’t grapple with the main point: that they said they could not have made the changes they merged in themselves? Surely pointing out that the commits were small cuts AGAINST your whole argument. For a more complex project where vibe slop might not be appropriate (again, wild thing to say), the potential input from outside is more valuable, not less.
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.
An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
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
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...
Honestly, this kind of disregard and reductive reasoning comes across as corrupt and sociopathic. The sentiment is a recurring theme I see on HN more than any other forum, and representative of the moral and ethical systemic failure permeating modern business and governance; how most politicians, investors, and leaders treat their users/customers/employees/constituents adversarially, as though they are marks to be fooled, manipulated, and exploited without conscience.
We should always hold each other accountable and ensure our beliefs and actions are conducive to improving everyones quality of life and standard of living. Software is no exception. These should not just be virtues to be signaled through marketing, or while standing on a pulpit, or being recorded. They are how we should strive to live our lives in private, even when nobody is watching.
Perhaps you could provide some examples?
Nowadays any AI lunatic with a couple of tokens to spare can spare no effort, have no understanding and still flood you with a wall of code that on first look might even look okay (spoiler: it's actually trash). That is tiring for maintainers.
This is all about AI
(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.
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.
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 see all projects moving this direction. Makes more sense to hash out a plan together.
It’s the same about published journal article. A lot of them are a few pages. That is mostly one hour of typing. But everyone knows that typing it is not the work.
Deep research in the codebase, deciding on the flavor of code to write that matches the project, deciding how you'll model the feature with types, how to architect it so that it's testable, writing the tests, foreseeing cases beyond the obvious path, etc.
What changed is that it can be automated. Or, just grant a world where AI is perfect at implementation.
Now our time/energy/attention is freed up to concentrate the work around planning what to build. And the interesting part is that it becomes the input into the AI implementor.
This is a good thing since we tended to skip the planning stage since it's hard in its own way. Or we start building something and then try to synthesize a high level direction from it, yet now since refactoring is so expensive, we're committed to a solution.
So any project that doesn’t accept AI PRs is really missing out on significant investment
Would you pay 2000$ for those tokens? If not, the number is meaningless.
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.
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.
Yes, this is the takeaway for me. A PR can no longer be a reasonable proof of work.
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.
Yes, that is exactly what this announcement is about. That it was too much work for them to tell those two apart.
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.
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'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).
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.
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.
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 I think it's within the realm of possibility.
Online retail eating away at local shops is a problem with two aspects - one of which is largely ignored and much more pernicious.
Yes, many people are shopping online which reduces footfall in the town centres. If this were a case of all the existing businesses simply shifting away from physical storefronts to virtual ones it would merely be unfortunate.
What's far worse is that the vast majority of the business that shifted away from a diverse collection of bricks-and-mortar stores now goes through one of a very few online retail giants.
Likewise, a couple of food delivery apps are parasitising takeaway food businesses.
And now we're allowing a handful of AI giants to tollbooth software development.
Very easy to say that in hindsight.
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.
Agreed, and that was exactly my point. Concern about possible impacts of a technology were expressed and you responded that you trust your government. But that's not the same as thinking that everything is headed in a good direction and doesn't require intervention.
> Why does it matter how much I trust the legislative branch from other countries?
Because in a globalized world if everyone else goes to shit you will probably also experience significant negative effects even if it's not as bad.
> for the most part, we (humanity) are getting incrementally better.
It seems to me that it's prudent to perform a risk assessment rather than assuming that everything will work out just because things seem to have been going well enough so far.
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 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 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.
What I don't get, is why these LLM users aren't asking their LLM for how to contribute and how the project prefers to contribute, and how they can make sure it's accepted? Literally, the very same tools they use to code, can be used to make sure their PR follows all guidelines, from discussions to acceptance of the PR itself, it's right there, they literally just have to prompt for it! Such a lazy group of people.
AI just makes it so obvious how bad of a process it is that we can't ignore it anymore, and now we need to finally figure out good processes.
Even little stuff like: I've created issues on the Claude Code github that got agreement and then led to code changes. Why isn't there a default, built-in way for my issues to rise above the zero-effort chaff? If you finally do the work of vetting someone's PR, why isn't there a built-in (hidden) way to +1 someone so we can see that they have some reputation with the project on their future issues/PRs?
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.
I actually am training 2 trainees (Azubi in German) and 1 working student. All three are somewhat anxious about the future but also all are learning in a significantly increased pace, compared to the ones I worked with 1.5 years ago.
They don't have to wait for random senior to answer questions, so they get stuck way less often. They aren't allowed to use AI to generate code though, so not sure how that'd look like learning-wise if we/they went all-in on AI.
But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies.
Reality will catch-up with that too, once the other smoke clears.
Reduce your scale: "100x achieves in 1 hour what used to take 1 week."
One year of work could require levels of complexity and human judgement that can't be accelerated past a certain point.
1 week of work can be reduced to an hour and some change.
Besides 1h what used to to take 1 week is basically 40x given a workweek is 40h.
This is especially bad with new, or quickly improving frameworks, like Android Compose. LLMs use completely outdated, deprecated APIs all the time, when they are not completely supervised. Or at least, I hope so that the framework causes it. Because if that’s not the case, then your products are fucked.
Also even with the best prompts it could never produce more working code in an hour than what I can produce in a day. Regardless of quality, just “working somehow”. Not even with an uninterrupted session. If that’s the case for some, then there is definitely also a developer skill issue. And so would definitely not trust anything coming out of their “supervision” of an LLM.
If one week of work can be reduced to an hour, then you should be able to complete a year's worth of work in 50 hours. If you break that into two 25-hour weeks (because a 40x dev earns the right to loaf?), what is that dev doing for the other 50 weeks in the year? What is making them so incredibly unproductive 50 out of 52 weeks in a year?
In other words, if you include everything that's required to create useful software then 100x turns out to be a fantasy.
I do think it is hype as a killer of knowledge work. It can certainly remove a lot of friction in the kind of borderline mechanical work that you'd formerly outsource to the lowest priced denominator, serve as an idea bouncer, remove friction for bug tracing, etc.
Attempts to cross the next line ("no need for architecture discussions, ai plans", "no need to read the code, ai reviews", and so on), nope.
As someone else mentioned, 100x is a couple days producing the outcomes (remember, not output) of a year. Or for a team, iOS delivering in a single year ten times as many features as its entire previous existence. It's not something that doesn't get noticed.
At my large org (+100 engineers), I'd say it's a mixed bag and the overall impact of AI rollout looks to be slightly negative productivity.
They probably won't say it publicly though.
It's not because some people are more productive with it that all of them are and it certainly doesn't mean that the company itself is more productive either as you have other things than code to take into account.
Each of these three sentences are in need of some evidence. I'm not actually seing any signs of software velocity notably increasing anywhere. Except perhaps in the AI-reseller sphere, but that seems mostly due to throwing huge amounts of VC money at it and a lack of quality control.
I still believe that. 250 lines of tight code that solves a specific problem in a way that others can maintain will always be better than 25k lines of code that's difficult to review and consume (and, therefore, becoming a liability).
A year of that is 1.3M code: the size of systemd, or postgres.
Can you imagine a single person writing systemd (not a POC, the current version feature complete and battle tested) from scratch in a year? If so can you point me to any such project?
I don't think you could get to 1.3M lines of production code, but people say AI agents are good at writing tests. I could imagine that if you had an unlimited budget you could set up agents to generate lots and lots of tests and comments, inflating your weekly total. Like, maybe you can set up an agent to loop against a code coverage tool trying to generate more and more tests to hit MC / DC levels of testing.
In the extreme / absurd case, if you could hit the SQLite ratio of 590x lines of test code vs real code then 25,000 lines of code per week could be 43 lines of production code and 24,958 lines of test code.
You'd be a "100x programmer" in terms of lines of code output, but that would not get you to SystemD levels of production code in a year.
I can't point you to a project taking that route, and I don't have the budget to try it, but I can imagine someone hitting 25k lines of code per week with lots of tests and comments padding the numbers.
I am not sure software written that way would be any good though.
It's quite hard to quantify, but I think it's one shot nature really makes it hard to gauge it's capability
Friends have spoken of good days and bad coding days with me, and I find it odd nodding along, it's a strange new normal
At times it feels like we're just coding with one-armed bandits, trying to carefully line them up for a jackpot and just discarding and retrying if we don't hit
I think about some of the more complex systems I've built and I wonder how well we can build them like this
And over engineering, there seems to be over engineering everywhere, and yet, more fragility to our systems
It's all a little surreal
Or trying to reduce complexity, increasing readability and coherence of variable names (the opposite of code golf if you will), while staying within a certain limit of performance regression (e.g. "make this code as nice as you can while making it at most 0.5% slower").
Making the stuff millions of people have been using for decades better, in a way that also makes it better for humans when they read the code. Surely that's possible, some people are probably doing it but it doesn't go viral as much, because it's too mundane.
And of course, making new stuff is more exciting. I mean, you could hit on something with a vibe coded thing, and then know it's now worth to make a non-sloppy version, but you won't get much fame for making ffmpeg twice as fast by prompting an LLM. Though on the other hand, it's like a safe investment (if not in "fame", then in "improving the stuff we all have to use daily"), because you know ffmpeg and many many other things will still be around, whereas a vibe coded thing that wasn't special will be 100% forgotten the next day, or have just the one user forever.
I wish I could be so optimistic. Our lives are ruled by distorted, irrational, inefficient, failed markets, and the markets can remain distorted, irrational, inefficient, and failed for longer than we as individuals can remain solvent. "In the long term the market is a weighing machine", for term lengths that include the heat death of the universe.
This is insinuating that code was the bottleneck in the first place, or that every line of code is to build a new feature and not fixing existing bugs, or that apple didn't lay off enough engineers and reallocate resources to other departments to make up for the productivity boost.
I do think that companies with poor AI practices will eventually pay the piper in the form of technical debt or debilitating bugs. But let's not equate a productivity boost with a boost in releasing features, because there's plenty of business reasons to not release thousands of new features every year.
I agree with you on the rest of your points. Eventually the smoke will clear. What awaits to be seen is who is left standing when it does? I don't think I like the answer to that question.
It’s been enormously alienating talking to laypeople about the apocalyptic atmosphere in the tech world, while for them ChatGPT is a cool piece of software but the world still hasn’t changed very much. They look at me bug eyed when I tell them how dramatically software engineering has changed in the matter of a couple years. We are in a bubble, or we’re just, as you say, in the eye of the cyclone which still has to hit the rest of the world.
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.
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?
I wouldn't say it's asinine though. People reject creative output out of personal protest against the creator. Someone might love a movie only to refuse to ever watch it again because they found out the director was accused of something horrible.
Some people just don't want to support anything to do with AI. Although in this case the OP admits to also using AI directly so there's some inconsistency there, which is consistent with the state of confusion and uncertainty OP is expressing.
I'm sure the religious fundamentalists would have something to say about that XD I'm not one, though, but I don't much appreciate the framing of needing a more "rational" stance here as it kind of signals bad faith to me. There is nothing emotional about worrying about artists' livelihood which has already been under attack for decades before LLMs existed. I'm not saying that one HAS to derive (additional) enjoyment from the presence of a creator. I listen to plenty of human-produced music where I don't care about the artist but these are always songs that I listen to for a short period of time then never think about again. And of course this goes way beyond just who the creator is as a person, it's also about what they inflict into the art itself: the unique vocal inflections, odd ways someone play's an instrument, how they perform it... but that's getting more into this than I meant to when I started typing what I thought would be two sentences, lol.
Anyway, I'm also not saying that people can't enjoy generated output, I'm just not going to support it. Especially since there is still always a person behind it who is maybe going to benefit from people listening to it. No thank you.
Movie studios are "signing" AI artists from AI studios for massive dollars; this is happening.
Maybe you don't care, but music is beautiful and difficult, and I really enjoy hearing works from people that have a passion for it.
You don't have to worry, though; most people are in your school of thought. "Who cares? It's good." Short-term thinking is best-term thinking.
I am in favor of being able to find music I like, with the least friction possible, without fueling the legacy music industry that is inflated far beyond reasonability.
This is tribal thinking.
They (theoretically) have the physical infrastructure and capital to produce entirely AI-generated records, master and press them, promote and market them, retain an in-house band to play the record and book venues for them to play in (see also: Live Nation/Ticketmaster).
The members of the band are replaceable, thus capping the compensation ceiling.
The label retains almost all of the revenue end-to-end in this model. No messy contracts (except to AI providers).
Why would they invest in human talent that has needs, like, idk, sleep, when they can have AI-generated artists that can be available any time for any reason? (Lots of people don't care where their music comes from, unfortunately, and Spotify, the biggest streaming app, is already working hard to desensitize people to AI-generated tracks.)
This is already happening:
- https://www.ohio.edu/news/2025/07/your-new-favorite-band-may...
- Even Timbaland (very successful producer in the 2000s) started an AI-only label: https://www.thefader.com/2025/07/25/imoliver-human-ai-music-...
Because we don't read reports just to have something to read, we do because we want to learn something about the world. And actual music fans don't listen to music just to drown out the silence, they want to listen to what another human being has to say, someone with their own history, experiences, views on life and the world, something to say and the creativity to express it in an interesting way. It makes absolute sense to be pissed off at something artificially generated, devoid of any intent or meaning, statistically generated based on a mass-pirated library of real musicians' work, skinsuiting as music with content.
I admit there are situations where music is used just to have sound, and some people just want to have something on in the background without having to pax attention to it. And one could lament or not the fact that humans are no longer really necessary to produce vapid muzak. But going by the GP's words, I don't think that that's what they were doing or looking for.
Maybe, just maybe, you're not thinking rationally/logically about the situation and instead are mostly operating on emotion and feelings?
Have you ever had an experience where, by all calculations, you should be happy with the outcome but for whatever reason you're not?
In some ways, that is the state of the internet today. Everything is optimized based on analytics, but so many of use are unhappy with how things are.
> 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.
Therefore a maintainer is more likely to steer the AI in a direction that is aligned with the codebase.
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.
For now this makes sense.
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.
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.
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.
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.
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.
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.
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.
Yes, but one key reason that a stable ABI isn't provided for drivers is to help encourage companies that ship drivers to make their drivers open source. The idea being, if a driver is mainlined into the Linux kernel, the Linux developers will help maintain support for that driver, in exchange for it being released with an open source licence. There are companies (like NVIDIA) that ship closed source drivers for their devices, but they rely on a kernel-side shim that interacts with the userspace driver, and this is seen as second best compared to mainlining the driver in the kernel.
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.
What I am curious about as someone who has been kind of cheering off on the sidelines is if there's any way that folks could get involved still in the future or if this is in practice permanently a closed project?
BSDs are more cathedral style and getting maintainer status is usually pretty onerous from what I understand but there are at least routes to it available to people willing to make an appropriate level of investment.
I'm not at a point in my life where I can meaningfully provide that kind of time and energy into serenity or ladybird but if my circumstances changed it's the kind of open source project that I would love to dedicate my time and energy towards in the future and I'm sure I'm not alone in feeling that way.
I feel like 1/10 comment I make on HN are about this.
So merged PR were until LLMs a good proxy for the ability to code and contribute to a software project. Consequently they were used to estimate if a candidate was potentially good for a position. Merged PR on popular project were thus precious credentials one could "trade" for potential work. Since then the desire to provide PR changed from contributing to a project for its own sake, to make the actual project progress, to signalling.
A new proxy must be found to establish the ability to contribute to a project.
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.
How do you do that efficiently so it can scale?
What I can imagine though is that
- the value of merged PRs might drop (as it's not a good metric anymore)
- while the cost of submitting them goes up (as price per token is radically changing, e.g. Github announcement just this week)
so maybe it's also only temporary.
Also if all this is correct, including the value of PR on popular repository being more important, then the long tail of projects might not have to worry about this.
I think closing contributions (due) to AI will be looked at in a similar way. Forks open to AI will appear, and take over. And people will return to the open model. I think it needs more proliferation of AI coding and reviewing tools, so that AI contributions can be automatically independently reviewed for quality.
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.
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 exactly is different now?
> it's under development and very likely will be forever.
So is Sqlite. Last time I checked they are still actively developing Sqlite.
Do you mean you can't just grab a current release and hold on to that? Well it's pre-alpha... That's the point...
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.
They probably could do that as part of the hiring process.
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.
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.
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?
As for well-documented, the reviewer can decide that when they are reviewing the smaller PR.
Nobody said volume is not a problem, but closing down contributions entirely is a step too far.
Is this a sponsored project where maintainers are just hired?
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.
Integrating some kind of proof-of-stake system might be a way forward for open source. Nobody wants to shuffle through a pile of low-quality PRs written by LLM.
This is probably the best, most succinct explanation of what we're seeing happening in the OS world right now.
If AI is the problem, the solution would be introducing an AI policy, community trust management system or something like that. Definitely not a closed development process.
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.
Though in retrospect we should have seen it. It's been an angle of attack since forever, it only took a lot of effort.
Also, Linux has many more people, many of whom basically just review code.
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.
Make a better Ladybird successfully to the point the original contributors take notice. If the barriers to doing that are truly lower, then it should be easier.
It's heartbreaking, my two favorite things about the internet are dying off because human interaction can't outscale AI slop.
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.
As far as I can tell, architecture, i.e. sound, precise definitions of exactly what a software artifact must do, is now critical. And with LLMs, it's now feasible to begin implementing such things, though many brownfield projects may be intrinsically unsound in ways that their creators are unaware of. In such a world, contributions simply require a modified proof that the software does what it must do, with perhaps additional claims that the maintainers provide.
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.
That way new contributors are forced to start small.
1. Opening an issue. 2. Talking about what they want/need that's not catered to right now. 3. Asking for my thoughts or suggestions - even if they already have a potential PR to submit.
and that is for a small codebase where changes are rarely that big of a deal in terms of amount of effort.
I've gotten a few decent 'cold-submit' PRs as well, but my bias has usually borne out, in that these are usually PRs to reject, and only some of the time get adapted into something useful, following some back-and-forth of course.
So, on the one hand, the measure the LB people are taking seems extreme to me; but the previous state of affairs they allude to seems equally weird. (I mean, unless it's a "here is a two-liner fix for a bug" kind of patches).
I wonder what it will be referred to as, after the dust settles?
Although I no way suspect this particular individual of anything untoward, of course it's always possible it could be part of one of the long-term goodwill-generation campaigns mentioned by the Ladybird team. Generating credibility by making seemingly difficult genuine contributions over a long period, then abusing that credibility. But in our particular project we're not in the habit of delegating approval authority, so I'm less concerned about that.
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.
In this type of system, if I am competent and can contribute how to do I? By reviewing the maintainers PRs, helping fill out more info for bug reports / root causing?
There had to be some way for a competent user to get involved enough to become a familiar handle to the maintainers and be seen as a possible future maintainer/ expert contributor right?
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.
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?
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.
Applies so, so widely. Glad they’re taking (very necessary) action here.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
Without one they will slowly lose all maintainers by attrition.
Of course, if they are also concerned about the quality of external PRs then that does not help.
Trust is key.
It’s controversial to say, and I may be downvoted, but I’ll share this as a pov: OSS is essentially giving away our work for free. Did that ever really make sense? If it does, why don’t graphic designers give their work away for free? Why don’t authors do that? UX designers?
It’s a very peculiar thing to us nerds.
And the strangest thing is, we may have unwittingly built the data source required to make our skills redundant, as models are trained on the work we gave away for free.
I think this is an interesting narrative.
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.
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.
What should probably be done is PRs are treated as “reimplement requests”.
“You had your agent write some code? Great, we’ll take it from here, and reimplement it ourselves.”
"I would have written a shorter letter, but I did not have the time." -- Pascal, 1657
Think about it. Anthropic just reported that their codebase is now improving itself. We're moments away from every open source repo being able to do the same. Think of it like torrenting — you'll be able to open your repo to the public, and have a stream of code flow in from millions of contributors. More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days.
Ladybird doesn't know it yet, but they just left themselves in the dust.
why would you want this. this sounds terrible
I'm picturing something like folding@home, but where people donate their spare tokens to a service, and those tokens get distributed amongst all open source projects on GitHub. You don't think that would be cool? Like, someone might initialise a repo with only a readme and a to do list before they go to sleep, and then wake up to a complete software ecosystem that looks as if it's been in development since before they were born. Like, so much code that no one person could possibly understand it, and it all happened overnight while they were sleeping!
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.
"green" and "the right artifact exists" drift apart faster than expected with more automation. exit code wasn't enough for us — had to make the output file the thing that proves a run happened.
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.
Of course they can, the problem is they have to spend time digging through a ton of garbage looking for the ones that aren't low quality slop.
If you're getting DDOSed, you start by putting up a firewall lol.
they can vibe-code their own browser, there's no need for the public to access every single open-source project anymore, you need to find people you can actually trust
What the Ladybird maintainers did here was messy and a punch in the gut to actual contributors who liked the project and the openness of it. There was no effort to shore things up, just a boilerplate message from a maintainer account then closing of your PR. Of course, Ladybird maintainers have no obligation to outside contributors but it shows a lack of grace nonetheless.
Reading between the lines, there seems to have been a stark shift in attitude from Andreas which is concerning. Ladybird started from SerenityOS (a hobby OS) and he always encouraged everyone to submit a patch. Sure, LLMs have increased the amount of slop PRs, but I feel like those are easy to spot and close accordingly. I don't have links handy, but maintainers would point to a section about AI usage in their CONTRIBUTING.md then close the PR whenever obvious slop was submitted. This idea that people "own" the code they contribute is strange to me; the code would be determined worthy of acceptance at review time, why does someone have to "own" it?
All that is to say: I think there's much darker things going on here and AI+security is a nice scapegoat. Time will tell, but this reeks of a rugpull in the future. Disappointing day.
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.
I think your thought was cut off. What is the project no longer?
The open source definition was created in that mind. It does not state or imply open development or a community are requirements.
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).
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.
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.
Yes, Ladybird is facing a wall of slop... no... A tsunami of slop overwhelms core maintainers. Probably safe to generalize to other popular open source projects.
The project is important and the code is beautiful! I spent many happy hours trying to understand the code, browser-specs and tried to adapt to their coding style. After 18 months I ended up with a few merged PRs. Some were pure joy to write. I got to work directly with most of their core maintainers in the review cycle. They're great!! From the outside, it seems like their responsiveness to submissions slowed down in the last few months... slop.
Of course, it would be great if there was another way, but here we are.
Love <3 to Andreas and the core maintainer group! Keep up the good fight! Maybe we'll meet again.
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.
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.
Maybe also limit the size/scope of external contributions (only small bug fixes allowed for your first few PRs)
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.
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...
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.
> 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 are playing a mean game of Secret Hitler. I guess only time will tell.
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
How is this the top post on my favorite website?
This is partly due to Ladybird building on low-level system-language primitives that make it harder to identify problems, and while they are porting to Rust it's not fair to say that C++ is single-handedly the cause of this, because regardless of the language, in a complicated interconnected codebase the complexity easily compounds. It's a real shame we don't have the option of a trust-graph filter stop-gap that can filter contributors with a social model of who is trusted for what, purely as a heuristic to reduce the risk of bad contributions (not as solid proof of soundness).
This whole situation shows the way that development has been done isn't nearly as transparent as just having the source code being available.
We haven't been able to say what we want the code to do in a way that can be tested robustly enough to make openly accepting contributions sustainable, and it's unfair to blame the team for that because on top of needing to develop and review their own changes, it's an incredibly difficult problem with only so many hours in the day. I hope we figure out the representation and social trust graph problems, and that people continue to build on their great work.
Bad actors pay good money for vulnerabilities and patient actors are invested in slowly introducing them. Agent loops like Codex or Claude, with Anthropic's Mythos model finding ~271 Firefox 0-days, and helping fix them shows both the problem and the promise.
It's bitter-sweet in a way that Ladybird is great at showing how the incidental complexity of web browsers could be vastly reduced. To protest being gagged, cryptographers made t-shirts with DeCSS DVD or RSA algorithms on them. Alan Kay suggests that t-shirt computing is actually a useful target, and STEPS by his Viewpoints Research Institute managed to really distill some parts of OS-level and desktop publishing software down into minimal, more understandable abstractions that encode the rules of the programs with more appropriate patterns for the problems at hand, that might more plausibly fit on a small wardrobe of t-shirts. Browsers really need this range of t-shirts making.
As a minority browser user (and someone wanting to build on them), I'm excited to see Ladybird get increasingly usable for real browsing, and I am hopeful that in time, the spec representation gaps, and social trust map heuristics are solvable problems that could restore the dream of open-source, or at least stop a trend of closing (with tldraw doing this much earlier, for a less risky but still thorny project).
(Seems I ran out of edit time!)
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.
They should make the barrier to create a pull request higher, they should detect slop pull requests, they should hand maintainers tools to deal with this bullshit.
Sadly they do not have the right motivations to create all of this. Because all of this would mean less usage of AI.
If I were GitLab or Forgejo, I would be working exactly on this, to get the projects who are struggling the most with this problem on my platform.
Then the linux kernel is doomed. /s
We'll have more such disruptions and we'll learn to live with it.
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?