"The Cathedral and the Baazzar"

Legit

One more data point that AI is ruining open source. It's disgusting what these people are doing.

I think we are going to see a lot opensource project switching to Humans Need Not Apply Mode.

I don't understand why people contribute AI slop to existing projects. You move 1000x faster. Just write your own browser in 2 days.

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?

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.

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?

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?

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.

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 feel like the project just died.

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.

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.

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.

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.

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

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.

We need stricter verifications / credentials behind GitHub accounts and PRs.

And this we should have had already before AI.

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

The cathedral vs. the bazaar. Makes sense to me.

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...

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.

This is one way to rephrase "we don't want your AI slop, thanks.".

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

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"

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.

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.

seems reasonable.

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

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

    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

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

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

That sucks, I would have hoped that they at least allow previous contributors to somehow make PRs still.

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.

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

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.

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.

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.

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.

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.

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.

This project gets a lot of publicity for the product it has to show (which, as far as I know, is effectively still inexistent).

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.

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.

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.

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.

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.

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.

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.

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

Sure, edited.

For the same reason software engineers still employed. AI is not yet capable of autonomous software development. From my perspective we're nowhere close.

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

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.

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.

Abandoning editorial control is poison for all composed works.

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.

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.

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.

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

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

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.

It was a proof of work system. When work becomes cheap, it stops being proof.

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.

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

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.

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.

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.

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.

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.

I know, but opensource was not just about freedoms, it was about community.

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?

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.

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

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.

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.

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

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

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.

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.

Yes, sorry for the confusion.

Maintainers can also use the exact same tools to help review and validate PRs

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.

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

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.

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.

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.

As explained: New features. Bugfixes. Better analysis.

Only stoneagers would say that they are better than a good AI.

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.

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.

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.

That sounds like a massive headache for maintainers and opportunity for people to cry foul. That gets messy so fast.

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.

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.

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

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.

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

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

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?

100x is achieving something in two days, what it took an entire year before. I strongly doubt that is happening for an individual.

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

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.

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.

I have seen people with that kind of AI assisted productivity-by-volume, building eldritch abominations like Gas Town.

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.

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.