Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

231–240 of 602 posts

Re: Changing how we develop Ladybird

#231

"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

The generalised form of this, which we are rapidly discovering, is that AI breaks the social contract that used to exist between an author and a reader (of prose, code, anything).

Re: Changing how we develop Ladybird

#232
post #63

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

> It was very useful for me

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

#233
Surprising how little appetite for changing norms exists here on HN. Yes, the transition to agentic coding will be difficult, but to me this is mostly exciting. Despite my AI enthusiasm, I also run into shortcomings that the agents have very often, but that's a more interesting learning experience than the status quo without AI would have been!

We'll have more such disruptions and we'll learn to live with it.

Re: Changing how we develop Ladybird

#234
post #138

Earlier 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

> If everybody does the same with their small improvements, the project becomes better for everyone

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

#235

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

The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.

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

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

Yeah but it comes with a cost. Claude isn't free.

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

#237

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

As someone who maintained FOSS libraries pre-AI, I think the frequency might have changed, but large drive-by PRs with thousands of changes happened before too, I've been on the receiving end of those many times. Usually they fundamentally change the architecture too, then the submitter get offended/sad/surprised when you tell them you impossibly could accept it and they should stop wasting their time contributing without discussing first. Usually ends with some threats how their fork will take all the contributors or something like that.

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

#238

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

https://github.com/PThorpe92/fossier

Re: Changing how we develop Ladybird

#239

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

In this case they seem to be firmly closing the path though

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

Post reply on HN