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?
[deleted]
Changing how we develop Ladybird
111–120 of 602 posts
Re: Changing how we develop Ladybird
#112I 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.
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.
Re: Changing how we develop Ladybird
#113I 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?
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.
Re: Changing how we develop Ladybird
#114Ladybird 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.
Re: Changing how we develop Ladybird
#115Wasn'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.
Exactly! It's not opensource anymore: it's fork-or-transparent source.
Accepting contribution has never been a requirement for open source.
Re: Changing how we develop Ladybird
#116A 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.
Re: Changing how we develop Ladybird
#117Earlier quoted context omitted.
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 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 necessarily see a benefit from separately maintained drivers that wouldn't already be present.
Re: Changing how we develop Ladybird
#118I'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…
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.
Re: Changing how we develop Ladybird
#119> 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…
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.
Re: Changing how we develop Ladybird
#120[deleted]