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

151–160 of 602 posts

Re: Changing how we develop Ladybird

#151

Post by LeFantome »

layer8 wrote: post #71
nh2 wrote: 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…

You can still tell them how you did it, just not in the form of code/patches. You should be able to describe it in prose so that the maintainer understands your solution approach.

Not necessarily. I just fixed the Ladybird build process so it will successfully build on a system that uses musl instead of glibc. By far the most compact way of explaining what needed to be changed is to share the changes themselves. It is a set of very small changes to a number of individual files.

Re: Changing how we develop Ladybird

#152

Post by afdbcreid »

siwatanejo wrote: post #82
conaclos wrote: post #59

Earlier quoted context omitted.

I lost all trust in the project since the LLM rewrite. This new step is another red flag to me.

what rewrite? I thought it would switch to Rust but I still see it to be C++

They are adopting Rust (https://ladybird.org/posts/adopting-rust/) and use LLMs to help with the rewrite, but not all code was migrated yet. Also it's definitely not a big-bang-rewrite-the-world-with-Claude like Bun.

Re: Changing how we develop Ladybird

#153

Post by Fraterkes »

lucideer wrote: post #87
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…

The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort. In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a…

Gratitude was maybe the wrong word. As the article mentions, before ai I think larger PRs, while sometimes inconsiderate, at least implied some amount of care / effort / good faith. In my experience, that was often rewarded with the maintainers at least taking a look at the code. I meant it's odd to have the same expectation when you dump 3000 lines in a pr that you won't even personally write a description for.

Re: Changing how we develop Ladybird

#154

Post by duskdozer »

siwatanejo wrote: post #98
troupo wrote: post #84

Earlier quoted context omitted.

> Now opensource will become a thing that only "influential" people can contribute to. No. Having access to a slop generator doesn't entitle you to acceptance to any and all open source projects. You're still responsible for the quality of your contributions. Something that is completely lost on bullshit artists.

Don't put words in my ~mouth~ (keyboard) that I didn't ~say~ (type), I'm not saying I want my contributions to be accepted on equal footing even if they are generated by AI. What I'm saying is that solving this problem this way is going to make opensource much worse. We need a better way, and I'm not sure which is the better way, sorry.

You aren't really contributing anything except funding to Anthropic/oai/MS/etc if you're sending genAI content. The better way will be fairly similar to the previous status quo: humans interacting with humans, with the change that there will be higher barriers to gaining access to the web of trust.

Re: Changing how we develop Ladybird

#155

Post by sdevonoes »

bigupthewhole wrote: post #70
habinero wrote: post #51

Earlier quoted context omitted.

How does that help? People gladly post slop PRs under their real names.

It's not the only solution but it might reduce PRs by a decent amount I would think. If you see a PR and the guy is verified, you can check his name, his linkedin and where he works, at least there is some accountability if he introduces malicious code. If the goal is to reduce slop, define slop. As a maintainer of a project you should be able to tell if something is slop. If you don't have time to read PRs (which is…

What does verified means? Anyone can create fake linkedin profiles claiming they have worked for faang.

Re: Changing how we develop Ladybird

#156

Post by dvdkon »

JimBlackwood wrote: post #33
jsmailes wrote: 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.

Closed-source projects have been dealing with this forever, by having a mostly-static pool of employees replenished through job listings and interviews. A FLOSS project adopting this model would certainly feel weird, but could work if there were enough willing candidates. The question is, who will take on effectively a job without the monetary reward?

Re: Changing how we develop Ladybird

#158

Post by TheCoreh »

b3e53bb34c0bd wrote: post #116
TheCoreh wrote: post #105

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

You can introduce a social/trust element to it, something like: Join our Discord, chat to us, come to our "office hours" video calls first, then you get to contribute.

Maybe also limit the size/scope of external contributions (only small bug fixes allowed for your first few PRs)

Re: Changing how we develop Ladybird

#160

Post by afdbcreid »

I wonder, if they are really only concerned about trust, will accepting external PRs but never giving commit access to external contributors work for them?

Of course, if they are also concerned about the quality of external PRs then that does not help.

Post reply on HN