Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

281–290 of 602 posts

Re: Changing how we develop Ladybird

#281

Earlier quoted context omitted.

There are great Open Source projects doing fine with the cathedral style, just look at Sqlite and its siblings (Fossil, …). So I do not see a problem with Ladybirds decision, in contrary, IMHO it strengthens the human aspect of software development and puts the brakes on AI free riders

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…

Just uh.. build your own thing?

Boom. Maintainer. Easy.

Why would normal people even want to become an unpaid janitor for someone else's stuff?

Re: Changing how we develop Ladybird

#282
post #242

Interesting how this post coincides with the Leyden declaration in mathematics: both documents are abot how human-human trust ("in good faith") is eroded by large language models, because a substantially-sized artifact does not necessarily attest to substantial human effort and skills.

Good point about how the community of mathematicians is struggling to come to terms with the role of language models in their work, and the similarity with the community of software developers. Machine-generated programs and proofs are contributing real value, undeniably, but it's causing social tension and destablizing the community with the sheer volume of its production, the varying quality, unreliability, and lack of humanity in the process. I would guess that similar issues will spread throughout society, in other areas of collective work and living. One potential solution, like with Ladybird and some other open source projects, is for a community to become more exclusive, restrictive and selective about what inputs they accept.

Re: Changing how we develop Ladybird

#283
Their loss.

Think about it. Anthropic just reported that their codebase is now improving itself. We're moments away from every open source repo being able to do the same. Think of it like torrenting — you'll be able to 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.

Ladybird doesn't know it yet, but they just left themselves in the dust.

Re: Changing how we develop Ladybird

#284

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

That's the most succinct way I have seen someone put it, thanks! It's really the same issue, no matter if it's software, online comments, e-mails, artworks, homework, etc. We engage because we expect to be interacting with the output of another human being. AI fundamentally betrays this expectation.

Re: Changing how we develop Ladybird

#285

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…

> As a maintainer of a project you should be able to tell if something is slop.

Of course they can, the problem is they have to spend time digging through a ton of garbage looking for the ones that aren't low quality slop.

If you're getting DDOSed, you start by putting up a firewall lol.

Re: Changing how we develop Ladybird

#286

Earlier quoted context omitted.

>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…

I sense your comment as saying: "AI is hype, and reality will catch-up.". But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies. Reality will catch-up with that too, once the other smoke clears.

100x is achieving something in two days, what it took an entire year before. I strongly doubt that is happening for an individual.

Re: Changing how we develop Ladybird

#287
post #219

Reading this leaves a weird taste in my mouth, since the author tends to regularly make nontrivial >1k LOC PRs (sometimes several per day) and merge them on the same day with no reviews at all. This is even ignoring the LLM aspect; I don't know what % of them are assisted, but even if it was 0%, this isn't the pace of development I'd be comfortable with.

That's entirely consistent with what they said here: > Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.

That's the philosophical argument. In practice, though, the effect of large unreviewed AI commits on the project and its users is likely to be the same regardless of whether those commits were prompted by a core developer or an outside contributor.

Re: Changing how we develop Ladybird

#288
post #190

Earlier quoted context omitted.

> Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences. It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the…

> I think they're moving in the WebKit/Safari direction: open for you to look at, but not really an open source project. Webkit absolutely takes third party submissions. https://webkit.org/contributing-code/ . I believe this is an external PR merged a few hours ago at the time of this writing. https://github.com/WebKit/WebKit/pull/66507 Safari does not accept third party submissions, but the chrome has never been ope…

WebKit does allow outside contributions, though that example is perhaps not the most illustrative as it is from an Igalia employee. Igalia maintains substantial parts of WebKit and at this point has to be the #2 contributor other than Apple themselves.

Re: Changing how we develop Ladybird

#289
post #269

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…

There massive value in AI PR's. If a feature and ignored, it can forked to provide more value to the users. If unaccepted bugfixes, the maintainers are just silly. They need to be forked off.

I mean, aren't you kind of proving the poster's point?

Fork away. If you want to put in the meaningful effort required to maintain and improve upon a project as significant as Godot, and feel that AI is a mechanism you want in order to do so, go for it. Clearly, the maintainers don't feel that that's the best approach to create the product they want to create, and they are not required to accede to the sense of entitlement of the community.

Re: Changing how we develop Ladybird

#290
curious what the "did the pipeline actually do what we think" story looks like now.

"green" and "the right artifact exists" drift apart faster than expected with more automation. exit code wasn't enough for us — had to make the output file the thing that proves a run happened.

Post reply on HN