Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

101–110 of 602 posts

Re: Changing how we develop Ladybird

#101
I don't like this, but I understand it. I've contributed to the LB project several times, and I have made friends IRL with people who have also contributed to the project. ( we are now friends at uni ) It feels like a stepback because instead of 30-45 contributors every month, you have 15...

i feel like there should be a way to trust a PR ID verification or in-person verification at FOSDEM/DEFCON/Chaos Communication Congress,UNI's, for example.

Re: Changing how we develop Ladybird

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

What made open source great, is the fact that if you find a problem, you can patch it. It's what motivated me, anyway. Ladybird is not SQLite, it's under development and very likely will be forever. To me it looks like they are transitioning into a company, where this model makes sense.

Re: Changing how we develop Ladybird

#103
post #32

Wasn't the entire goal of Ladybird to have an open and independent browser engine? Making it effectively closed to contributions makes it.. Not independent anymore. It's now dependent, on few people who work on it, just like any other closed-source or corporate-controlled browser.

I don’t think that changes the project independence, when a project is open to PRs you have the same dependency on maintainers accepting changes into main. And the project is still open source. But that does make it less community oriented

But opensource has always been about community. This way it becomes "source-open", even if you could make changes to it and run those changes yourself, the latter doesn't sound "opensourcy" to me.

Re: Changing how we develop Ladybird

#104

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

Those corporations are not doing that out of the good of their hearts. They are doing so to assert control, in order to protect their business value. If it stopped being economical for them, they would stop tomorrow.

I do not think we should be eternally grateful for monopoly building.

Re: Changing how we develop Ladybird

#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"

Re: Changing how we develop Ladybird

#106

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…

Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from, say, someone cargo-culting code from tutorials.

Moreover, as these tools become more expensive, people with money to blow on tokens will be able to drown maintainers that don’t have enough token-cash to help them deal with it. People see this as mostly a matter of time and energy, but I reckon it will soon be a financial issue.

Re: Changing how we develop Ladybird

#107

Earlier quoted context omitted.

> I feel like the project just died. Why? This seems to be a strengthening move, not a weakening one.

Moving to a closed development model => opensource is just a gimmick, especially with a BSD licence.

> Moving to a closed development model => opensource is just a gimmick,

How so? Many projects are open source (GPL, MIT, whatever) while closed development, and no one calls those a gimmick.

In any case, most open-source is going to move towards a closed-development model; there simply isn't the resources to review thousands of lines of PRs per hour.

Re: Changing how we develop Ladybird

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

As they say, just send me the prompt instead, at least that's more useful.

Re: Changing how we develop Ladybird

#109
post #4

I feel like the project just died.

Maybe, or maybe not. But it will certainly kill the community they've built up, and squander a huge amount of goodwill. Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that nobody can contribute to? Not to mention how the sponsors might feel about this.

> Why would anybody who's interested in supporting or using an independent browser (read: techies) choose one that's only source-available?

It's not source-available, it's open-source.

Re: Changing how we develop Ladybird

#110
post #90
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.

I think this is the key point. A few years ago, if I send a complex PR that compiles and passes tests, that implies a certain amount of time and cognitive investment on my part. It seems likely that I wouldn't invest that if I didn't also understand the codebase, the feature or bug I'm working on, etc. Now, that understanding is roughly as expensive as before, but AI has vastly reduced the cost of generating the code…

Also, this paper seems relevant: https://www.nber.org/papers/w35275

"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"

As the FT summarizes,

> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.

https://www.ft.com/content/8e9ae7a4-7209-4e2c-aa36-f3af77d6c...

So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.

And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.

Post reply on HN