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.
Changing how we develop Ladybird
101–110 of 602 posts
Re: Changing how we develop Ladybird
#102It'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
#103Wasn'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
Re: Changing how we develop Ladybird
#104Fascinating 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…
I do not think we should be eternally grateful for monopoly building.
Re: Changing how we develop Ladybird
#105Re: Changing how we develop Ladybird
#106I'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…
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
#107Earlier 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.
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
#108I 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.
Re: Changing how we develop Ladybird
#109I 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.
It's not source-available, it's open-source.
Re: Changing how we develop Ladybird
#110I 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…
"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.