Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

Post reply on HN
Print view View original

491–500 of 602 posts

Re: Changing how we develop Ladybird

#491

Post by cestith »

maplethorpe wrote: post #353
efficax wrote: post #298

Earlier quoted context omitted.

> open your repo to the public, and have a stream of code flow in from millions of contributors. More code than you could ever write in ten lifetimes, uploaded to your repository in a matter of days. why would you want this. this sounds terrible

It would be free labour! Truly crowd-funded development. I'm picturing something like folding@home, but where people donate their spare tokens to a service, and those tokens get distributed amongst all open source projects on GitHub. You don't think that would be cool? Like, someone might initialise a repo with only a readme and a to do list before they go to sleep, and then wake up to a complete software ecosystem t…

Just donate your tokens to the project. The actual team that’s actually leading the project can direct the prompts better and evaluate the LLM-generated code better for their project than random drive-by contributors can. That’s the whole point of their announcement.

Re: Changing how we develop Ladybird

#492

Post by cestith »

rhubarbtree wrote: post #291

I see this as the slow death of OpenSource. It’s controversial to say, and I may be downvoted, but I’ll share this as a pov: OSS is essentially giving away our work for free. Did that ever really make sense? If it does, why don’t graphic designers give their work away for free? Why don’t authors do that? UX designers? It’s a very peculiar thing to us nerds. And the strangest thing is, we may have unwittingly built th…

Some authors and UX designers to give away at least part of their work for free.

The point of OSS though isn’t that nobody gets paid. It’s that if they charge for contributions, they get paid to release their work as Open Source software. They get paid for the labor of producing the artifact, and not necessarily paid a royalty for future sales of the copies.

Re: Changing how we develop Ladybird

#494

Post by cestith »

q3k wrote: post #78

It's surprising to me how many people here seem offended that someone might just not want their code. I guess it takes quite a lot of experience as a maintainer to realize that 'free' in 'free code contributions by strangers' is like 'free' in 'free puppy'.

Sometimes it’s even more like “free kudzu”.

Re: Changing how we develop Ladybird

#495

Post by Klonoar »

dcrazy wrote: post #488
Klonoar wrote: post #454

Earlier quoted context omitted.

> It’s pretty much exactly what Americans decry about unions. If you consider a union to be a "bad thing" then we are likely going to talk past each other for eternity.

I support workers being compensated for their value; what I dislike are protectionism and ossification. I am fortunate that software has paid me well to work on problems I am enthusiastic about solving. I understand that a lot of people on e.g. the Ford assembly line are not there because they want to make excellent cars, they’re there because they need a job. I acknowledge that I have no idea what it’s like to struc…

You're throwing around the term "ossification" like it's a guarantee or necessity tied to anything being discussed here, and that's just not the case.

Software developers should not ossify. Nowhere have I said that LLMs as a tool - used by those in this profession! - should be shunned. I was pointing out that people being totally okay with those outside our profession, those without the necessary skillsets, directly doing our work not only devalues our work.

Re: Changing how we develop Ladybird

#496

Post by ncruces »

crabmusket wrote: post #231
noIdeaTheSecond wrote: post #137

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

Precisely. In the case of OSS it makes no sense for maintainers to spend more time reviewing AI generated code than contributors spent prompt engineering it. That's just not helpful.

Re: Changing how we develop Ladybird

#497

Post by sambaumann »

fabon wrote: post #480

Very confusing statement. It is definitely true that OSS is on the verge of a crisis because of AI agents, but they clearly said AI is not the reason to reject external contributors: "Whether code was typed by hand is beside the point." If AI is the problem, the solution would be introducing an AI policy, community trust management system or something like that. Definitely not a closed development process.

There's a big difference between a well considered high quality contribution made using AI as a tool and "claude find and fix an issue in this repo so I can put on my resume that I contributed to a high profile project". The problem is that it takes considerable time of the reviewers to filter out the high quality contributions vs the low quality ones.

I do think closing off contributions is a big step and would rather most projects find a middle ground, but it's definitely understandable why they did this.

Re: Changing how we develop Ladybird

#498

Post by radlad »

helloplanets wrote: post #221
Fraterkes wrote: post #66

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

If a project has a rule to not submit AI generated PRs, people should never submit AI generated PRs to that project. It's spam. Or if the rule is more nuanced than that in relation to AI, it should be respected. It's 100% an issue with the people with submitting these PRs. So, if someone has a history of having no issue with breaking project rules (let alone being arrogant about it), it should be a massive red flag a…

I can empathize with this view but I've also seen one line clear bug fixes rejected because CC signed off on it.

There's no other correct fix - why do you care which pen I used to write it?

Re: Changing how we develop Ladybird

#499

Post by cestith »

justin66 wrote: post #473
cestith wrote: post #380

Earlier quoted context omitted.

That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.

I expect they'd like to not mentor new people attempting to make real contributions as well. Sometimes you're just not in a position to do that.

You make a strong point. Large parts of a decision like this have less to do with what you can get from the community, but what you have person-hours available to do with it. The core team is pretty small, and a lot of these automatically coded PRs are bound to be huge. They’re taking back their own time to focus on their own project.

Re: Changing how we develop Ladybird

#500

Post by ian-g »

potsandpans wrote: post #451
tarkin2 wrote: post #441

Earlier quoted context omitted.

The rust conversion was a byte-for-byte replica of the original's bytecode, was it not? Thereby it was easily possible to validate the quality of the AI-based work. The same would obviously not be possible for patches. I don't believe you can use the rust conversion as a valid, if implied, argument that you can take AI-patches in good faith.

Fair call out. My implied argument is not so much that "because llm was used, then llm must be used." The original argument proposed by the author is essentially distilled into, "because llm could be used, we must no longer accept public contributions." Which is, in my opinion, a disproportional and misguided overreaction. The llm was apparently good enough to do the byte for byte replica, so we know that it can be u…

I see where you're coming from, but I think it's less the fact that they _can_ use an LLM to do this and more that they can't guarantee anybody else has exercised equal diligence with their code or equal experience with browser engines.

It's not unreasonable to feel conflicted about this, but at the same time, I wonder if they're starting to burn out on code review.

Post reply on HN