I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description).
This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful.
It's kinda surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort.
In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a post-ai world. They were always out of line & continue to be.
Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from, say, someone cargo-culting code from tutorials.
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 see AI as a barrier remover. Unfortunately some barriers are good or minimally necessary.
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.
This is entirely too much friction in the wrong place. Public open source will simply die before a system like that ever becomes the norm.
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
I agree with the bond in theory, but that would entirely stop contributions from people in economies where a shady maintainer could keep their code, and their weekly food budget.
We already have trouble with people maintaining open source projects without getting paid, now you want people to pay for the privilege to participate in free work?
But your company employs said individual, whereas arbitrary drive-by patches from randos on open source projects with no consequence of submitting a mountain of garbage.
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.
yes. github has very minimal controls for PRs (either shut them off completely, or not at all) but through GH webhooks you can essentially script "auto-close" of PRs that dont have correct preliminary approval.
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.
> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
It is 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.
Man, you must hate those handymen who put up YouTube videos showing how to do basic home maintenance. A truly class-conscious handyman would insist that the homeowner hire them to replace a light switch.
How this is equivalent at all? The proper equivalence would be "You should be happy a random passerby decided to re-wire your home after watching a youtube tutorial and thank him accordingly".
There certainly exists a class of electricians who believe that homeowners shouldn't be changing a light switch, and jurisdictions exist where a permit is required to do so.
Come on, are you really going to strawman "engineering should be inherently disqualifying" into "so people shouldn't DIY in their own home"? Please try a little bit harder.
I’m not strawmanning anything. I’m pointing out what I believe to be ridiculous gatekeeping. Software engineering isn’t some holy magic that must be kept from the masses.
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.
Alright, I guess I'll take the bait. Not much else going on today anyway.
> 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.
Your initial post on class solidarity was extremely reasonable (even if I disagreed with it - see my comment above) but to follow it up with a post describing castes in a non-negative light is wild.
In hindsight, the word "caste" is too heavily loaded and I should have chosen a different term. Sorry for the shit choice.
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".
> 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.
I consider this mode of thinking selfish and anti-progress. It’s pretty much exactly what Americans decry about unions.
I support workers being compensated for their value; what I dislike are protectionism and ossification.
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.
You're throwing around the term "ossification" like it's a guarantee or necessity tied to anything being discussed here, and that's just not the case.
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.
I’ll be blunt and say you certainly sounds like someone “post money” talking if castes and such. Glad you got your nut and do not care how it shakes out.
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.
Assuming you're being genuine (which I have a hard time believing because your argument is quite literally a strawman, please read the definition), you're missing the context entirely. You can't conflate small DIY projects done around the house with developing software that thousands of people and institutions rely on. By all means you can go and watch a video on software development, but that does not entitle you to expect that PRs you make will be accepted to any project other than the ones you control yourself.
Please re-read the specific comment I replied to. It was someone expressing indignation that a software engineer would accept “high-quality” PRs from a non-software engineer, accusing the poster of lacking “class consciousness.”
> hard for me to imagine another engineering discipline....
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?
> 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.
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.
> 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
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.
happens all the time. Some business jerk outsources an entire initiative, forces it through review, and we get dumped with externally written crap we gotta deal with. So what if claude wrote it, actually claude is better than money wasted on those outsourced piles of crap projects
Ooof. This is a big topic - I understand where you're coming from, but it's a common sentiment & one I've recently come to disagree more & more with.
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.
> It's in no way specific to software engineering as a role nor to high salary positions.
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 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.
Gratitude was maybe the wrong word. As the article mentions, before ai I think larger PRs, while sometimes inconsiderate, at least implied some amount of care / effort / good faith. In my experience, that was often rewarded with the maintainers at least taking a look at the code. I meant it's odd to have the same expectation when you dump 3000 lines in a pr that you won't even personally write a description for.
There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs.
It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.
It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.
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.
I agree it's not "entitlement" specifically but there's something there. I guess by now everyone has experienced that type of person that "tries to help" by copy/pasting a bunch of AI slop and expecting you to work through the cognitive load of validating it.
The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.
> It 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
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.
If a project has a rule to not submit AI generated PRs, people should never submit AI generated PRs to that project. It's spam. Or if the rule is more nuanced than that in relation to AI, it should be respected.
It's 100% an issue with the people with submitting these PRs. So, if someone has a history of having no issue with breaking project rules (let alone being arrogant about it), it should be a massive red flag about the person for any possible employer or future collaborator checking their profile, etc.
Why people are wilfully destroying their own reputation like that is beyond me. It's infinitely better to have no activity at all on your profile than to create a track record of bad behaviour.
I can imagine in these cases the LLM is telling the "contributor" how smart they are and how much the project is loosing out, maybe saying something like: "It's not about maintaining project boundaries, it’s not about ensuring code quality; it’s a gatekeeping mechanism designed by traditionalists who feel threatened by forward-thinking creators like you who truly master the efficiency of AI."
Whether or not they are, I agree it is entirely possible to imagine them doing that, given what we know about how AI chat has reinforced people doing much worse to themselves and others.
(And the whole "miffed AI wrote a shitpost" thing)
really? in the way the parent comment describes? (genuine) i suppose i've never encountered a context where it would be relevant for an LLM to output that, interesting
> What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful.
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?
If I don’t word these critiques in the most diplomatic way possible, this immediately turns into a discussion about the prevalence of anti-ai sentiment on hn. Which would be boring.
What would be great is something like Pangram for PRs and issues. Detects if the PR or issue is AI-generated (with multiple checkers for redundancy) so that maintainers can choose to auto-close and PR authors have to at least manually write _something_ before they launch 20k SLOC diffs.
> They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
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.
> What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful.
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.
It's interesting to see this perspective in the wild. In the age of AI I wonder what "massive value" your PR is bringing to the maintainer. $1 worth of tokens?
I regularly find the code output of opus and gpt 5.5 to be garbage. Overly verbose, unnecessary abstractions, strange duplication of concepts across objects, unnecessary copying of objects and creation of objects. I have found its much more useful to just ping pong some ideas, have it generate helper methods, and do the code implementation by hand.
I think this is one of the grand realisations, and it is why local models are much, much more of a threat to the "metered intelligence as a global utility" business model.
As an AI-cynic I am much more interested in learning how AI solves my problems (of which I have many), not how it can revolutionise programming. How about it revolutionises me not experiencing task paralysis first.
This thread is in the context of community PRs in open source projects. So it's not about AI or not, it's about maintainers using AI vs random contributors using AI.
My point is that with AI, where the actual code generation is easy, there's little value in community PR contributions anymore.
> Only stoneagers would say that they are better than a good AI.
I am only a bit above average and I clearly still write better code than a good AI.
The only question left in my mind, alas, is whether that is enough to earn a living.
I mean: it is clear that in every domain except for programming, a talented XYZer can do better than an appropriate LLM trained to do XYZ (except perhaps in some absolutely exhausting pattern recognition tasks).
So I am not sure why we see our own field as different. A sort of inverted Gell-Mann amnesia?
I mean, aren't you kind of proving the poster's point?
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.
Even before AI it was trivial to setup a continuous merge script. I did that several years for several projects which refused my PR's.
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.
The generalised form of this, which we are rapidly discovering, is that AI breaks the social contract that used to exist between an author and a reader (of prose, code, anything).
Precisely. In the case of OSS it makes no sense for maintainers to spend more time reviewing AI generated code than contributors spent prompt engineering it. That's just not helpful.
That's the most succinct way I have seen someone put it, thanks! It's really the same issue, no matter if it's software, online comments, e-mails, artworks, homework, etc. We engage because we expect to be interacting with the output of another human being. AI fundamentally betrays this expectation.
Yes, and there was a good post about exactly this social contract last week https://jola.dev/posts/the-social-contract-of-writing. I find the argument compelling on the face of it and true in my experience with colleagues and the broader digital landscape recently.
I wonder how many comments are from bots in this discussion. Few days ago there was a discussion of traffic stall at the strait of Hormuz on HN. One comment from an user with over 9000 Kama went like "I just checked the traffic on the road and it is normal ...". Unfortunately other bots are not as easy to spot as this one.
I agree, I suspect what Ladybird is doing here may become the normal social model for open source going forward.
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 one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.
On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
Open source development has become more and more superficial aligning with modern social network characteristics. It's more important to have an contribution, a active commit history, a few stars as a proof of pixel fame than the intrinsic value of the contributions or projects.
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.
Yes. Open source existed and thrived before GitHub, before git, and before anyone had ever used the words “pull request“.
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.
World readable has become a liability as well. How many times has some random disagreement been blown up by observers and lead to people being kicked out of groups, jobs being lost, or SWAT raids?
I’m never getting accustomed to the fact that there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style (are people these days even aware of the metaphor or Raymond’s book?), a world in which the frigging Microsoft is a major OSS vendor and in charge of facilitating most of the open-source programming on the planet. Try explaining that to a time traveler from the late 90.
(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!)
> there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style
(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.)
I think that was a natural outcome of cheaper merges/conflict resolution in distributed version control. It became easier so there were more situations where it made sense.
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.
of course not literally 'everything', but as someone that grew up in a post-git world, with github as the 'default', to me projects that don't accept (or expect!) outside contributions have been the exception; definitely aware of notable examples (sqlite? some web servers, a few internal-libraries-that-outsiders-use?) but very much used to the bazaar
i think the claim is that more projects are locking up contribution paths ~currently
Umm, I missed a negation there, sorry. I meant that the newest generation has only seen a world where there's a giant OSS ecosystem and the bazaar style is the norm for all of your tool and library needs.
> it will also make it more difficult to identify who to invite to join the priesthood
The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.
How many people will ask to be a "priest" and will then violate the rules around AI?
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.
There are great Open Source projects doing fine with the cathedral style, just look at Sqlite and its siblings (Fossil, …).
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
I still don't see solutions on how a normal person can become a mantainer though.
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
> how a normal person can become a maintainer though.
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.
The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn the rank of "maintainer."
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.
In this case they seem to be firmly closing the path though
> 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.
They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.
The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.
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.
It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
> 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.
That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.
> it more difficult to identify who to invite to join the priesthood.
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 think whats more likely to happen is patches & forks stop being shared. If AI continues to improve, I see a world where people are mostly no longer making software for others, but purely for themselves.
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.
fwiw I asked Claude to look at GP's post and write me a story titled "The Cathedral, the bazaar and the junkyard" and I have a pretty good time reading his riff.
> There will not be a [..] process for submitting patches by [any] means
> Outside involvement still matters: clear bug reports
So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly.
As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.
It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.
> a pull request no longer tells us as much as it used to about the person submitting it
Nobody should need to know anything about any person submitting a pull request.
Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.
Reviewing code fixes is strictly easier than coming up with them yourself.
This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.
As a project you can always ignore or close a PR you want to write yourself instead.
But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
exactly. a _proposed_ code fix is a good indicator where the problem is (analysis) but more often than not the actual maintainable and sustainable solution will look different.
a code owner may choose a very different way of fixing things, even for what looks like a trivial fix.
Reviewing code in PRs is not a no-effort action. If there are 3 people working in the project, and thousands of people submitting bugfixes, then no matter how useful those bugfixes might be, the 3 people will be totally overwhelmed by the sheer number of PRs.
There might be value in your bugfix, but maybe that value is not greater than the cost of reviewing and accepting it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
This is completely false, for any sufficiently complex project. The fix might be a single line change, but the consequences might be far reaching.
> As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software?
Please don't! You don't owe the project anything. The other side of that equation is that the project also doesn't owe you anything. As simple as.
Firefox and Chromium are running much larger teams, let alone the Linux kernel, that other people suggested as a model. Maybe they can afford accepting your contributions.
> 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.
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?
Yeah, I am employed by an open source company (to be clear not open core) and most of the external code contributions we get are a net cost for us. It takes more time to review than it would have taken for our team to code and review.
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.
> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years
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.
Thanks for your work on nixpkgs but I think that shapes your perspective quite a lot - its a very different project from Ladybird. Not to belittle your contributions there but the majority of commits there are a few lines of code and much of it is declarative. I'm sure a lot goes into review of entirely new packages and there are some complex interactions between dependencies to consider on some changes but not in a program structure or logic sense. Vibe slop may not be so much an issue there.
You can still tell them how you did it, just not in the form of code/patches. You should be able to describe it in prose so that the maintainer understands your solution approach.
Not necessarily. I just fixed the Ladybird build process so it will successfully build on a system that uses musl instead of glibc. By far the most compact way of explaining what needed to be changed is to share the changes themselves. It is a set of very small changes to a number of individual files.
That sounds more like a new feature than a bugfix, however. That aside, I didn’t claim that it would necessarily be more compact, just that it’s possible. Any change can be described in prose, to whatever level is necessary to get the essential insights across. It’s how the ancient greeks did mathematics, they didn’t have symbols or formulas.
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 still submit a bug report and tell them exactly how you did 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.
In the post, the ladybird maintainers say that they trust pull requests less than they used to, because many pull requests are authored by AI now. A big pull request no longer signals that the submitter put in a lot of work into it and it's committed to developing and maintaining quality code.
Not sure if this happened to ladybird, but the amount of junk vibecoded AI-slop pull requests has been putting an immense amount of strain on many open-source maintainers. Reviewing stuff like that is intensely energy draining an most of the time your comments will just be copy-pasted into claude code and the "contributor" will put in 0 effort themselves to try to make the code readable or maintainable.
Before AI, being open source and having to manage issues and PR's was already a huge task, burning out maintainers left and right. Now with AI, anyone with a terminal and a claude code subscription can open PR's...
So the solution is for FOSS developers to pay large sums of money to AI companies, to solve the problem that the AI companies created, for profit? ... and you typed this out as though extorting charities were a solution, instead of a grotesquely immoral and unethical systemic failure?
AI reviewing AI. Or in other words, having non-deterministic systems review the creation of non-deterministic systems, hoping for a deterministic result. Good luck with that.
This is direct result of AI as you can see in many other public repos.
before AI like 1 in 1000 would spend their time fixing something they had no idea about and even then considering how much time you spent and how few of those happened it made sense to review/talk about it.
now every "dev" with claude submits prs having absolutely no idea what they are even doing.
most of them would not even be able to create PR without AI in the first place.
and on top of that add slop bots that "fix" issues in the loop and create hundreds of PRs daily
I can understand where they come from. If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves.
I think the whole game of software engineering, open source or not, has completely changed. A lump of code doesn't mean or imply the same thing as it did 2 years ago.
A few years ago, if I send a complex PR that compiles and passes tests, that implies a certain amount of time and cognitive investment on my part. It seems likely that I wouldn't invest that if I didn't also understand the codebase, the feature or bug I'm working on, etc.
Now, that understanding is roughly as expensive as before, but AI has vastly reduced the cost of generating the code that compiles and passes tests.
Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).
"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"
As the FT summarizes,
> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.
So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.
And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.
> If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves.
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.
The code just isn’t the main effort of work anymore. Anyone can generate the implementation, so it makes more sense than ever to instead hammer out the what, why, and how that underlies any code change.
I see all projects moving this direction. Makes more sense to hash out a plan together.
Code was never the main effort of work, but it was a clear signal that someone has done the main effort, which is understanding the codebase, designing a new feature, or investigating a bug, and have the knowledge to write the code. By the time you get to review, you can expect a knowledgeable person on the other end.
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.
Right, and all of that is what I consider to be the "code" effort:
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.
For anything but the most trivial change, a prompt is not enough though. There's a long iterative process of generating the right code, reviewing it, testing it, experimenting with UX or design for maintainability, fixing bugs... even a predominantly AI-generated PR can capture a lot of value. But apparently trying to distinguish those from the 'one-shot' vibe coded PRs is too much work for the Ladybird team.
> But apparently trying to distinguish those from the 'one-shot' vibe coded PRs is too much 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.
When I contribute to OSS with AI I’m essentially engaging in a donation matching scheme where Anthropic matches 1 to 20 the dollar value invested (usually I can get ~2k of value per month on the $100 plan) in the open source project.
So any project that doesn’t accept AI PRs is really missing out on significant investment
> the maintainers are equally capable of prompting Claude Code themselves
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).
Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.
(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)
It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.
(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)
Those corporations are not doing that out of the good of their hearts. They are doing so to assert control, in order to protect their business value. If it stopped being economical for them, they would stop tomorrow.
I do not think we should be eternally grateful for monopoly building.
When AI first happened, I was afraid I was going to eventually lose my job. And while I've been lucky since, many did, and that hurt a lot. When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans, or at least hope that society keeps being fair to those who are most affected.
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.
>But all now seems like a transition phase. Transition to f-ing what though?
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've been thinking a fair bit about what I'm seeing in terms of the output I experience
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
I imagine this stuff is probably really good at iterative changes to improve objective benchmarks like CPU or RAM use. I'm thinking of little contained optimizations that you can understand in and of themselves, that you maybe have done yourself before in other places, found really quickly and applied uniformly. Stuff you can confirm to be what you expect it to be by mostly just scanning. Low hanging fruit for sure, but something where you can actually know what is a fruit and what is crap, and only keep the fruit, and develop some confidence in the process, if that makes sense?
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.
> Juniors want this to be a chance to shine in a market that otherwise rejected them.
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.
Is that a good thing? I think getting stuck is an intrinsic part of the learning process and sometimes it's good that there isn't an immediate answer from a senior. For some things you'd never have solved yourself, sure. But pain and suffering is a big and important chunk of learning and I fear we just throw it all out of the window with asking AI.
I am skeptical. This is a testable hypothesis, and I know there have been tons of research done trying to provide evidence of claims like these. However I have yet to see a convincing evidence. If this statement was indeed true, I think experimental data backing it up would be old news at this point, it however is not, and I suspect that is because junior developers are by and large in fact not learning faster or more with the help of AI.
> 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.
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.
> iOS is not delivering a decade of features and fixes on each yearly release
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.
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.
I sense your comment as saying: "AI is hype, and reality will catch-up.".
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.
Ignoring the obvious math problem here, I think the broader scope is important. Some of the point from preceding comments is that overall longterm output is not changing. So if somebody is oneshotting a week of work in an hour, but has the same annual output... where are you losing all the normal productivity that should have happened the rest of the week/year?
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?
That’s also not possible in “skilled” hands. My output is roughly the same. It does the scaffolding, but I need to rewrite almost every line, because it introduces footguns around that often. And before I had about 20000 LOC it failed even with scaffolding, ie architecture. And it wasn’t taste, just footguns all around, architecture ones. Nowadays for example still introduce mutability or completely unnecessary complexity where it shouldn’t, even when the example code which does almost the same is pristine. Many times it’s like StackOverflow, when a question doesn’t need 90% of the accepted answer, but people happily copy it brainlessly.
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.
> 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.
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 can believe that the difference between the slowest programmer in the world and the fastest AI aided programmer in the world is now 100x in terms of lines of code output. Like I can imagine a programmer writing 250 lines of code per week by hand and I can imagine an AI powered person writing 25,000 lines of code per week.
But we spent decades as an industry trying to dispel of the notion that SLOC/KLOC does not matter.
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).
>and I can imagine an AI powered person writing 25,000 lines of code per week.
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?
Well, as a thought experiment, I'd say that depends on if the measure is "1.3M lines of production code" or "1.3M lines of code (test code, comments and production code combined)".
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.
I'm not say it's pure hype. Not in the sense of previous hype waves like the metaverse or NFCs. It clearly has uses.
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.
> And definitely behind closed doors across companies.
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.
> 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.
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.
It always seemed like a weird default to let people (esp strangers) submit PRs that weren't tied to an issue nor approved.
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.
I think it was different pre-AI. Someone might come in and spend days getting some understanding of the codebase before they contribute some minor fix. Over time they might stick around a make some more of these, progressively gaining trust so when they do take on something bigger the maintainers will know they aren't wasting their time reviewing it.
Now they can drop a multi thousand line poorly understood PR day 1.
As someone who maintained FOSS libraries pre-AI, I think the frequency might have changed, but large drive-by PRs with thousands of changes happened before too, I've been on the receiving end of those many times. Usually they fundamentally change the architecture too, then the submitter get offended/sad/surprised when you tell them you impossibly could accept it and they should stop wasting their time contributing without discussing first. Usually ends with some threats how their fork will take all the contributors or something like that.
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.
Good faith PRs were also suffering under the current model. Ive opened PRs by hand on small projects to try and fix personal issues that probably affected others. Then the PRs languish for months or in one case literal years under the deluge of ai slop being spammed at the repo. I’m not going to ping the maintainers constantly when I know they are struggling so I’m left running my fork and no one else gets the benefit.
Big projects pre-AI also can have hundreds of rotting PRs. It's a lot of work to go through them, and unsolicited PRs are kind of the wrong way to spend time as a maintainer.
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?
First off, to have conflicting feelings about something is really normal and doesn't immediately point to a problem, it's extremely human, and I feel similar to you to. I'm a creative + programmer, I hate to see what's happening in some communities yet I too use agents for development, it'd be like avoiding Google + SO when they first appeared, feels like there is a clear "before/after" moments with those, and with LLMs as well.
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, very genuinely, highly recommend reading the Wikipedia page about the Luddites if you feel confused. This is a class consciousness problem. People feel conflicted because they know they aren't acting in their own best interests when they use generative AI (i.e. it does not lead us, as a society, to a good place -- mainly due to our bought-out legislature).
Again, I don't think there is any universal truths here, no correct nor incorrect answers, it's all very subjective. For example, I'm conflicted about the thing as a whole, but also I wouldn't say "Usage of generative AI for sure leads society to a worse place" like you just implied, that's too absolute for me and not something I'd agree with, and it wouldn't resolve the conflicts we're talking about here.
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.
> that's not the situation nor the feeling everywhere in the world, certainly not where I live
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.
> 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?
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.
> Trusting the legislative branch of my government is different from "so you think it'll work out well for everyone then huh?", btw.
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.
I feel like you're trying to move this conversation in a direction of discussing policy, while the context are individuals, their emotions and how they feel about things, that's how the conversation started. I never talked about how much I trust/distrust my government, all I said was that I trust the legislative branch, as parent commentator said they didn't trust their legislative branch. How much I distrust/trust my government at large is hardly on topic here, I also don't think because one (large) country been bought out, doesn't mean the entire world goes to shit, nor do I assume that everything everywhere will work out simply because I'm admitting that I too am conflicted, even though I too use AI-tooling, even though I'm a creative that like manual crafted things, even though I trust the legislative branch of my government.
We can also take some refuge in things like steam engines or electricity or the internet and how if you're just on the cusp of those you'd have similar feelings, but many years later here we are, still with jobs and meaning. A lot of people say this time is different but I guess when electricy showed up people would've said the same? I certainly remember people predicting that Manhattan would stop existing during the dotcom bubble because the internet would kill all street level businesses and people would work from wherever so big cities were over. And here we are.
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.
> A lot of people say this time is different but I guess when electricy showed up people would've said the same?
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.
> 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.
It certainly didn’t kill Manhattan, but it did kill or at least seriously maim lots of small towns. We lost a lot of local culture in the switch to everything being available online. I’m not sure we’re better off.
You can stop at any time. It's an unfortunate reality that many will not pay much mind as long as it's other people who are being harmed, but why support something morally and financially when it's now destroying something you personally care about?
It doesn’t help to know that using and supporting private LLMs is only making openai/anthropic/google/etc even richer. I myself cannot justify its usage.
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 ?
Every like to an AI-generated work is (literally!) one more data point in support of record labels dropping human artists for AI artists that will do what they want, perform where they want, and give all of their profits back to the label.
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.
Perhaps knowing a human with talent worked on it, putting some small part of themselves and their lived experience into the music has value to them? If so, then their actions make complete sense.
Human created music might have value to them, but it doesn't mean that the AI song was valueless. They admit they enjoyed it. So it doesn't make sense in terms of it not having value.
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.
It's not asinine at all. Context matters in art. Otherwise, more songs exist that I would probably really like than I will ever hear, so I'm going to focus on the human-made ones. Besides, part of the joy of music extends beyond listening. For many people, myself included, if we feel really connected to a song we like to learn about the people who created it.
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.
"I was afraid" .. "hurt a lot" .. "I hope that" .. "that feels" .. "I'm conflicted" .. "I'm confused" .. "I'm afraid" .. "human touch" .. "I liked" .. "I feel so stupid".
Maybe, just maybe, you're not thinking rationally/logically about the situation and instead are mostly operating on emotion and feelings?
The core of the human experience is to react to emotions. There’s nothing without emotions. Even if you feel like you can numb yourself to look at everything objectively, those “objective” “rational” thoughts are still based on feelings and inklings about what you trust and which facts you believe through chains of sources and anecdotes. There’s no such thing as operating without emotion.
What are you talking about? There was nothing irrational or illogical about what he said. The fact that he balanced his (well thought-out) opinion with emotion does not make it instantly irrational.
Reading this leaves a weird taste in my mouth, since the author tends to regularly make nontrivial >1k LOC PRs (sometimes several per day) and merge them on the same day with no reviews at all. This is even ignoring the LLM aspect; I don't know what % of them are assisted, but even if it was 0%, this isn't the pace of development I'd be comfortable with.
That's entirely consistent with what they said here:
> 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.
That's the philosophical argument. In practice, though, the effect of large unreviewed AI commits on the project and its users is likely to be the same regardless of whether those commits were prompted by a core developer or an outside contributor.
I don't buy that at all. A core developer producing a thousand line commit that they'll be responsible for over the remaining lifetime of the project is entirely different from a fire-and-forget PR from an outside contributor.
Yes, I have lost faith in some open source project maintainers that are doing this. There is an open source platform we've used for years at work (we use the paid Enterprise version of it) that introduced some pretty grotesque security flaws and when I looked into it I realized AI had taken over the project - you can clearly see it in the commit log whether it is attributed or not, just based on volume and frequency. It was very disappointing.
LLMs might be part of why Ladybird is making this decision, but they aren’t the only possible one: SQLite, for example, has been developed this way pretty much forever. To each their own, I guess.
Yeah I don't see the big deal here. Some of the best software is made and maintained by a very small group of dedicated folks. It's a perfectly reasonable move to protect their time and project.
I am old enough to remember what happened to GCC. It was also developed by a closed group of maintainers, because "it couldn't work" as a bazaar-style development. Then EGCS fork happened and became more successful.
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 two months ago ladybird announced that they were leveraging llms to do the rewrite that had been languishing for a year.
Now, "it breaks the social contract." Alright buddy.
This is part of the insane overreaction rippling through various communities.
The folks who figure out how to do it successfully will succeed. Groups that recede into what they know will either be slow to adapt or end up forming modern old order Mennonite groups.
Which, it's fine no judgement. But those groups don't represent technical / human progress. They represent recalcitrance in the face of a changing culture/world/society.
The rust conversion was a byte-for-byte replica of the original's bytecode, was it not? Thereby it was easily possible to validate the quality of the AI-based work. The same would obviously not be possible for patches. I don't believe you can use the rust conversion as a valid, if implied, argument that you can take AI-patches in good faith.
My implied argument is not so much that "because llm was used, then llm must be used."
The original argument proposed by the author is essentially distilled into, "because llm could be used, we must no longer accept public contributions."
Which is, in my opinion, a disproportional and misguided overreaction. The llm was apparently good enough to do the byte for byte replica, so we know that it can be used (within the context of ladybird) in a way that's apparently acceptable to the maintainers.
To attempt to get more precise, argument is that "closing the gates" is moving in the wrong direction against progress, and a signals a potentially net negative impact to the ladybird project.
I don't have a fully formed thesis, it's a lot of vibes. It just feels wrong. I'm willing to acknowledge that, much like the overreaction that I'm calling out, I could be experiencing a similar kind of conservative gut reaction to the changing of the open source community that unsettles me.
Well see how it all shakes out. Right now the topic is so charged and we don't have a good suite of tools and heuristics for the new world, that were bound to see the gamut of reactions.
Very confusing statement. It is definitely true that OSS is on the verge of a crisis because of AI agents, but they clearly said AI is not the reason to reject external contributors: "Whether code was typed by hand is beside the point."
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.
It saddens me to see the communities surrounding free software projects going dark because of the threat posed by AI tools, but I don't know what other solutions there are that would mitigate the threat, particularly when browsers are such a compelling target. Perhaps some kind of trust system a la arxiv.org, where existing users have to vouch for new submissions before a user is themselves trusted? Definitely still vulnerable to abuse, but perhaps less so.
Closed-source projects have been dealing with this forever, by having a mostly-static pool of employees replenished through job listings and interviews. A FLOSS project adopting this model would certainly feel weird, but could work if there were enough willing candidates. The question is, who will take on effectively a job without the monetary reward?
My understanding is that the people working on ladybird are compensated for their full time positions, so I would also expect any future positions to be similar.
Wasn't the entire goal of Ladybird to have an open and independent browser engine? Making it effectively closed to contributions makes it.. Not independent anymore. It's now dependent, on few people who work on it, just like any other closed-source or corporate-controlled browser.
I don’t think that changes the project independence, when a project is open to PRs you have the same dependency on maintainers accepting changes into main. And the project is still open source. But that does make it less community oriented
But opensource has always been about community. This way it becomes "source-open", even if you could make changes to it and run those changes yourself, the latter doesn't sound "opensourcy" to me.
Open source is about rights/freedom, the community aspect is downstream from that. You have “source available” projects with active communities and external contributors (see elastic license v2.0 projects), and open source projects that only rely on core developers. With open source freedoms comes a culture of community oriented development but what makes a project open is the license, nothing else. The right to fork, read, run, edit is what matters.
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
The open source definition does not mention community at all - it is a set of licensing requirements that certain rights to modify code must be maintained, not that upstream will accept your change or (for that matter) that you need to package it up and hand it to them.
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.
It is still independent in sense that it doesn't depend on Google Search money and Chrome/Firefox code as most of the alternative browsers. Depending on your definition of dependency, it will always going to be dependent on something.
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.
This feels like a new phase for open source. I think screening people to join development efforts will become the norm, at least for resource-constrained projects. Trust will have to be earned.
I'd argue that was what made Serenity good - a toy OS that anyone can code anything for. Want to spend ages working on a painting program? Make screensavers? Add drivers for your printer? Port Doom? Improve font support because it sounds fun? etc. It celebrated coding for coding's sake, which is the antithesis of AI. There's no point vibe coding features for Serenity because there is no real product there.
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.
They are adopting Rust (https://ladybird.org/posts/adopting-rust/) and use LLMs to help with the rewrite, but not all code was migrated yet. Also it's definitely not a big-bang-rewrite-the-world-with-Claude like Bun.
This seems quite misguided and is sad to see. They have every right to do this, but I was looking forward to continuing testing Ladybird as it improves and contributing in the future. I hope servo stays open to contributions, as it seems like it's all we have left.
It makes sense when you have a somewhat fixed core team size. Frankly, in some regards, this is the responsible thing to do.
It means they’ll never grow modules or the codebase beyond what the team can reasonably maintain.
However on the other hand.. What does this mean for the existing team, are maintainers now worth considerably more to the project? What does this mean for the codebase, or the momentum of the project?
It’s an approach I would have expected for the likes of curl, or single-purpose libraries. But this is a mammoth decision for a mammoth project.
I manage multiple open source Github enterprises for the Linux Foundation. Something like this is under discussion in all of them - the amount of terrible PRs and issues being filed is overwhelming.
Having read the blog post and then the comments here, I'm rather astonished. Do we understand our craft so little that our only realistic option is to ban LLMs (so-called AI)? Has everyone forgotten we've been in a software crisis for almost sixty years?[0] Have we so internalized the sweat-of-the-brow we've accumulated for decades that it's now part of the identity of being a programmer, and the only reliable signal of whether a contribution is beneficial?
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.
I believe the development world has a few cultural issues that make it hard to focus on the issues at hand. As a group we tend to not see the forest for the trees which causes us to worry about microscopic details while ignoring overwhelmingly more important realities, like, say, economics, lack of proper communication, team alignment, power hierarchies, etc. Being male-dominated has also not helped us for as far as I can tell the field, like many others, is dominated by power play, ego and identity issues. Everyone is trying to prove to everyone else how clever they are instead of cooperating properly. I can count on one hand the programmers I met that are actually humble and not just humble bragging. I myself am guilty of this arrogance.
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.
It's inevitable that more projects follow this path.
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.
Crappy timing for me. Ladybird has never built on musl based systems. I got that working just a couple of days ago (on Chimera Linux) and was hoping to push the changes to the project. I guess I am maintaining that myself now.
> hoping to push the changes to the project. I guess I am maintaining that myself now.
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.
Linux has WAY more maintainers, and many of them just reviewed other people's commits for years. They had a crazy amount of contributions even before AI.
I think we're past beginning to warn, we've now reached the point of accepting Linux needs to remove drivers and features, because the maintainers just can't keep up.
This is not helped by everyone using the same LLMs to find the same vulnerabilities and flooding maintainers with duplicate reports to be the first to get that CVE and branded vuln on their resume.
There are numerous advantages of microkernels over monoliths, but even if Linux were a microkernel it wouldn't necessarily change the review pressure that the above commenter is talking about, because you still have the same number of components (filesystem, networking, drivers, etc) to develop and review patches for (although you do have more well-defined interfaces between components, which eases security).
Not really - it changes how the lines are drawn between components, rather than removing any of them.
The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.
The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.
Behind my question was another one: is there too much in the source tree that doesn't _strictly_ need to be?
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.
> 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.
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
Open source has nothing to do with the right to contribute upstream. It's about you being able to use the software how you like and make changes to it and redistribute it.
> We usually call open source software without open collaboration source available software.
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.
Hell no, open source is just about the licence, and source available generally refers to proprietary licenses that at least let customers access the source.
This is just the cathedral model to open source, as opposed to the bazaar you clearly prefer, but it's still open source.
They could make two kinds of pull requests and add much more strict criteria for public contributions. For example, they could say that the PR has to be smaller in size and well-documented for human review, otherwise it's closed by an automation.
And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to get it in.
Blocking public contributions means that they want to have complete control of the project and AI is likely a good excuse to do that.
That doesn't solve the volume or quality problem. LLMs can split one giant PR into 50 smaller PRs just as easily and "well-documented" isn't something you can determine automatically.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
It says something about the fragility of contemporary software that a fragment of bad code could result in doom. I think we need to move to much more restrictive computation architectures, inherently partitioned, functionally pure, and resistant to type confusion, pointer manipulation, memory issues etc.
I don't disagree with the desire for more inherently secure architectures, but I don't think it's the most relevant issue here.
You're always going to have to trust some core same-privilege code--a browser renderer is a great example of this: it has to be able to see the entirety of the DOM it's rendering, right?
Higher-level languages can still help code review--for example, memory safety makes it harder to hide a backdoor via unsafe memory operations leading to code injection. But you're still, fundamentally, trusting these community contributions.
I think the real problem (as others noted here) is that:
- writing code is now much, much cheaper than ever
- understanding and designing code is still fairly expensive
So doing the former (in the form of a PR that compiles and passes CI) is not a good "staking mechanism" to prove someone has done the latter.
The core problem is that we don't have a PR respect system. 10kLOC from an unfamiliar person with empty GitHub is much different from a pal regularly contributing that you personally know.
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.
Encourage forks and wait for actual experienced, committed maintainers of the fork to emerge I suppose is the way. In essence the maintainers are saying the path to trusted contributor and then to maintainer via outside unsolicited pull requests is less useful because the signals of a committed person in that path have become less useful.
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.
There is, it’s being able to tell bullshit from actual cosplayers.
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.
I'm not sure. I didn't think about this seriously in an adversarial context.
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 don't like this, but I understand it.
I've contributed to the LB project several times, and I have made friends IRL with people who have also contributed to the project. ( we are now friends at uni )
It feels like a stepback because instead of 30-45 contributors every month, you have 15...
i feel like there should be a way to trust a PR ID verification or in-person verification at FOSDEM/DEFCON/Chaos Communication Congress,UNI's, for example.
> 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.
As much as I wanted to see another browser alternative succeed, Ladybird has lost my trust. Using LLMs to rewrite the entire codebase was already extreme. But eliminating external contributors is a precursor to a rug pull. And rewriting the entire codebase can now be seen as another step in a rug pull.
I do wish they had left a window open for criteria to whitelist developers who can create PRs. By closing off their developer circle, they are losing the best parts of open-source - new software developers eager to solve large problems with novel approaches.
So basically it will become more or less similar to the structure for SQlite and Fossil by Dr.Richar Hipp et al , basically seems most projects that have the requisite manpower/maturity will end up at that kind of structure.
In the long run may be interesting from a chain of trust (human as well as code) and interop as any dev from these projects (guilds?) would already have some trust build in.
Perhaps we should start to describe projects as Open Contributions from now on. With maybe a few Open Contributions Standards to distinguish how this works.
Interesting how this post coincides with the Leyden declaration in mathematics: both documents are abot
how human-human trust ("in good faith") is eroded by
large language models, because a substantially-sized
artifact does not necessarily attest to substantial
human effort and skills.
Good point about how the community of mathematicians is struggling to come to terms with the role of language models in their work, and the similarity with the community of software developers. Machine-generated programs and proofs are contributing real value, undeniably, but it's causing social tension and destablizing the community with the sheer volume of its production, the varying quality, unreliability, and lack of humanity in the process. I would guess that similar issues will spread throughout society, in other areas of collective work and living. One potential solution, like with Ladybird and some other open source projects, is for a community to become more exclusive, restrictive and selective about what inputs they accept.
this is a move in wrong direction, its sad and a bad solution. Ladybird implements specs that must be compliant, making compliance harder is the way to go, proving the code changes does what they are intended for should be made better instead of gate keeping from malicious and "honest" contributors
I think it's not the issue with the added PR count, but the fact they have to review them. 1 big PR review is the same as 5 small PR reviews if you have to look at how it holds, edge cases and what not...
Well, then add some backpressure. Each contributor gets only a few small PRs a month, until they prove themselves. Contributors that don't have a credible online presence are automatically rejected. Etc
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.
> 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.
This is not really a valid criticism for an Open Source project. I built Ladybird from source yesterday and I am typing this comment in it now. So, I assure you that the Ladybird browser exists.
Of course, Ladybird is not production ready yet. Feature-wise, it is getting close. I can use it to do most of the things I want to do with a browser. Speed and reliability are another matter. I has gotten dramatically faster but normal users would still find it slow. But the biggest problem is reliability. I would not use it in its current form for anything that matters.
But for a complicated application that was started from scratch, not being ready yet is not an indictment. They claim it will be ready for regular users to try sometime this year and, from where I type, this seems realistic.
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.
For an open source project, is there any reason to still accept code contributions?
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 the same reason software engineers still employed. AI is not yet capable of autonomous software development. From my perspective we're nowhere close.
Ladybird going source-available is quite unfortunate, seems like Gecko is the only production-ready independent browser engine we're left with.
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.
That's not source-available, that's still open-source. Quoting Wikipedia:
> 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.
> 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.
It's not source available, source available implies some restrictions on what you can do with the source, or with any resulting binaries. This isn't a rugpull; all they're doing is closing off contributions, which has nothing to do with the license of the code.
I once submitted a PR to Ladybird, but even in early AI days there were so many open PRs that mine got lost in the noise. I don't really blame the maintainers here. Once the open PRs get to a certain point, it becomes unmanageable.
Maybe, or maybe not. But it will certainly kill the community they've built up, and squander a huge amount of goodwill. Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that nobody can contribute to? Not to mention how the sponsors might feel about this.
> Moving to a closed development model => opensource is just a gimmick,
How so? Many projects are open source (GPL, MIT, whatever) while closed development, and no one calls those a gimmick.
In any case, most open-source is going to move towards a closed-development model; there simply isn't the resources to review thousands of lines of PRs per hour.
Too early to say. Once they enter "we now accept everyone to use Ladybird as daily driver" then there will be the real test phase. And, IMO, only after that phase has started and continued for some months, perhaps even few years, can a final conclusion be made. If ladybird fails then the Google empire has won permanently. Skynet slop will then be under control of Google, just as they stole all the advertisement money.
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.
But that's a bit backwards. RMS would emphatically agree that Free Software doesn't mean being open to contributions; if you asked him about either "FOSS" or "Open Source" he'd probably command you to wash your mouth out with soap. It's the other side of the fighting FOSS family which evangelised for Linux-like development (see the thread from https://news.ycombinator.com/item?id=48410503 ).
I wonder, if they are really only concerned about trust, will accepting external PRs but never giving commit access to external contributors work for them?
Of course, if they are also concerned about the quality of external PRs then that does not help.
Indeed, while there is communication that the situation with merging external pull requests should improve, the reality is that it's easier to land a patch in Linux, than in Zig.
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.
> More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days
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.
Is your point that Anthropic is now accepting code submissions to Opus 5.0 from “millions of contributors”? No?
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.
> 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.
It would be free labour! Truly crowd-funded development.
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!
Just donate your tokens to the project. The actual team that’s actually leading the project can direct the prompts better and evaluate the LLM-generated code better for their project than random drive-by contributors can. That’s the whole point of their announcement.
It sounds like all public contribution will simply be impossible. That said, they will continue to develop out in the open on GitHub and you can clone the repo and build whenever you want. You can continue to contribute in other ways.
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.
curious what the "did the pipeline actually do what we think" story
looks like now.
"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.
It's surprising to me how many people here seem offended that someone might just not want their code.
I guess it takes quite a lot of experience as a maintainer to realize that 'free' in 'free code contributions by strangers' is like 'free' in 'free puppy'.
What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway. Ladybird is not SQLite, it's under development and very likely will be forever. To me it looks like they are transitioning into a company, where this model makes sense.
Surprising how little appetite for changing norms exists here on HN. Yes, the transition to agentic coding will be difficult, but to me this is mostly exciting. Despite my AI enthusiasm, I also run into shortcomings that the agents have very often, but that's a more interesting learning experience than the status quo without AI would have been!
We'll have more such disruptions and we'll learn to live with it.
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.
Some authors and UX designers to give away at least part of their work for free.
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.
It's not the only solution but it might reduce PRs by a decent amount I would think.
If you see a PR and the guy is verified, you can check his name, his linkedin and where he works, at least there is some accountability if he introduces malicious code.
If the goal is to reduce slop, define slop. As a maintainer of a project you should be able to tell if something is slop.
If you don't have time to read PRs (which is the real issue here) that's fine too.
My guess is they want to reduce the amount of PRs, and ensure that the quality of the PRs passes an extremely high bar.
While it would help for some use-cases, it wouldn't necessarily reduce the problem that a browser is facing when dealing with malicious code in a large and complex codebase. And vetted people can be victims of supply-chain attacks, which makes it still hard to evaluate a change properly.
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.
I suspect that rather than some kind of digital proof-of-competence, communities will shift to in-person meetups at conferences and such. Which is unfortunate for people who can't attend for whatever reason, but I think some solution to that can be worked out.
I been thinking about it for a while that we need some score based system where each PR on GitHub/Gitlab grants you a review form the maintainer as well. You build your rep and the maintainers decide about the thresholds for contribution.
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.
I wonder how can a new browser engine survive with the source available model. Like, why would anyone support this, unless they have business association with the Ladybird developers?
It's not source available. It's OpenSource(TM) because of the BSD-2 license.
This is not unheard of. The most famous models are emacs & SQLite. SQLite doesn't accept outside patches, emacs is developed opaquely and only releases are put forward.
You can do this with GPL, too. You put out tarballs of the releases only.
There's a great misconception between Free Software, Open Source, and Open Development (bazaar model). They complement each other, but they are completely independent things.
Addenda: Looks like emacs' Git repo is publicly accessible now, but it's not a requirement for GPL or Free or Open Source software.
It's actually common, many companies develop their products this way. The source is available, you can see the VCS, but you can't participate in the development. That's why I see this as signal that it's going to turn into a company.
However many if not most of these companies use "Source Available" licenses which say "Thou shall look, thou shan't compile". This is very different than Open Source license of Ladybird itself.
I truly understand why this step was taken, but it is still sad to see the death of open source or rather open contribution. Every project that turns away from open contributions is a project lost to the whims and fuckery of AI Bros.
What I realy want to know how sustainable a model like this is. How does one find new maintainers when old ones leave. When you cannot contribute anymore.
The cause of this is that the cost of creating plausible code contributions has gone down, so PR proposals can multiply, but flaws still threaten project security and LLMs can be confidently wrong. So human review is needed right now to maintain the integrity of the project, but it takes time and costs money. Ladybird's developers, and we as a community, can't easily evaluate "this is what we want" vs. "this is not what we want" without manual review, because we haven't settled upon a reliable representation of the meaning of our code and its side effects that is time-efficient, secure, and meaningfully interpretable at scale.
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).
> Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project.
WebKit does allow outside contributions, though that example is perhaps not the most illustrative as it is from an Igalia employee. Igalia maintains substantial parts of WebKit and at this point has to be the #2 contributor other than Apple themselves.
That's not really right, though the license is still Open Source compliant. Linux was practising an open, patches-welcome developement style before the forges existed, on its mailing list. This did indeed contrast with how eg. the FSF was running its projects, though even in those the door wasn't shut as hard on people wanting to contribute as Ladybird's now is, I think. Then Eric Raymond wrote "The Cathedral and the Bazaar" specifically to talk up Linux's patches-welcome development model, and to move the emphasis away from (just) licensing terms and source accessibility, to openness to patches. Netscape then launched the Mozilla Project specifically on the CatB model. In response to the surge of momentum, the "Open Source" label was created basically as a brand name for the CatB perspective. After all this, "doing it as open source" was established as a clear mental category in people's heads, and the forges popped up as low-friction SaaS solutions for something that people already wanted to do, and by then were often already doing. (In the process helping to make Web-based SaaS a well-established concept and business model in people's heads, something with ironic consequences.) So Ladybird's current development model is much more clearly in line with the Free Software philosophy than the Open Source philosophy. To be clear, that's not the only disagreement or difference of emphasis between "Free Software" and "Open Source": most obvioulsy, Ladybird's BSD license is a failing in the FSF's view of things, just not enough of a failing make Ladybird not Free Software. But it is a real one.
"The Cathedral and Bazaar" is orthogonal to open source. Its argument is that open source is most valuable when paired with the bazaar model, not that the cathedral model cannot be considered open.
The open source definition was created in that mind. It does not state or imply open development or a community are requirements.
CatB and Open Source aren't coaxial, but there wasn't a very clean separation between them either: https://www.free-soft.org/literature/papers/esr/cathedral-ba...https://web.archive.org/web/20021001164015/http://www.openso... . "[T]he same pragmatic, business-case grounds that motivated Netscape" was CatB. Even now OSI doesn't emphasise any separation: https://opensource.org/about . You are correct: the Open Source Definition does not mandate an open development model. However that's probably at least in a small part because, well, how would one craft a legal requirement for open development in a software license that wasn't either unenforceable or very burdensome and abusable? It's also quite definitely because the expectation was that forks and/or the threat of forks would in practice enforce a certain level of open development on OSD-compatibly-licensed software: this was in fact what ended up happening to GCC at least once https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_f... . If software projects all largely go the way Ladybird is going now, and stay that way, then it's a crushing (though not total) defeat for what the Open Source movement promoted and what it hoped to achieve; but sure, to be clear, Ladybird remains OSD-compliant. (Not total because at least the source remains available, without paying or signing anything, for bug-hunting.)
I think I didn't put the emphasis right in my comment above. The code is still fully open source, but the project that produces the code isn't. It's not dissimilar to other projects producing open source software.
This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.
AI contributions are only a part of the issue. Another part is where a contributor decides they want a specific feature and contributes it but then disappears off into the sunset when it comes to needing maintenance later.
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.
A bit sad to see this. Of course they are free to do it the way they prefer, and there are successful projects like this (Notably SQLite) but there has to be a reasonable middle ground between "everyone can just flood us with 30,000-line 'Claude implement feature X make no mistakes' PRs" and "we're not open to outside contributions"
How would you decide what is the middle ground though? If a project allows some AI-generated PR if its good quality, then it is a burden on the reviewer on what is considered good or not.
You can introduce a social/trust element to it, something like: Join our Discord, chat to us, come to our "office hours" video calls first, then you get to contribute.
Maybe also limit the size/scope of external contributions (only small bug fixes allowed for your first few PRs)
While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
> Now opensource will become a thing that only "influential" people can contribute to.
No. Having access to a slop generator doesn't entitle you to acceptance to any and all open source projects. You're still responsible for the quality of your contributions. Something that is completely lost on bullshit artists.
Don't put words in my ~mouth~ (keyboard) that I didn't ~say~ (type), I'm not saying I want my contributions to be accepted on equal footing even if they are generated by AI. What I'm saying is that solving this problem this way is going to make opensource much worse. We need a better way, and I'm not sure which is the better way, sorry.
Your prior message could be taken that this was an elitist move, and not a move that is being taken by many different projects for survival with limited review capacity.
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.
You aren't really contributing anything except funding to Anthropic/oai/MS/etc if you're sending genAI content. The better way will be fairly similar to the previous status quo: humans interacting with humans, with the change that there will be higher barriers to gaining access to the web of trust.
> You aren't really contributing anything except funding to Anthropic/oai/MS/etc if you're sending genAI content.
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.
Opensource is already much worse and is drowning in slop. Until a better way is found (if it can be found), severely restricting contributions is the only sane response.
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 don't know about you, but as for me, when I contribute to opensource it's because I find some improvement that makes the project better because it probably polishes some rough edge around a kind-of particular use case (that maybe few people face, but still, it makes the project better for them; it amplifies the range of usecases that it can span to). If everybody does the same with their small improvements, the project becomes better for everyone, but none of the contributors of these small changes would have time to embark on maintaining a fork. Mantaining a fork is hard work, not only because software breaks over time (dependencies going obsolete or insecure, builds stop working because of old toolkits), but also because not pulling the latest changes from master would mean that your fork gets stagnated (and thus not worth to run it).
it's fair, especially because if people want to contribute to something so badly, they can make their own fork or version of it
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
I wasn’t around much before GitHub so. I believe I tried submitting patches to the XFCE project but I didn’t get anything accepted to FOSS before GitHub.
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?
> 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.
Applies so, so widely. Glad they’re taking (very necessary) action here.
I paid for Kagi's Orion (even though it's actually a little crappy) because I want options in the browser landscape. I'm really rooting for Ladybird, and just in case they don't offer a paid version in the future, here's a link to how you can sponsor its development: https://opencollective.com/ladybird
I want someone to resolve the contradiction you have highlighted. Why don’t we now have an AI built web browser that is much better faster than chrome?
To that mind, why hasn’t chrome itself become 1000x better?
There is a disconnect between the narrative and reality.
> 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.
The Zig project is making a real difference in the culture of open source software. I'm so glad for the leadership and community. It's a refuge from the mania of large language models disrupting this and other industries, steamrolling over human connection, decency, ingenuity, class, taste. These intangible qualities that make it worthwhile, joyous and fun, will be destroyed unless people put in effort to protect them.
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.
>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.
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]
Oh well, AI bros ruined it. I'm actually glad in some twisted way, because if more projects follow suit and close their development, it will again become an actual badge of honor to get on those teams. Having contributed to such projects will mean something.
"A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it."
Cool - how about fewer perma-bans on github for participating in discussions?
Also, as I have pointed out before, they seem to develop too slowly for a solid beta this year. You only have to look at the issue tracker and check for URLs not working or even crashing the browser. Ladybird may have gotten better in the last months, but imagine if 50.000 people are using it, you will see more bugs. How do they then handle bug reports?
Seems cold how they present this, but on the other hand I’ve ignored Ladybird because I just don’t think they’ll have meaningful impact, so I remain unaffected by this policy change.
I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful.
It's kinda surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort.
In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a post-ai world. They were always out of line & continue to be.
Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from, say, someone cargo-culting code from tutorials.
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 see AI as a barrier remover. Unfortunately some barriers are good or minimally necessary.
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.
This is entirely too much friction in the wrong place. Public open source will simply die before a system like that ever becomes the norm.
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.
I don't disagree, where is the right place for the friction?
A couple of alternatives are:
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
I agree with the bond in theory, but that would entirely stop contributions from people in economies where a shady maintainer could keep their code, and their weekly food budget.
We already have trouble with people maintaining open source projects without getting paid, now you want people to pay for the privilege to participate in free work?
It's a bond not a fee. If the maintainer feels that it's spam, they keep the bond. If they feel like it's not, they leave it.
That sounds like a massive headache for maintainers and opportunity for people to cry foul. That gets messy so fast.
Or create pull requests and earn crypto!
https://gitearn.vercel.app/
https://gitreward.com/
But your company employs said individual, whereas arbitrary drive-by patches from randos on open source projects with no consequence of submitting a mountain of garbage.
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.
just to clarify:
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.
yes. github has very minimal controls for PRs (either shut them off completely, or not at all) but through GH webhooks you can essentially script "auto-close" of PRs that dont have correct preliminary approval.
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.
> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
It is 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.
Man, you must hate those handymen who put up YouTube videos showing how to do basic home maintenance. A truly class-conscious handyman would insist that the homeowner hire them to replace a light switch.
How this is equivalent at all? The proper equivalence would be "You should be happy a random passerby decided to re-wire your home after watching a youtube tutorial and thank him accordingly".
There certainly exists a class of electricians who believe that homeowners shouldn't be changing a light switch, and jurisdictions exist where a permit is required to do so.
Come on, are you really going to strawman "engineering should be inherently disqualifying" into "so people shouldn't DIY in their own home"? Please try a little bit harder.
I’m not strawmanning anything. I’m pointing out what I believe to be ridiculous gatekeeping. Software engineering isn’t some holy magic that must be kept from the masses.
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.
Alright, I guess I'll take the bait. Not much else going on today anyway.
> 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.
Your initial post on class solidarity was extremely reasonable (even if I disagreed with it - see my comment above) but to follow it up with a post describing castes in a non-negative light is wild.
In hindsight, the word "caste" is too heavily loaded and I should have chosen a different term. Sorry for the shit choice.
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".
> 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.
I consider this mode of thinking selfish and anti-progress. It’s pretty much exactly what Americans decry about unions.
> 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 support workers being compensated for their value; what I dislike are protectionism and ossification.
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.
You're throwing around the term "ossification" like it's a guarantee or necessity tied to anything being discussed here, and that's just not the case.
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.
I’ll be blunt and say you certainly sounds like someone “post money” talking if castes and such. Glad you got your nut and do not care how it shakes out.
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.
> Glad you got your nut and do not care how it shakes out.
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.
Assuming you're being genuine (which I have a hard time believing because your argument is quite literally a strawman, please read the definition), you're missing the context entirely. You can't conflate small DIY projects done around the house with developing software that thousands of people and institutions rely on. By all means you can go and watch a video on software development, but that does not entitle you to expect that PRs you make will be accepted to any project other than the ones you control yourself.
Please re-read the specific comment I replied to. It was someone expressing indignation that a software engineer would accept “high-quality” PRs from a non-software engineer, accusing the poster of lacking “class consciousness.”
"You can't conflate small DIY projects done around the house with developing software that thousands of people and institutions rely on. "
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, "
> hard for me to imagine another engineering discipline....
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?
> 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.
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.
> 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
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.
happens all the time. Some business jerk outsources an entire initiative, forces it through review, and we get dumped with externally written crap we gotta deal with. So what if claude wrote it, actually claude is better than money wasted on those outsourced piles of crap projects
Ooof. This is a big topic - I understand where you're coming from, but it's a common sentiment & one I've recently come to disagree more & more with.
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.
> It's in no way specific to software engineering as a role nor to high salary positions.
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 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.
> 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)
On this topic, "Open-Source Isn't About You": https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Gratitude was maybe the wrong word. As the article mentions, before ai I think larger PRs, while sometimes inconsiderate, at least implied some amount of care / effort / good faith. In my experience, that was often rewarded with the maintainers at least taking a look at the code. I meant it's odd to have the same expectation when you dump 3000 lines in a pr that you won't even personally write a description for.
There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs.
It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.
It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.
I've experienced the following sequence more than once at work, and I remain baffled by it each time:
- 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.
> 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.
That's every place :(
I agree it's not "entitlement" specifically but there's something there. I guess by now everyone has experienced that type of person that "tries to help" by copy/pasting a bunch of AI slop and expecting you to work through the cognitive load of validating it.
The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.
It was a proof of work system. When work becomes cheap, it stops being proof.
> 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
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.
If a project has a rule to not submit AI generated PRs, people should never submit AI generated PRs to that project. It's spam. Or if the rule is more nuanced than that in relation to AI, it should be respected.
It's 100% an issue with the people with submitting these PRs. So, if someone has a history of having no issue with breaking project rules (let alone being arrogant about it), it should be a massive red flag about the person for any possible employer or future collaborator checking their profile, etc.
Why people are wilfully destroying their own reputation like that is beyond me. It's infinitely better to have no activity at all on your profile than to create a track record of bad behaviour.
I can imagine in these cases the LLM is telling the "contributor" how smart they are and how much the project is loosing out, maybe saying something like: "It's not about maintaining project boundaries, it’s not about ensuring code quality; it’s a gatekeeping mechanism designed by traditionalists who feel threatened by forward-thinking creators like you who truly master the efficiency of AI."
Whether or not they are, I agree it is entirely possible to imagine them doing that, given what we know about how AI chat has reinforced people doing much worse to themselves and others.
(And the whole "miffed AI wrote a shitpost" thing)
I wouldn’t be surprised to find out this is part of their RHLF training, the attitude is so prevalent in these models.
really? in the way the parent comment describes? (genuine) i suppose i've never encountered a context where it would be relevant for an LLM to output that, interesting
> What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful.
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?
If I don’t word these critiques in the most diplomatic way possible, this immediately turns into a discussion about the prevalence of anti-ai sentiment on hn. Which would be boring.
Since Godot got mentioned, I thought this recent talk by Juan Linietsky provides a reasonable alternative to heavily restricting contribution.
https://youtu.be/LDSwP37y_W4?si=fMIsdQ2yjoiGChb6
What would be great is something like Pangram for PRs and issues. Detects if the PR or issue is AI-generated (with multiple checkers for redundancy) so that maintainers can choose to auto-close and PR authors have to at least manually write _something_ before they launch 20k SLOC diffs.
One could call a big lump of code a Tumor.
> They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
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.
> What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful.
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.
There massive value in AI PR's.
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.
It's interesting to see this perspective in the wild. In the age of AI I wonder what "massive value" your PR is bringing to the maintainer. $1 worth of tokens?
As explained: New features. Bugfixes. Better analysis.
Only stoneagers would say that they are better than a good AI.
I regularly find the code output of opus and gpt 5.5 to be garbage. Overly verbose, unnecessary abstractions, strange duplication of concepts across objects, unnecessary copying of objects and creation of objects. I have found its much more useful to just ping pong some ideas, have it generate helper methods, and do the code implementation by hand.
I guess I am a stoneager.
I think this is one of the grand realisations, and it is why local models are much, much more of a threat to the "metered intelligence as a global utility" business model.
As an AI-cynic I am much more interested in learning how AI solves my problems (of which I have many), not how it can revolutionise programming. How about it revolutionises me not experiencing task paralysis first.
This thread is in the context of community PRs in open source projects. So it's not about AI or not, it's about maintainers using AI vs random contributors using AI.
My point is that with AI, where the actual code generation is easy, there's little value in community PR contributions anymore.
Hmm. I've read that differently. Maybe you are right. So he is going the GNU/FSF direction avoiding the minefield of external contributions
not to throw this word around, but,
> Only stoneagers would say that they are better than a good AI.
projection? lack of confidence in your own abilities? why make such a sweeping statement
> Only stoneagers would say that they are better than a good AI.
I am only a bit above average and I clearly still write better code than a good AI.
The only question left in my mind, alas, is whether that is enough to earn a living.
I mean: it is clear that in every domain except for programming, a talented XYZer can do better than an appropriate LLM trained to do XYZ (except perhaps in some absolutely exhausting pattern recognition tasks).
So I am not sure why we see our own field as different. A sort of inverted Gell-Mann amnesia?
I mean, aren't you kind of proving the poster's point?
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.
Even before AI it was trivial to setup a continuous merge script. I did that several years for several projects which refused my PR's.
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.
The generalised form of this, which we are rapidly discovering, is that AI breaks the social contract that used to exist between an author and a reader (of prose, code, anything).
Precisely. In the case of OSS it makes no sense for maintainers to spend more time reviewing AI generated code than contributors spent prompt engineering it. That's just not helpful.
That's the most succinct way I have seen someone put it, thanks! It's really the same issue, no matter if it's software, online comments, e-mails, artworks, homework, etc. We engage because we expect to be interacting with the output of another human being. AI fundamentally betrays this expectation.
Yes, and there was a good post about exactly this social contract last week https://jola.dev/posts/the-social-contract-of-writing. I find the argument compelling on the face of it and true in my experience with colleagues and the broader digital landscape recently.
I wonder how many comments are from bots in this discussion. Few days ago there was a discussion of traffic stall at the strait of Hormuz on HN. One comment from an user with over 9000 Kama went like "I just checked the traffic on the road and it is normal ...". Unfortunately other bots are not as easy to spot as this one.
I agree, I suspect what Ladybird is doing here may become the normal social model for open source going forward.
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.
Yeah, that's well written and accurate. Hadn't thought about PR spam in those terms before but that does actually make a lot of sense.
On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.
On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
Open source development has become more and more superficial aligning with modern social network characteristics. It's more important to have an contribution, a active commit history, a few stars as a proof of pixel fame than the intrinsic value of the contributions or projects.
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.
Yes. Open source existed and thrived before GitHub, before git, and before anyone had ever used the words “pull request“.
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.
> I hope this spreads to all of the internet.
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.
World readable has become a liability as well. How many times has some random disagreement been blown up by observers and lead to people being kicked out of groups, jobs being lost, or SWAT raids?
I’m never getting accustomed to the fact that there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style (are people these days even aware of the metaphor or Raymond’s book?), a world in which the frigging Microsoft is a major OSS vendor and in charge of facilitating most of the open-source programming on the planet. Try explaining that to a time traveler from the late 90.
(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!)
> there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style
(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.)
I think that was a natural outcome of cheaper merges/conflict resolution in distributed version control. It became easier so there were more situations where it made sense.
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’m confused, when has “everything” been a bazaar, and when did that cease to be?
of course not literally 'everything', but as someone that grew up in a post-git world, with github as the 'default', to me projects that don't accept (or expect!) outside contributions have been the exception; definitely aware of notable examples (sqlite? some web servers, a few internal-libraries-that-outsiders-use?) but very much used to the bazaar
i think the claim is that more projects are locking up contribution paths ~currently
Umm, I missed a negation there, sorry. I meant that the newest generation has only seen a world where there's a giant OSS ecosystem and the bazaar style is the norm for all of your tool and library needs.
Okay that makes way more sense. It seems especially applicable to web frontend, where everything seems to have been developed out in the open.
> it will also make it more difficult to identify who to invite to join the priesthood
The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.
How many people will ask to be a "priest" and will then violate the rules around AI?
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.
There are great Open Source projects doing fine with the cathedral style, just look at Sqlite and its siblings (Fossil, …).
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
I still don't see solutions on how a normal person can become a mantainer though.
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
> how a normal person can become a maintainer though.
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.
The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn the rank of "maintainer."
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.
In this case they seem to be firmly closing the path though
> 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.
They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.
The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.
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.
It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
Just uh.. build your own thing?
Boom. Maintainer. Easy.
Why would normal people even want to become an unpaid janitor for someone else's stuff?
> 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.
That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.
I expect they'd like to not mentor new people attempting to make real contributions as well. Sometimes you're just not in a position to do that.
> it more difficult to identify who to invite to join the priesthood.
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 think whats more likely to happen is patches & forks stop being shared. If AI continues to improve, I see a world where people are mostly no longer making software for others, but purely for themselves.
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.
If you grew up in a junkyard, getting adjusted to the social norms of a bazaar might feel like your way of life is being threatened.
In your analogy, is the junkyard the development model of vibe coding?
I look forward to the book: The Cathedral, The Bazaar and The Junkyard.
fwiw I asked Claude to look at GP's post and write me a story titled "The Cathedral, the bazaar and the junkyard" and I have a pretty good time reading his riff.
“Its riff”
You're absolutely right...
> There will not be a [..] process for submitting patches by [any] means
> Outside involvement still matters: clear bug reports
So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly.
As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.
It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.
> a pull request no longer tells us as much as it used to about the person submitting it
Nobody should need to know anything about any person submitting a pull request. Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.
Reviewing code fixes is strictly easier than coming up with them yourself.
This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.
As a project you can always ignore or close a PR you want to write yourself instead. But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.
exactly. a _proposed_ code fix is a good indicator where the problem is (analysis) but more often than not the actual maintainable and sustainable solution will look different.
a code owner may choose a very different way of fixing things, even for what looks like a trivial fix.
Reviewing code in PRs is not a no-effort action. If there are 3 people working in the project, and thousands of people submitting bugfixes, then no matter how useful those bugfixes might be, the 3 people will be totally overwhelmed by the sheer number of PRs.
There might be value in your bugfix, but maybe that value is not greater than the cost of reviewing and accepting it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
This is completely false, for any sufficiently complex project. The fix might be a single line change, but the consequences might be far reaching.
> As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software?
Please don't! You don't owe the project anything. The other side of that equation is that the project also doesn't owe you anything. As simple as.
Firefox and Chromium are running much larger teams, let alone the Linux kernel, that other people suggested as a model. Maybe they can afford accepting your contributions.
> 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.
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?
Yeah, I am employed by an open source company (to be clear not open core) and most of the external code contributions we get are a net cost for us. It takes more time to review than it would have taken for our team to code and review.
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.
> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years
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.
Thanks for your work on nixpkgs but I think that shapes your perspective quite a lot - its a very different project from Ladybird. Not to belittle your contributions there but the majority of commits there are a few lines of code and much of it is declarative. I'm sure a lot goes into review of entirely new packages and there are some complex interactions between dependencies to consider on some changes but not in a program structure or logic sense. Vibe slop may not be so much an issue there.
You can still tell them how you did it, just not in the form of code/patches. You should be able to describe it in prose so that the maintainer understands your solution approach.
Not necessarily. I just fixed the Ladybird build process so it will successfully build on a system that uses musl instead of glibc. By far the most compact way of explaining what needed to be changed is to share the changes themselves. It is a set of very small changes to a number of individual files.
That sounds more like a new feature than a bugfix, however. That aside, I didn’t claim that it would necessarily be more compact, just that it’s possible. Any change can be described in prose, to whatever level is necessary to get the essential insights across. It’s how the ancient greeks did mathematics, they didn’t have symbols or formulas.
> It was very useful for me
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).
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
You're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.
> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
You can still submit a bug report and tell them exactly how you did it.
> Reviewing code fixes is strictly easier than coming up with them yourself.
Unless it's hundreds or thousands of AI slop PRs each pretending "here's a bug I fixed it"
> You can still submit a bug report and tell them exactly how you did 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.
> Can you? The announcement says
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.
Stuff like this makes me wish AI had never happened.
An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
They have rewritten a huge change of their project using llms.
How is it really related to AI? there have been issues with open-source and maintainers for a long long time
In the post, the ladybird maintainers say that they trust pull requests less than they used to, because many pull requests are authored by AI now. A big pull request no longer signals that the submitter put in a lot of work into it and it's committed to developing and maintaining quality code.
Not sure if this happened to ladybird, but the amount of junk vibecoded AI-slop pull requests has been putting an immense amount of strain on many open-source maintainers. Reviewing stuff like that is intensely energy draining an most of the time your comments will just be copy-pasted into claude code and the "contributor" will put in 0 effort themselves to try to make the code readable or maintainable.
Before AI, being open source and having to manage issues and PR's was already a huge task, burning out maintainers left and right. Now with AI, anyone with a terminal and a claude code subscription can open PR's...
Maintainers can also use the exact same tools to help review and validate PRs
So the solution is for FOSS developers to pay large sums of money to AI companies, to solve the problem that the AI companies created, for profit? ... and you typed this out as though extorting charities were a solution, instead of a grotesquely immoral and unethical systemic failure?
AI reviewing AI. Or in other words, having non-deterministic systems review the creation of non-deterministic systems, hoping for a deterministic result. Good luck with that.
My friend, the very article we are talking about this mentions this directly
Read the post
This is direct result of AI as you can see in many other public repos.
before AI like 1 in 1000 would spend their time fixing something they had no idea about and even then considering how much time you spent and how few of those happened it made sense to review/talk about it.
now every "dev" with claude submits prs having absolutely no idea what they are even doing. most of them would not even be able to create PR without AI in the first place.
and on top of that add slop bots that "fix" issues in the loop and create hundreds of PRs daily
I can understand where they come from. If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves.
I think the whole game of software engineering, open source or not, has completely changed. A lump of code doesn't mean or imply the same thing as it did 2 years ago.
I think this is the key point.
A few years ago, if I send a complex PR that compiles and passes tests, that implies a certain amount of time and cognitive investment on my part. It seems likely that I wouldn't invest that if I didn't also understand the codebase, the feature or bug I'm working on, etc.
Now, that understanding is roughly as expensive as before, but AI has vastly reduced the cost of generating the code that compiles and passes tests.
Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).
Also, this paper seems relevant: https://www.nber.org/papers/w35275
"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"
As the FT summarizes,
> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.
https://www.ft.com/content/8e9ae7a4-7209-4e2c-aa36-f3af77d6c...
So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.
And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.
> that implies a certain amount of time and cognitive investment on my part
Yes, this is the takeaway for me. A PR can no longer be a reasonable proof of work.
> If most of the pull-requests were AI-coded, well, the maintainers are equally capable of prompting Claude Code themselves.
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.
The code just isn’t the main effort of work anymore. Anyone can generate the implementation, so it makes more sense than ever to instead hammer out the what, why, and how that underlies any code change.
I see all projects moving this direction. Makes more sense to hash out a plan together.
Code was never the main effort of work, but it was a clear signal that someone has done the main effort, which is understanding the codebase, designing a new feature, or investigating a bug, and have the knowledge to write the code. By the time you get to review, you can expect a knowledgeable person on the other end.
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.
Right, and all of that is what I consider to be the "code" effort:
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.
As they say, just send me the prompt instead, at least that's more useful.
For anything but the most trivial change, a prompt is not enough though. There's a long iterative process of generating the right code, reviewing it, testing it, experimenting with UX or design for maintainability, fixing bugs... even a predominantly AI-generated PR can capture a lot of value. But apparently trying to distinguish those from the 'one-shot' vibe coded PRs is too much work for the Ladybird team.
> But apparently trying to distinguish those from the 'one-shot' vibe coded PRs is too much work for the Ladybird team.
Yes, that is exactly what this announcement is about. That it was too much work for them to tell those two apart.
Migh as well just write the thing out yourself - you will learn something by doin that and it will be easier next time. :)
> But apparently trying to distinguish those from the 'one-shot' vibe coded PRs is too much 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.
yeah but they could get free token usage from the community
Yeah, but then it’s either an arduous manual review or incurring a bunch of token usage to review something that may be slop.
When I contribute to OSS with AI I’m essentially engaging in a donation matching scheme where Anthropic matches 1 to 20 the dollar value invested (usually I can get ~2k of value per month on the $100 plan) in the open source project.
So any project that doesn’t accept AI PRs is really missing out on significant investment
> (usually I can get ~2k of value per month on the $100 plan)
Would you pay 2000$ for those tokens? If not, the number is meaningless.
> the maintainers are equally capable of prompting Claude Code themselves
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).
Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.
(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)
It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.
(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)
Those corporations are not doing that out of the good of their hearts. They are doing so to assert control, in order to protect their business value. If it stopped being economical for them, they would stop tomorrow.
I do not think we should be eternally grateful for monopoly building.
Yeah, they are essentially praising price dumping.
Chrome is Google's loss leader.
It sure is, but it’s a bit weird to call loss leader the cornerstone of their trillion dollar monopoly.
When AI first happened, I was afraid I was going to eventually lose my job. And while I've been lucky since, many did, and that hurt a lot. When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans, or at least hope that society keeps being fair to those who are most affected.
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.
>But all now seems like a transition phase. Transition to f-ing what though?
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've been thinking a fair bit about what I'm seeing in terms of the output I experience
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
I imagine this stuff is probably really good at iterative changes to improve objective benchmarks like CPU or RAM use. I'm thinking of little contained optimizations that you can understand in and of themselves, that you maybe have done yourself before in other places, found really quickly and applied uniformly. Stuff you can confirm to be what you expect it to be by mostly just scanning. Low hanging fruit for sure, but something where you can actually know what is a fruit and what is crap, and only keep the fruit, and develop some confidence in the process, if that makes sense?
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.
> Juniors want this to be a chance to shine in a market that otherwise rejected them.
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.
Is that a good thing? I think getting stuck is an intrinsic part of the learning process and sometimes it's good that there isn't an immediate answer from a senior. For some things you'd never have solved yourself, sure. But pain and suffering is a big and important chunk of learning and I fear we just throw it all out of the window with asking AI.
I am skeptical. This is a testable hypothesis, and I know there have been tons of research done trying to provide evidence of claims like these. However I have yet to see a convincing evidence. If this statement was indeed true, I think experimental data backing it up would be old news at this point, it however is not, and I suspect that is because junior developers are by and large in fact not learning faster or more with the help of AI.
> 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.
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.
> iOS is not delivering a decade of features and fixes on each yearly release
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.
> But all this smoke will eventually clear.
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.
I sense your comment as saying: "AI is hype, and reality will catch-up.".
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.
100x is achieving something in two days, what it took an entire year before. I strongly doubt that is happening for an individual.
> 100x is achieving something in two days, what it took an entire year before.
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.
That requires that you not only one-shot the thing. You will also not have the time to verify the solution yourself in that time period.
Besides 1h what used to to take 1 week is basically 40x given a workweek is 40h.
Ignoring the obvious math problem here, I think the broader scope is important. Some of the point from preceding comments is that overall longterm output is not changing. So if somebody is oneshotting a week of work in an hour, but has the same annual output... where are you losing all the normal productivity that should have happened the rest of the week/year?
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?
>One year of work could require levels of complexity and human judgement that can't be accelerated past a certain point.
In other words, if you include everything that's required to create useful software then 100x turns out to be a fantasy.
That’s also not possible in “skilled” hands. My output is roughly the same. It does the scaffolding, but I need to rewrite almost every line, because it introduces footguns around that often. And before I had about 20000 LOC it failed even with scaffolding, ie architecture. And it wasn’t taste, just footguns all around, architecture ones. Nowadays for example still introduce mutability or completely unnecessary complexity where it shouldn’t, even when the example code which does almost the same is pristine. Many times it’s like StackOverflow, when a question doesn’t need 90% of the accepted answer, but people happily copy it brainlessly.
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.
The baseline engineer in that case must really be something incompetent.
Ironic. The best way to turn 1x engineers into 100x engineers is to reduce the median skill level by 100x.
> 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.
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.
AI is turning 1x engineers into 0.3x engineers claiming to be 100x engineers.
I can believe that the difference between the slowest programmer in the world and the fastest AI aided programmer in the world is now 100x in terms of lines of code output. Like I can imagine a programmer writing 250 lines of code per week by hand and I can imagine an AI powered person writing 25,000 lines of code per week.
But we spent decades as an industry trying to dispel of the notion that SLOC/KLOC does not matter.
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).
>and I can imagine an AI powered person writing 25,000 lines of code per week.
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?
Well, as a thought experiment, I'd say that depends on if the measure is "1.3M lines of production code" or "1.3M lines of code (test code, comments and production code combined)".
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.
I have seen people with that kind of AI assisted productivity-by-volume, building eldritch abominations like Gas Town.
10x? The most generous studies I know give up to a 50% improvement.
I'm not say it's pure hype. Not in the sense of previous hype waves like the metaverse or NFCs. It clearly has uses.
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.
Name a single project that has a 10x increase. I mean real production ready code, not some single person hobby project.
> And definitely behind closed doors across companies.
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.
> 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.
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.
It always seemed like a weird default to let people (esp strangers) submit PRs that weren't tied to an issue nor approved.
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.
I think it was different pre-AI. Someone might come in and spend days getting some understanding of the codebase before they contribute some minor fix. Over time they might stick around a make some more of these, progressively gaining trust so when they do take on something bigger the maintainers will know they aren't wasting their time reviewing it.
Now they can drop a multi thousand line poorly understood PR day 1.
As someone who maintained FOSS libraries pre-AI, I think the frequency might have changed, but large drive-by PRs with thousands of changes happened before too, I've been on the receiving end of those many times. Usually they fundamentally change the architecture too, then the submitter get offended/sad/surprised when you tell them you impossibly could accept it and they should stop wasting their time contributing without discussing first. Usually ends with some threats how their fork will take all the contributors or something like that.
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.
Good faith PRs were also suffering under the current model. Ive opened PRs by hand on small projects to try and fix personal issues that probably affected others. Then the PRs languish for months or in one case literal years under the deluge of ai slop being spammed at the repo. I’m not going to ping the maintainers constantly when I know they are struggling so I’m left running my fork and no one else gets the benefit.
Big projects pre-AI also can have hundreds of rotting PRs. It's a lot of work to go through them, and unsolicited PRs are kind of the wrong way to spend time as a maintainer.
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?
First off, to have conflicting feelings about something is really normal and doesn't immediately point to a problem, it's extremely human, and I feel similar to you to. I'm a creative + programmer, I hate to see what's happening in some communities yet I too use agents for development, it'd be like avoiding Google + SO when they first appeared, feels like there is a clear "before/after" moments with those, and with LLMs as well.
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, very genuinely, highly recommend reading the Wikipedia page about the Luddites if you feel confused. This is a class consciousness problem. People feel conflicted because they know they aren't acting in their own best interests when they use generative AI (i.e. it does not lead us, as a society, to a good place -- mainly due to our bought-out legislature).
Again, I don't think there is any universal truths here, no correct nor incorrect answers, it's all very subjective. For example, I'm conflicted about the thing as a whole, but also I wouldn't say "Usage of generative AI for sure leads society to a worse place" like you just implied, that's too absolute for me and not something I'd agree with, and it wouldn't resolve the conflicts we're talking about here.
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.
> that's not the situation nor the feeling everywhere in the world, certainly not where I live
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.
> 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?
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.
> Trusting the legislative branch of my government is different from "so you think it'll work out well for everyone then huh?", btw.
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.
I feel like you're trying to move this conversation in a direction of discussing policy, while the context are individuals, their emotions and how they feel about things, that's how the conversation started. I never talked about how much I trust/distrust my government, all I said was that I trust the legislative branch, as parent commentator said they didn't trust their legislative branch. How much I distrust/trust my government at large is hardly on topic here, I also don't think because one (large) country been bought out, doesn't mean the entire world goes to shit, nor do I assume that everything everywhere will work out simply because I'm admitting that I too am conflicted, even though I too use AI-tooling, even though I'm a creative that like manual crafted things, even though I trust the legislative branch of my government.
We can also take some refuge in things like steam engines or electricity or the internet and how if you're just on the cusp of those you'd have similar feelings, but many years later here we are, still with jobs and meaning. A lot of people say this time is different but I guess when electricy showed up people would've said the same? I certainly remember people predicting that Manhattan would stop existing during the dotcom bubble because the internet would kill all street level businesses and people would work from wherever so big cities were over. And here we are.
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.
> A lot of people say this time is different but I guess when electricy showed up people would've said the same?
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.
> 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.
> That was never going to happen overnight, if at all.
Very easy to say that in hindsight.
It certainly didn’t kill Manhattan, but it did kill or at least seriously maim lots of small towns. We lost a lot of local culture in the switch to everything being available online. I’m not sure we’re better off.
You can stop at any time. It's an unfortunate reality that many will not pay much mind as long as it's other people who are being harmed, but why support something morally and financially when it's now destroying something you personally care about?
For many, there's a cost involved in stopping, and not all can bear it.
It doesn’t help to know that using and supporting private LLMs is only making openai/anthropic/google/etc even richer. I myself cannot justify its usage.
Side question: what's wrong with Sonos playing a song? Are they generating AI music now?
I think they meant Suno.
Yes, sorry for the confusion.
> When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans
As in cheer for the humans because they've been liberated from the drudgery they have lost?
AI first happened in the 1950s
Is cursing not allowed..?
Sonos? Did you mean Suno?
Apparently, yes: https://news.ycombinator.com/item?id=48411805
> Transition to f-ing what though?
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
Very related: https://graymirror.substack.com/p/sam-altmans-lamplighter
> Also: I liked a song and it was sonos. I unliked it after discovering. I feel so stupid, so often.
This is asinine. Keep depriving yourself of things you enjoy I guess?
Every like to an AI-generated work is (literally!) one more data point in support of record labels dropping human artists for AI artists that will do what they want, perform where they want, and give all of their profits back to the label.
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.
Perhaps knowing a human with talent worked on it, putting some small part of themselves and their lived experience into the music has value to them? If so, then their actions make complete sense.
Human created music might have value to them, but it doesn't mean that the AI song was valueless. They admit they enjoyed it. So it doesn't make sense in terms of it not having value.
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.
It's not asinine at all. Context matters in art. Otherwise, more songs exist that I would probably really like than I will ever hear, so I'm going to focus on the human-made ones. Besides, part of the joy of music extends beyond listening. For many people, myself included, if we feel really connected to a song we like to learn about the people who created it.
I think your response is reactionary.
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.
"I was afraid" .. "hurt a lot" .. "I hope that" .. "that feels" .. "I'm conflicted" .. "I'm confused" .. "I'm afraid" .. "human touch" .. "I liked" .. "I feel so stupid".
Maybe, just maybe, you're not thinking rationally/logically about the situation and instead are mostly operating on emotion and feelings?
The core of the human experience is to react to emotions. There’s nothing without emotions. Even if you feel like you can numb yourself to look at everything objectively, those “objective” “rational” thoughts are still based on feelings and inklings about what you trust and which facts you believe through chains of sources and anecdotes. There’s no such thing as operating without emotion.
The irony is that it is sometimes irrational/illogical to only consider rationality and logic.
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.
And that is perfectly acceptable if somebody is a human person.
its okay for humans to have feelings (and even occasionally talk about them).
What are you talking about? There was nothing irrational or illogical about what he said. The fact that he balanced his (well thought-out) opinion with emotion does not make it instantly irrational.
Reading this leaves a weird taste in my mouth, since the author tends to regularly make nontrivial >1k LOC PRs (sometimes several per day) and merge them on the same day with no reviews at all. This is even ignoring the LLM aspect; I don't know what % of them are assisted, but even if it was 0%, this isn't the pace of development I'd be comfortable with.
That's entirely consistent with what they said here:
> 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.
That's the philosophical argument. In practice, though, the effect of large unreviewed AI commits on the project and its users is likely to be the same regardless of whether those commits were prompted by a core developer or an outside contributor.
I don't buy that at all. A core developer producing a thousand line commit that they'll be responsible for over the remaining lifetime of the project is entirely different from a fire-and-forget PR from an outside contributor.
My own experience is far from this. Steering the AI, early and while developing a change, matters sigificantly.
Therefore a maintainer is more likely to steer the AI in a direction that is aligned with the codebase.
Yes, I have lost faith in some open source project maintainers that are doing this. There is an open source platform we've used for years at work (we use the paid Enterprise version of it) that introduced some pretty grotesque security flaws and when I looked into it I realized AI had taken over the project - you can clearly see it in the commit log whether it is attributed or not, just based on volume and frequency. It was very disappointing.
Why not name the project in question?
His Github page [1] matches some of this. 83% commits, 14% PRs, 2% reviews, 1% issues. Clearly out of control.
[1] https://github.com/awesomekling
LLMs might be part of why Ladybird is making this decision, but they aren’t the only possible one: SQLite, for example, has been developed this way pretty much forever. To each their own, I guess.
Lua is the same IIRC: open source but not open development.
It’s MIT licensed, and the maintainers are always grateful for bug reports, but all the code in the project was written by just 3 people.
Yeah I don't see the big deal here. Some of the best software is made and maintained by a very small group of dedicated folks. It's a perfectly reasonable move to protect their time and project.
I am old enough to remember what happened to GCC. It was also developed by a closed group of maintainers, because "it couldn't work" as a bazaar-style development. Then EGCS fork happened and became more successful.
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.
You're extrapolating from an exception.
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.
I think 8 full-time people at this point.
Yes of course it will.
Just two months ago ladybird announced that they were leveraging llms to do the rewrite that had been languishing for a year.
Now, "it breaks the social contract." Alright buddy.
This is part of the insane overreaction rippling through various communities.
The folks who figure out how to do it successfully will succeed. Groups that recede into what they know will either be slow to adapt or end up forming modern old order Mennonite groups.
Which, it's fine no judgement. But those groups don't represent technical / human progress. They represent recalcitrance in the face of a changing culture/world/society.
The rust conversion was a byte-for-byte replica of the original's bytecode, was it not? Thereby it was easily possible to validate the quality of the AI-based work. The same would obviously not be possible for patches. I don't believe you can use the rust conversion as a valid, if implied, argument that you can take AI-patches in good faith.
Fair call out.
My implied argument is not so much that "because llm was used, then llm must be used."
The original argument proposed by the author is essentially distilled into, "because llm could be used, we must no longer accept public contributions."
Which is, in my opinion, a disproportional and misguided overreaction. The llm was apparently good enough to do the byte for byte replica, so we know that it can be used (within the context of ladybird) in a way that's apparently acceptable to the maintainers.
To attempt to get more precise, argument is that "closing the gates" is moving in the wrong direction against progress, and a signals a potentially net negative impact to the ladybird project.
I don't have a fully formed thesis, it's a lot of vibes. It just feels wrong. I'm willing to acknowledge that, much like the overreaction that I'm calling out, I could be experiencing a similar kind of conservative gut reaction to the changing of the open source community that unsettles me.
Well see how it all shakes out. Right now the topic is so charged and we don't have a good suite of tools and heuristics for the new world, that were bound to see the gamut of reactions.
Very confusing statement. It is definitely true that OSS is on the verge of a crisis because of AI agents, but they clearly said AI is not the reason to reject external contributors: "Whether code was typed by hand is beside the point."
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.
How would they know for sure if the submitted code was written by a human or AI? If they had a “no-AI” policy, there would be no way to enforce it.
The policy makes sense to me given the security concerns for the project.
It saddens me to see the communities surrounding free software projects going dark because of the threat posed by AI tools, but I don't know what other solutions there are that would mitigate the threat, particularly when browsers are such a compelling target. Perhaps some kind of trust system a la arxiv.org, where existing users have to vouch for new submissions before a user is themselves trusted? Definitely still vulnerable to abuse, but perhaps less so.
I think a trust system is the only way. Ladybird will need new/different maintainers at some point in the future. How are you going to find them now?
I don’t disagree with their choice, but it’s not sustainable in the long term.
Closed-source projects have been dealing with this forever, by having a mostly-static pool of employees replenished through job listings and interviews. A FLOSS project adopting this model would certainly feel weird, but could work if there were enough willing candidates. The question is, who will take on effectively a job without the monetary reward?
My understanding is that the people working on ladybird are compensated for their full time positions, so I would also expect any future positions to be similar.
Maybe it is, if they can somehow vet potential new contributors in-person at e.g. conferences.
This is needed for more projects than just ladybird, and I'm sure will be worked out.
For now this makes sense.
Wasn't the entire goal of Ladybird to have an open and independent browser engine? Making it effectively closed to contributions makes it.. Not independent anymore. It's now dependent, on few people who work on it, just like any other closed-source or corporate-controlled browser.
I don’t think that changes the project independence, when a project is open to PRs you have the same dependency on maintainers accepting changes into main. And the project is still open source. But that does make it less community oriented
But opensource has always been about community. This way it becomes "source-open", even if you could make changes to it and run those changes yourself, the latter doesn't sound "opensourcy" to me.
Open source is about rights/freedom, the community aspect is downstream from that. You have “source available” projects with active communities and external contributors (see elastic license v2.0 projects), and open source projects that only rely on core developers. With open source freedoms comes a culture of community oriented development but what makes a project open is the license, nothing else. The right to fork, read, run, edit is what matters.
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
The open source definition does not mention community at all - it is a set of licensing requirements that certain rights to modify code must be maintained, not that upstream will accept your change or (for that matter) that you need to package it up and hand it to them.
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.
It is still independent in sense that it doesn't depend on Google Search money and Chrome/Firefox code as most of the alternative browsers. Depending on your definition of dependency, it will always going to be dependent on something.
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.
Exactly! It's not opensource anymore: it's fork-or-transparent source.
Accepting contribution has never been a requirement for open source.
I know, but opensource was not just about freedoms, it was about community.
This feels like a new phase for open source. I think screening people to join development efforts will become the norm, at least for resource-constrained projects. Trust will have to be earned.
This rather feels like it's completely stepping away from the thing that made the community around Serenity and Ladybird so good.
What made the community so good, is that it was a community.
Any rando armed with an LLM is not a community.
I'd argue that was what made Serenity good - a toy OS that anyone can code anything for. Want to spend ages working on a painting program? Make screensavers? Add drivers for your printer? Port Doom? Improve font support because it sounds fun? etc. It celebrated coding for coding's sake, which is the antithesis of AI. There's no point vibe coding features for Serenity because there is no real product there.
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.
I lost all trust in the project since the LLM rewrite. This new step is another red flag to me.
what rewrite? I thought it would switch to Rust but I still see it to be C++
They are adopting Rust (https://ladybird.org/posts/adopting-rust/) and use LLMs to help with the rewrite, but not all code was migrated yet. Also it's definitely not a big-bang-rewrite-the-world-with-Claude like Bun.
This seems quite misguided and is sad to see. They have every right to do this, but I was looking forward to continuing testing Ladybird as it improves and contributing in the future. I hope servo stays open to contributions, as it seems like it's all we have left.
It makes sense when you have a somewhat fixed core team size. Frankly, in some regards, this is the responsible thing to do.
It means they’ll never grow modules or the codebase beyond what the team can reasonably maintain.
However on the other hand.. What does this mean for the existing team, are maintainers now worth considerably more to the project? What does this mean for the codebase, or the momentum of the project?
It’s an approach I would have expected for the likes of curl, or single-purpose libraries. But this is a mammoth decision for a mammoth project.
I guess we’ll just have to see.
You can still contribute through bug reports.
>This seems quite misguided
Does it? Seems the only sane option. The other being being drowned in AI slop PRs.
I manage multiple open source Github enterprises for the Linux Foundation. Something like this is under discussion in all of them - the amount of terrible PRs and issues being filed is overwhelming.
Having read the blog post and then the comments here, I'm rather astonished. Do we understand our craft so little that our only realistic option is to ban LLMs (so-called AI)? Has everyone forgotten we've been in a software crisis for almost sixty years?[0] Have we so internalized the sweat-of-the-brow we've accumulated for decades that it's now part of the identity of being a programmer, and the only reliable signal of whether a contribution is beneficial?
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.
[0]https://en.wikipedia.org/wiki/Software_crisis
I believe the development world has a few cultural issues that make it hard to focus on the issues at hand. As a group we tend to not see the forest for the trees which causes us to worry about microscopic details while ignoring overwhelmingly more important realities, like, say, economics, lack of proper communication, team alignment, power hierarchies, etc. Being male-dominated has also not helped us for as far as I can tell the field, like many others, is dominated by power play, ego and identity issues. Everyone is trying to prove to everyone else how clever they are instead of cooperating properly. I can count on one hand the programmers I met that are actually humble and not just humble bragging. I myself am guilty of this arrogance.
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.
It's inevitable that more projects follow this path.
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.
Crappy timing for me. Ladybird has never built on musl based systems. I got that working just a couple of days ago (on Chimera Linux) and was hoping to push the changes to the project. I guess I am maintaining that myself now.
> hoping to push the changes to the project. I guess I am maintaining that myself now.
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.
Why don’t they take the Linux approach? A browser is like an OS. Linux continues to accept public contributions, through an esoteric process that discourages lazy contributors: https://www.kernel.org/doc/html/latest/process/submitting-pa...
Linux has WAY more maintainers, and many of them just reviewed other people's commits for years. They had a crazy amount of contributions even before AI.
The only problem with that nowadays might be that AI can do all the incantations that formerly acted as gates to contributors.
Maybe not. Sqlite has some kind of hand-written license-agreement waiver procedure.
The Linux approach is under pressure too. Maintainers are beginning to warn about too many contributions and too much churn to review it all.
I think we're past beginning to warn, we've now reached the point of accepting Linux needs to remove drivers and features, because the maintainers just can't keep up.
This is not helped by everyone using the same LLMs to find the same vulnerabilities and flooding maintainers with duplicate reports to be the first to get that CVE and branded vuln on their resume.
I know is a naive question, but it's genuine!
Is this the direct result of a monolithic kernel? And would moving more drivers out-of-tree mitigate this?
The kernel has many different subsystems and the subsystems have their own maintainers and mailing lists.
There are numerous advantages of microkernels over monoliths, but even if Linux were a microkernel it wouldn't necessarily change the review pressure that the above commenter is talking about, because you still have the same number of components (filesystem, networking, drivers, etc) to develop and review patches for (although you do have more well-defined interfaces between components, which eases security).
Not really - it changes how the lines are drawn between components, rather than removing any of them.
The EXT4 filesystem driver as an example contains most of the same code whether it is part of the kernel process or is a user process. A virtual filesystem abstraction is needed between the two in either case as well.
The kernel also already has a module system to support loading externally maintained code. You won't necessarily see a benefit from separately maintained drivers that wouldn't already be present.
Behind my question was another one: is there too much in the source tree that doesn't _strictly_ need to be?
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.
> 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.
One commit per logical change, `git send-email` instead of `git push` and open a PR. Sending patches is not the difference maker here.
> Ladybird remains open source. The source code will continue to be publicly available under an open source license.
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.
> We usually call open source software without open collaboration source available software.
Not at all. You are of today’s lucky 10,000 [0]. Open source refers to OSI-compliant licenses, not open to contributions. SQLite is open source but not open to contributions.
[0] https://xkcd.com/1053/
Hell no, open source is just about the licence, and source available generally refers to proprietary licenses that at least let customers access the source.
This is just the cathedral model to open source, as opposed to the bazaar you clearly prefer, but it's still open source.
Amen to that. Let's not redefine an already very precise terminology.
By definition yes, but I believe most people consider open contribution essential for OSS.
Abandoning editorial control is poison for all composed works.
They could make two kinds of pull requests and add much more strict criteria for public contributions. For example, they could say that the PR has to be smaller in size and well-documented for human review, otherwise it's closed by an automation.
And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to get it in.
Blocking public contributions means that they want to have complete control of the project and AI is likely a good excuse to do that.
That doesn't solve the volume or quality problem. LLMs can split one giant PR into 50 smaller PRs just as easily and "well-documented" isn't something you can determine automatically.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
It says something about the fragility of contemporary software that a fragment of bad code could result in doom. I think we need to move to much more restrictive computation architectures, inherently partitioned, functionally pure, and resistant to type confusion, pointer manipulation, memory issues etc.
I don't disagree with the desire for more inherently secure architectures, but I don't think it's the most relevant issue here.
You're always going to have to trust some core same-privilege code--a browser renderer is a great example of this: it has to be able to see the entirety of the DOM it's rendering, right?
Higher-level languages can still help code review--for example, memory safety makes it harder to hide a backdoor via unsafe memory operations leading to code injection. But you're still, fundamentally, trusting these community contributions.
I think the real problem (as others noted here) is that:
- writing code is now much, much cheaper than ever
- understanding and designing code is still fairly expensive
So doing the former (in the form of a PR that compiles and passes CI) is not a good "staking mechanism" to prove someone has done the latter.
The core problem is that we don't have a PR respect system. 10kLOC from an unfamiliar person with empty GitHub is much different from a pal regularly contributing that you personally know.
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.
mitchell hashimoto https://github.com/mitchellh/vouch implemented this idea
https://github.com/PThorpe92/fossier
the ghostty developer introduced a system similar to what you describe!
I don’t understand how you’re supposed to cultivate new maintainers if you shut down contribution.
Is this a sponsored project where maintainers are just hired?
Encourage forks and wait for actual experienced, committed maintainers of the fork to emerge I suppose is the way. In essence the maintainers are saying the path to trusted contributor and then to maintainer via outside unsolicited pull requests is less useful because the signals of a committed person in that path have become less useful.
You are also not cultivating any new contributors by just accepting slop the submitter did not write or understand.
I guess they will have to introduce some kind of trust-based system.
Goodhart's law, again.
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.
There is, it’s being able to tell bullshit from actual cosplayers.
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.
> There is, it’s being able to tell bullshit from actual cosplayers.
How do you do that efficiently so it can scale?
what, in your opinion, are the new proxies?
I'm not sure. I didn't think about this seriously in an adversarial context.
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 don't like this, but I understand it. I've contributed to the LB project several times, and I have made friends IRL with people who have also contributed to the project. ( we are now friends at uni ) It feels like a stepback because instead of 30-45 contributors every month, you have 15...
i feel like there should be a way to trust a PR ID verification or in-person verification at FOSDEM/DEFCON/Chaos Communication Congress,UNI's, for example.
> 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.
As much as I wanted to see another browser alternative succeed, Ladybird has lost my trust. Using LLMs to rewrite the entire codebase was already extreme. But eliminating external contributors is a precursor to a rug pull. And rewriting the entire codebase can now be seen as another step in a rug pull.
"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds."
This is probably the best, most succinct explanation of what we're seeing happening in the OS world right now.
I do wish they had left a window open for criteria to whitelist developers who can create PRs. By closing off their developer circle, they are losing the best parts of open-source - new software developers eager to solve large problems with novel approaches.
The GenAI mess has delivered a new form of Eternal September[0] but for the software development communities.
I wonder what it will be referred to as, after the dust settles?
[0] https://en.wikipedia.org/wiki/Eternal_September
So basically it will become more or less similar to the structure for SQlite and Fossil by Dr.Richar Hipp et al , basically seems most projects that have the requisite manpower/maturity will end up at that kind of structure. In the long run may be interesting from a chain of trust (human as well as code) and interop as any dev from these projects (guilds?) would already have some trust build in.
For every person wanting to do good in the world there are ten windup merchants of which at least one has darker motives
Perhaps we should start to describe projects as Open Contributions from now on. With maybe a few Open Contributions Standards to distinguish how this works.
Interesting how this post coincides with the Leyden declaration in mathematics: both documents are abot how human-human trust ("in good faith") is eroded by large language models, because a substantially-sized artifact does not necessarily attest to substantial human effort and skills.
Good point about how the community of mathematicians is struggling to come to terms with the role of language models in their work, and the similarity with the community of software developers. Machine-generated programs and proofs are contributing real value, undeniably, but it's causing social tension and destablizing the community with the sheer volume of its production, the varying quality, unreliability, and lack of humanity in the process. I would guess that similar issues will spread throughout society, in other areas of collective work and living. One potential solution, like with Ladybird and some other open source projects, is for a community to become more exclusive, restrictive and selective about what inputs they accept.
this is a move in wrong direction, its sad and a bad solution. Ladybird implements specs that must be compliant, making compliance harder is the way to go, proving the code changes does what they are intended for should be made better instead of gate keeping from malicious and "honest" contributors
Surely you can just autoclose any PRs from 1. People you don't know and 2. That are over 100 or even 50 lines?
That way new contributors are forced to start small.
I think it's not the issue with the added PR count, but the fact they have to review them. 1 big PR review is the same as 5 small PR reviews if you have to look at how it holds, edge cases and what not...
Well, then add some backpressure. Each contributor gets only a few small PRs a month, until they prove themselves. Contributors that don't have a credible online presence are automatically rejected. Etc
This is a very sad day.
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.
> 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.
Trust is key.
This project gets a lot of publicity for the product it has to show (which, as far as I know, is effectively still inexistent).
This is not really a valid criticism for an Open Source project. I built Ladybird from source yesterday and I am typing this comment in it now. So, I assure you that the Ladybird browser exists.
Of course, Ladybird is not production ready yet. Feature-wise, it is getting close. I can use it to do most of the things I want to do with a browser. Speed and reliability are another matter. I has gotten dramatically faster but normal users would still find it slow. But the biggest problem is reliability. I would not use it in its current form for anything that matters.
But for a complicated application that was started from scratch, not being ready yet is not an indictment. They claim it will be ready for regular users to try sometime this year and, from where I type, this seems realistic.
So the new way to contribute is to fork
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.
Where "better" means you and your maintainers spend all your time scrutinizing volumes of code from token prediction machines?
Good luck!
That sucks, I would have hoped that they at least allow previous contributors to somehow make PRs still.
For an open source project, is there any reason to still accept code contributions?
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.
It was alluded to in the post - contributors turn into maintainers. Someone who contributes has a small but plausible chance of sticking around.
For an open source project that isn't a business, that's really the only way to recruit people
But why recruit people, now that we have AI?
Couldn't an agent monitor feature requests and bug reports, reason about them, and then implement and fix the ones it deems important?
For the same reason software engineers still employed. AI is not yet capable of autonomous software development. From my perspective we're nowhere close.
Ladybird going source-available is quite unfortunate, seems like Gecko is the only production-ready independent browser engine we're left with.
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.
That's not source-available, that's still open-source. Quoting Wikipedia:
> 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.
It's not source available, source available implies some restrictions on what you can do with the source, or with any resulting binaries. This isn't a rugpull; all they're doing is closing off contributions, which has nothing to do with the license of the code.
This is not the same as source available - you can fork it, the license didn't change.
I once submitted a PR to Ladybird, but even in early AI days there were so many open PRs that mine got lost in the noise. I don't really blame the maintainers here. Once the open PRs get to a certain point, it becomes unmanageable.
I feel like the project just died.
Maybe, or maybe not. But it will certainly kill the community they've built up, and squander a huge amount of goodwill. Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that nobody can contribute to? Not to mention how the sponsors might feel about this.
> Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that's only source-available?
It's not source-available, it's open-source.
Sure, edited.
Possibly, but they didn’t have much choice. Large open source endeavours are dead.
> I feel like the project just died.
Why? This seems to be a strengthening move, not a weakening one.
Moving to a closed development model => opensource is just a gimmick, especially with a BSD licence.
> Moving to a closed development model => opensource is just a gimmick,
How so? Many projects are open source (GPL, MIT, whatever) while closed development, and no one calls those a gimmick.
In any case, most open-source is going to move towards a closed-development model; there simply isn't the resources to review thousands of lines of PRs per hour.
Too early to say. Once they enter "we now accept everyone to use Ladybird as daily driver" then there will be the real test phase. And, IMO, only after that phase has started and continued for some months, perhaps even few years, can a final conclusion be made. If ladybird fails then the Google empire has won permanently. Skynet slop will then be under control of Google, just as they stole all the advertisement money.
Opensource doesn't mean open to contributions. The source code is available, you can fork it and apply your patches there.
This is the way to go to reduce supply chain vulnerabilities and to reduce time of mainters reviewing LLM slop.
> Opensource doesn't mean open to contributions.
That's not entirely true. It's certainly the case that Ladybird is still under an open-source license, but the whole idea of the "Open Source" label was to move the emphasis away from having a free license to actually being open to patches in practice.
Not even the most extreme FOSS zealots (RMS, FSF, …) ever claimed that taking public contributions was ever a part of that.
But that's a bit backwards. RMS would emphatically agree that Free Software doesn't mean being open to contributions; if you asked him about either "FOSS" or "Open Source" he'd probably command you to wash your mouth out with soap. It's the other side of the fighting FOSS family which evangelised for Linux-like development (see the thread from https://news.ycombinator.com/item?id=48410503 ).
These posts need a BPUF that calls out LLM-generated PRs. No need to read between the lines and wax poetic with walls of text.
Opening lines: "Today we’re changing how code enters the Ladybird project.
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.
I wonder, if they are really only concerned about trust, will accepting external PRs but never giving commit access to external contributors work for them?
Of course, if they are also concerned about the quality of external PRs then that does not help.
Zig is moving to this direction is well.
That is the opposite of what's going on, read this https://kristoff.it/blog/contributor-poker-and-ai/
Now that I think about it, moving away from GitHub surely filtered many low-quality contributions fueled by clout/GH profile reputation.
Indeed, while there is communication that the situation with merging external pull requests should improve, the reality is that it's easier to land a patch in Linux, than in Zig.
Their loss.
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.
> More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days
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.
Every idea can seem quite nice if you only imagine the good parts, gloss over the nitty-gritty and ignore the bad.
Is your point that Anthropic is now accepting code submissions to Opus 5.0 from “millions of contributors”? No?
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.
> 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.
why would you want this. this sounds terrible
It would be free labour! Truly crowd-funded development.
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!
Just donate your tokens to the project. The actual team that’s actually leading the project can direct the prompts better and evaluate the LLM-generated code better for their project than random drive-by contributors can. That’s the whole point of their announcement.
Are they going to be using gerrit or a private repo and push changes back regularly?
Sometimes the discussions on PRs are equally valuable to see how a commit was arrived at, and I'd be sad if that got lost in this change.
It sounds like all public contribution will simply be impossible. That said, they will continue to develop out in the open on GitHub and you can clone the repo and build whenever you want. You can continue to contribute in other ways.
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.
curious what the "did the pipeline actually do what we think" story looks like now.
"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.
It's surprising to me how many people here seem offended that someone might just not want their code.
I guess it takes quite a lot of experience as a maintainer to realize that 'free' in 'free code contributions by strangers' is like 'free' in 'free puppy'.
Sometimes it’s even more like “free kudzu”.
What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway. Ladybird is not SQLite, it's under development and very likely will be forever. To me it looks like they are transitioning into a company, where this model makes sense.
> What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway.
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 wonder if adding an artificial barrier in form of a donation could help. That's probably the only remaining way to show the good faith.
To be honest, judging by their repository, it doesn't look like they've stopped accepting third-party PRs.
Surprising how little appetite for changing norms exists here on HN. Yes, the transition to agentic coding will be difficult, but to me this is mostly exciting. Despite my AI enthusiasm, I also run into shortcomings that the agents have very often, but that's a more interesting learning experience than the status quo without AI would have been!
We'll have more such disruptions and we'll learn to live with it.
I see this as the slow death of OpenSource.
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.
Some authors and UX designers to give away at least part of their work for free.
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.
Meh. The project died for me when they started using LLMs for development in the first place.
"Gain trust through plausible contributions" is a new angle on AI-produced PRs I haven't seen yet.
Though in retrospect we should have seen it. It's been an angle of attack since forever, it only took a lot of effort.
isn't linux-kernel-development operating on exactly the same model since forever ?
Someone mentioned sqlite in a comment. It's a better comparison IMO.
Also, Linux has many more people, many of whom basically just review code.
We need stricter verifications / credentials behind GitHub accounts and PRs.
And this we should have had already before AI.
How does that help? People gladly post slop PRs under their real names.
It's not the only solution but it might reduce PRs by a decent amount I would think.
If you see a PR and the guy is verified, you can check his name, his linkedin and where he works, at least there is some accountability if he introduces malicious code.
If the goal is to reduce slop, define slop. As a maintainer of a project you should be able to tell if something is slop.
If you don't have time to read PRs (which is the real issue here) that's fine too.
My guess is they want to reduce the amount of PRs, and ensure that the quality of the PRs passes an extremely high bar.
While it would help for some use-cases, it wouldn't necessarily reduce the problem that a browser is facing when dealing with malicious code in a large and complex codebase. And vetted people can be victims of supply-chain attacks, which makes it still hard to evaluate a change properly.
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.
I suspect that rather than some kind of digital proof-of-competence, communities will shift to in-person meetups at conferences and such. Which is unfortunate for people who can't attend for whatever reason, but I think some solution to that can be worked out.
What does verified means? Anyone can create fake linkedin profiles claiming they have worked for faang.
> As a maintainer of a project you should be able to tell if something is slop.
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.
I been thinking about it for a while that we need some score based system where each PR on GitHub/Gitlab grants you a review form the maintainer as well. You build your rep and the maintainers decide about the thresholds for contribution.
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.
I wonder how can a new browser engine survive with the source available model. Like, why would anyone support this, unless they have business association with the Ladybird developers?
It's not source available. It's OpenSource(TM) because of the BSD-2 license.
This is not unheard of. The most famous models are emacs & SQLite. SQLite doesn't accept outside patches, emacs is developed opaquely and only releases are put forward.
You can do this with GPL, too. You put out tarballs of the releases only.
There's a great misconception between Free Software, Open Source, and Open Development (bazaar model). They complement each other, but they are completely independent things.
Addenda: Looks like emacs' Git repo is publicly accessible now, but it's not a requirement for GPL or Free or Open Source software.
It's actually common, many companies develop their products this way. The source is available, you can see the VCS, but you can't participate in the development. That's why I see this as signal that it's going to turn into a company.
Well, technically it is a "company" already as it is registered formally as a non-profit. They have income (sponsors) and paid employees.
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.
However many if not most of these companies use "Source Available" licenses which say "Thou shall look, thou shan't compile". This is very different than Open Source license of Ladybird itself.
I truly understand why this step was taken, but it is still sad to see the death of open source or rather open contribution. Every project that turns away from open contributions is a project lost to the whims and fuckery of AI Bros.
What I realy want to know how sustainable a model like this is. How does one find new maintainers when old ones leave. When you cannot contribute anymore.
I feel like every time I hear something about Ladybird its literally anything but a working browser to actually play around with.
The cause of this is that the cost of creating plausible code contributions has gone down, so PR proposals can multiply, but flaws still threaten project security and LLMs can be confidently wrong. So human review is needed right now to maintain the integrity of the project, but it takes time and costs money. Ladybird's developers, and we as a community, can't easily evaluate "this is what we want" vs. "this is not what we want" without manual review, because we haven't settled upon a reliable representation of the meaning of our code and its side effects that is time-efficient, secure, and meaningfully interpretable at scale.
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).
Full visibility of the source code is very different from having full legibility of the system: comprehensibility is the bottleneck.
(Seems I ran out of edit time!)
This is one way to rephrase "we don't want your AI slop, thanks.".
> Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.
It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project.
> I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project.
Webkit absolutely takes third party submissions. https://webkit.org/contributing-code/ .
I believe this is an external PR merged a few hours ago at the time of this writing. https://github.com/WebKit/WebKit/pull/66507
Safari does not accept third party submissions, but the chrome has never been open (even before Google Chrome recycled the term).
WebKit does allow outside contributions, though that example is perhaps not the most illustrative as it is from an Igalia employee. Igalia maintains substantial parts of WebKit and at this point has to be the #2 contributor other than Apple themselves.
It's still open source, but not open for public contributions. That's pretty much how it was before the advent of these forges.
That's not really right, though the license is still Open Source compliant. Linux was practising an open, patches-welcome developement style before the forges existed, on its mailing list. This did indeed contrast with how eg. the FSF was running its projects, though even in those the door wasn't shut as hard on people wanting to contribute as Ladybird's now is, I think. Then Eric Raymond wrote "The Cathedral and the Bazaar" specifically to talk up Linux's patches-welcome development model, and to move the emphasis away from (just) licensing terms and source accessibility, to openness to patches. Netscape then launched the Mozilla Project specifically on the CatB model. In response to the surge of momentum, the "Open Source" label was created basically as a brand name for the CatB perspective. After all this, "doing it as open source" was established as a clear mental category in people's heads, and the forges popped up as low-friction SaaS solutions for something that people already wanted to do, and by then were often already doing. (In the process helping to make Web-based SaaS a well-established concept and business model in people's heads, something with ironic consequences.) So Ladybird's current development model is much more clearly in line with the Free Software philosophy than the Open Source philosophy. To be clear, that's not the only disagreement or difference of emphasis between "Free Software" and "Open Source": most obvioulsy, Ladybird's BSD license is a failing in the FSF's view of things, just not enough of a failing make Ladybird not Free Software. But it is a real one.
"The Cathedral and Bazaar" is orthogonal to open source. Its argument is that open source is most valuable when paired with the bazaar model, not that the cathedral model cannot be considered open.
The open source definition was created in that mind. It does not state or imply open development or a community are requirements.
CatB and Open Source aren't coaxial, but there wasn't a very clean separation between them either: https://www.free-soft.org/literature/papers/esr/cathedral-ba... https://web.archive.org/web/20021001164015/http://www.openso... . "[T]he same pragmatic, business-case grounds that motivated Netscape" was CatB. Even now OSI doesn't emphasise any separation: https://opensource.org/about . You are correct: the Open Source Definition does not mandate an open development model. However that's probably at least in a small part because, well, how would one craft a legal requirement for open development in a software license that wasn't either unenforceable or very burdensome and abusable? It's also quite definitely because the expectation was that forks and/or the threat of forks would in practice enforce a certain level of open development on OSD-compatibly-licensed software: this was in fact what ended up happening to GCC at least once https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_f... . If software projects all largely go the way Ladybird is going now, and stay that way, then it's a crushing (though not total) defeat for what the Open Source movement promoted and what it hoped to achieve; but sure, to be clear, Ladybird remains OSD-compliant. (Not total because at least the source remains available, without paying or signing anything, for bug-hunting.)
I think I didn't put the emphasis right in my comment above. The code is still fully open source, but the project that produces the code isn't. It's not dissimilar to other projects producing open source software.
This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.
> The code is still fully open source, but the project that produces the code isn't.
I think your thought was cut off. What is the project no longer?
AI contributions are only a part of the issue. Another part is where a contributor decides they want a specific feature and contributes it but then disappears off into the sunset when it comes to needing maintenance later.
Nobody wants ai slop
The cathedral vs. the bazaar. Makes sense to me.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
LLMs are killing open source just like they're killing online discussion forums.
It's heartbreaking, my two favorite things about the internet are dying off because human interaction can't outscale AI slop.
And most social media, and blogs.
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.
A bit sad to see this. Of course they are free to do it the way they prefer, and there are successful projects like this (Notably SQLite) but there has to be a reasonable middle ground between "everyone can just flood us with 30,000-line 'Claude implement feature X make no mistakes' PRs" and "we're not open to outside contributions"
How would you decide what is the middle ground though? If a project allows some AI-generated PR if its good quality, then it is a burden on the reviewer on what is considered good or not.
You can introduce a social/trust element to it, something like: Join our Discord, chat to us, come to our "office hours" video calls first, then you get to contribute.
Maybe also limit the size/scope of external contributions (only small bug fixes allowed for your first few PRs)
While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
> Now opensource will become a thing that only "influential" people can contribute to.
No. Having access to a slop generator doesn't entitle you to acceptance to any and all open source projects. You're still responsible for the quality of your contributions. Something that is completely lost on bullshit artists.
Don't put words in my ~mouth~ (keyboard) that I didn't ~say~ (type), I'm not saying I want my contributions to be accepted on equal footing even if they are generated by AI. What I'm saying is that solving this problem this way is going to make opensource much worse. We need a better way, and I'm not sure which is the better way, sorry.
Your prior message could be taken that this was an elitist move, and not a move that is being taken by many different projects for survival with limited review capacity.
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.
You aren't really contributing anything except funding to Anthropic/oai/MS/etc if you're sending genAI content. The better way will be fairly similar to the previous status quo: humans interacting with humans, with the change that there will be higher barriers to gaining access to the web of trust.
> You aren't really contributing anything except funding to Anthropic/oai/MS/etc if you're sending genAI content.
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.
Opensource is already much worse and is drowning in slop. Until a better way is found (if it can be found), severely restricting contributions is the only sane response.
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
> 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
> If everybody does the same with their small improvements, the project becomes better for everyone
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...
> Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.
I don't know about you, but as for me, when I contribute to opensource it's because I find some improvement that makes the project better because it probably polishes some rough edge around a kind-of particular use case (that maybe few people face, but still, it makes the project better for them; it amplifies the range of usecases that it can span to). If everybody does the same with their small improvements, the project becomes better for everyone, but none of the contributors of these small changes would have time to embark on maintaining a fork. Mantaining a fork is hard work, not only because software breaks over time (dependencies going obsolete or insecure, builds stop working because of old toolkits), but also because not pulling the latest changes from master would mean that your fork gets stagnated (and thus not worth to run it).
it's fair, especially because if people want to contribute to something so badly, they can make their own fork or version of it
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
I wasn’t around much before GitHub so. I believe I tried submitting patches to the XFCE project but I didn’t get anything accepted to FOSS before GitHub.
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?
seems reasonable.
> 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.
Applies so, so widely. Glad they’re taking (very necessary) action here.
I paid for Kagi's Orion (even though it's actually a little crappy) because I want options in the browser landscape. I'm really rooting for Ladybird, and just in case they don't offer a paid version in the future, here's a link to how you can sponsor its development: https://opencollective.com/ladybird
Legit
I think we are going to see a lot opensource project switching to Humans Need Not Apply Mode.
One more data point that AI is ruining open source. It's disgusting what these people are doing.
"The Cathedral and the Baazzar"
I don't understand why people contribute AI slop to existing projects. You move 1000x faster. Just write your own browser in 2 days.
I want someone to resolve the contradiction you have highlighted. Why don’t we now have an AI built web browser that is much better faster than chrome?
To that mind, why hasn’t chrome itself become 1000x better?
There is a disconnect between the narrative and reality.
The problem statement is clear to everybody.
> 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.
The Zig project is making a real difference in the culture of open source software. I'm so glad for the leadership and community. It's a refuge from the mania of large language models disrupting this and other industries, steamrolling over human connection, decency, ingenuity, class, taste. These intangible qualities that make it worthwhile, joyous and fun, will be destroyed unless people put in effort to protect them.
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.
>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.
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
Honesty. WTF is Ladybird? Feel like as a normal guy doing normal software development I'm living in an alternate reality or something.
How is this the top post on my favorite website?
Oh well, AI bros ruined it. I'm actually glad in some twisted way, because if more projects follow suit and close their development, it will again become an actual badge of honor to get on those teams. Having contributed to such projects will mean something.
"A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it."
Then the linux kernel is doomed. /s
Cool - how about fewer perma-bans on github for participating in discussions?
Also, as I have pointed out before, they seem to develop too slowly for a solid beta this year. You only have to look at the issue tracker and check for URLs not working or even crashing the browser. Ladybird may have gotten better in the last months, but imagine if 50.000 people are using it, you will see more bugs. How do they then handle bug reports?
Can we see some discussions that got people perma-banned?
Seems cold how they present this, but on the other hand I’ve ignored Ladybird because I just don’t think they’ll have meaningful impact, so I remain unaffected by this policy change.