Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

131–140 of 602 posts

Re: Changing how we develop Ladybird

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

Re: Changing how we develop Ladybird

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

Re: Changing how we develop Ladybird

#133
post #129

Earlier quoted context omitted.

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

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.

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.

Re: Changing how we develop Ladybird

#134

Earlier quoted context omitted.

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.

Re: Changing how we develop Ladybird

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

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.

Re: Changing how we develop Ladybird

#136
post #117

Earlier quoted context omitted.

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?

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…

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.

Re: Changing how we develop Ladybird

#138
post #84

Earlier quoted context omitted.

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

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

Re: Changing how we develop Ladybird

#139

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.

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.

Re: Changing how we develop Ladybird

#140

This rather feels like it's completely stepping away from the thing that made the community around Serenity and Ladybird so good.

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.

Post reply on HN