"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
Changing how we develop Ladybird
231–240 of 602 posts
Re: Changing how we develop Ladybird
#232> 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…
Exactly. You want others to change to fulfill your needs. Their priorities and needs are different. In this case, it was evaluated and found not to be useful (cost > benefits).
Re: Changing how we develop Ladybird
#233We'll have more such disruptions and we'll learn to live with it.
Re: Changing how we develop Ladybird
#234Earlier quoted context omitted.
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
> You're always welcome to fork any and all projects and run your AI on those I already replied to the forking thing here: https://news.ycombinator.com/item?id=48410121
That assumes everyone does that. Instead, with LLMs everyone just does "do a thing, no mistakes".
And when that backfires, uses LLMs to start an automated bullying and smearing campaign: https://cybernews.com/security/openclaw-bot-attacks-develope...
Re: Changing how we develop Ladybird
#235Earlier quoted context omitted.
I still don't see solutions on how a normal person can become a mantainer though. If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view. Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source pr…
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 th…
I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.
That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.
Re: Changing how we develop Ladybird
#236I 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.
Initially I thought AI would be great for FOSS because suddenly open source projects could get up to speed with paid options. UIs could get better (albeit boring/soulless) with Claude Design, etc.
But then I guess someone has to pay for all of those tokens. It's "easier" to devote your time but much harder to justify spending $300/mo on contributions to open source.
So maybe some people see this almost as a donation? Hey, I paid for tokens and generated a PR - be grateful for my donation!
And then they completely disregard the fact that reviewing the generated slop becomes way too much for the contributors. They would probably have appreciated a monetary donation more.
Re: Changing how we develop Ladybird
#237Earlier quoted context omitted.
It always seemed like a weird default to let people (esp strangers) submit PRs that weren't tied to an issue nor approved. What do you mean you just spent a week implementing something in secret? AI makes it extra silly because now you can craft up your unsolicited code change in minutes, making it extra obvious that code changes should spawn from real discussion and agreement. TFA is part of looking for new processe…
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.
What I don't get, is why these LLM users aren't asking their LLM for how to contribute and how the project prefers to contribute, and how they can make sure it's accepted? Literally, the very same tools they use to code, can be used to make sure their PR follows all guidelines, from discussions to acceptance of the PR itself, it's right there, they literally just have to prompt for it! Such a lazy group of people.
Re: Changing how we develop Ladybird
#238The core problem is that we don't have a PR respect system. 10kLOC from an unfamiliar person with empty GitHub is much different from a pal regularly contributing that you personally know. Integrating some kind of proof-of-stake system might be a way forward for open source. Nobody wants to shuffle through a pile of low-quality PRs written by LLM.
Re: Changing how we develop Ladybird
#239Earlier quoted context omitted.
I still don't see solutions on how a normal person can become a mantainer though. If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view. Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source pr…
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 th…
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
Re: Changing how we develop Ladybird
#240Make 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.