Changing how we develop Ladybird • Hacker News Board

Re: Changing how we develop Ladybird

#71

Post by layer8 » Fri, Jun 05, 2026, 9:20 AM UTC

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.

Re: Changing how we develop Ladybird

#72

Post by q3k » Fri, Jun 05, 2026, 9:20 AM UTC

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…

> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.

You're allowed, they'll just ignore it. Same as how sqlite and some other projects operate.

Re: Changing how we develop Ladybird

#73

Post by tuyiown » Fri, Jun 05, 2026, 9:21 AM UTC

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…

> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.

Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.

Re: Changing how we develop Ladybird

#74

Post by ufo » Fri, Jun 05, 2026, 9:22 AM UTC

gregoriol wrote: post #67

koteelok wrote: post #9

Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.

How is it really related to AI? there have been issues with open-source and maintainers for a long long time

In the post, the ladybird maintainers say that they trust pull requests less than they used to, because many pull requests are authored by AI now. A big pull request no longer signals that the submitter put in a lot of work into it and it's committed to developing and maintaining quality code.

Re: Changing how we develop Ladybird

#75

Post by ares623 » Fri, Jun 05, 2026, 9:22 AM UTC

gregoriol wrote: post #67

koteelok wrote: post #9

Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.

How is it really related to AI? there have been issues with open-source and maintainers for a long long time

My friend, the very article we are talking about this mentions this directly

Re: Changing how we develop Ladybird

#76

Post by risyachka » Fri, Jun 05, 2026, 9:23 AM UTC

gregoriol wrote: post #67

koteelok wrote: post #9

Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.

How is it really related to AI? there have been issues with open-source and maintainers for a long long time

This is direct result of AI as you can see in many other public repos.

before AI like 1 in 1000 would spend their time fixing something they had no idea about and even then considering how much time you spent and how few of those happened it made sense to review/talk about it.

now every "dev" with claude submits prs having absolutely no idea what they are even doing. most of them would not even be able to create PR without AI in the first place.

and on top of that add slop bots that "fix" issues in the loop and create hundreds of PRs daily

Re: Changing how we develop Ladybird

#77

Post by jaapz » Fri, Jun 05, 2026, 9:23 AM UTC

gregoriol wrote: post #67

koteelok wrote: post #9

Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.

How is it really related to AI? there have been issues with open-source and maintainers for a long long time

Not sure if this happened to ladybird, but the amount of junk vibecoded AI-slop pull requests has been putting an immense amount of strain on many open-source maintainers. Reviewing stuff like that is intensely energy draining an most of the time your comments will just be copy-pasted into claude code and the "contributor" will put in 0 effort themselves to try to make the code readable or maintainable.

Before AI, being open source and having to manage issues and PR's was already a huge task, burning out maintainers left and right. Now with AI, anyone with a terminal and a claude code subscription can open PR's...

Re: Changing how we develop Ladybird

#78

Post by q3k » Fri, Jun 05, 2026, 9:23 AM UTC

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

Re: Changing how we develop Ladybird

#79

Post by troupo » Fri, Jun 05, 2026, 9:23 AM UTC

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…

> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.

You can still submit a bug report and tell them exactly how you did it.

> Reviewing code fixes is strictly easier than coming up with them yourself.

Unless it's hundreds or thousands of AI slop PRs each pretending "here's a bug I fixed it"

Re: Changing how we develop Ladybird

#80

Post by domenicd » Fri, Jun 05, 2026, 9:24 AM UTC

Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.

(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)

It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.

(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)