Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

411–420 of 602 posts

Re: Changing how we develop Ladybird

#411
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

Re: Changing how we develop Ladybird

#412
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

Re: Changing how we develop Ladybird

#413
post #35

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.

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

Re: Changing how we develop Ladybird

#414
post #376

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…

[flagged]

Re: Changing how we develop Ladybird

#415

Earlier quoted context omitted.

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…

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

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

Re: Changing how we develop Ladybird

#416
post #404

Earlier quoted context omitted.

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…

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.

Re: Changing how we develop Ladybird

#417

"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds." I believe this is the key point the article makes and it's valid for most projects out there

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.

Re: Changing how we develop Ladybird

#418

"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds." I believe this is the key point the article makes and it's valid for most projects out there

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.

Re: Changing how we develop Ladybird

#419
post #361

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…

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?

Re: Changing how we develop Ladybird

#420

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

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

Post reply on HN