Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

31–40 of 602 posts

Re: Changing how we develop Ladybird

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

Re: Changing how we develop Ladybird

#32

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

Re: Changing how we develop Ladybird

#33
post #3

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…

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.

Re: Changing how we develop Ladybird

#34

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.

Re: Changing how we develop Ladybird

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

Re: Changing how we develop Ladybird

#37

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

Re: Changing how we develop Ladybird

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

Post reply on HN