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

121–130 of 602 posts

Re: Changing how we develop Ladybird

#121

Post by LeFantome »

steve1977 wrote: post #40

This project gets a lot of publicity for the product it has to show (which, as far as I know, is effectively still inexistent).

This is not really a valid criticism for an Open Source project. I built Ladybird from source yesterday and I am typing this comment in it now. So, I assure you that the Ladybird browser exists.

Of course, Ladybird is not production ready yet. Feature-wise, it is getting close. I can use it to do most of the things I want to do with a browser. Speed and reliability are another matter. I has gotten dramatically faster but normal users would still find it slow. But the biggest problem is reliability. I would not use it in its current form for anything that matters.

But for a complicated application that was started from scratch, not being ready yet is not an indictment. They claim it will be ready for regular users to try sometime this year and, from where I type, this seems realistic.

Re: Changing how we develop Ladybird

#122

Post by lukaslalinsky »

bayindirh wrote: post #96
lukaslalinsky wrote: post #92

I wonder how can a new browser engine survive with the source available model. Like, why would anyone support this, unless they have business association with the Ladybird developers?

It's not source available. It's OpenSource(TM) because of the BSD-2 license. This is not unheard of. The most famous models are emacs & SQLite. SQLite doesn't accept outside patches, emacs is developed opaquely and only releases are put forward. You can do this with GPL, too. You put out tarballs of the releases only. There's a great misconception between Free Software, Open Source, and Open Development (bazaar model…

It's actually common, many companies develop their products this way. The source is available, you can see the VCS, but you can't participate in the development. That's why I see this as signal that it's going to turn into a company.

Re: Changing how we develop Ladybird

#123

Post by Orphis »

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…

While it would help for some use-cases, it wouldn't necessarily reduce the problem that a browser is facing when dealing with malicious code in a large and complex codebase. And vetted people can be victims of supply-chain attacks, which makes it still hard to evaluate a change properly.

It's not an impossible problem, but it's a resource allocation problem, and they don't seem to have a way to address it at the moment besides closing all PRs.

Re: Changing how we develop Ladybird

#124

Post by dgellow »

siwatanejo wrote: post #103
dgellow wrote: post #32

Earlier quoted context omitted.

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.

Open source is about rights/freedom, the community aspect is downstream from that. You have “source available” projects with active communities and external contributors (see elastic license v2.0 projects), and open source projects that only rely on core developers. With open source freedoms comes a culture of community oriented development but what makes a project open is the license, nothing else. The right to fork, read, run, edit is what matters.

Unfortunately AI tools are breaking the open community dynamics, it has become more and more expensive to run open community oriented projects due to the noise, it’s really a shame. It’s a lot to expect volunteer project members to triage the increasing amount of AI garbage

Re: Changing how we develop Ladybird

#125

Post by Hendrikto »

leoc wrote: post #91
merelydev wrote: post #47

Opensource doesn't mean open to contributions. The source code is available, you can fork it and apply your patches there. This is the way to go to reduce supply chain vulnerabilities and to reduce time of mainters reviewing LLM slop.

> Opensource doesn't mean open to contributions. That's not entirely true. It's certainly the case that Ladybird is still under an open-source license , but the whole idea of the "Open Source" label was to move the emphasis away from having a free license to actually being open to patches in practice.

Not even the most extreme FOSS zealots (RMS, FSF, …) ever claimed that taking public contributions was ever a part of that.

Re: Changing how we develop Ladybird

#127

Post by andrewchambers »

VortexLain wrote: post #114

Ladybird going source-available is quite unfortunate, seems like Gecko is the only production-ready independent browser engine we're left with. They may, at this point, go ahead and remove "get involved" block from their website https://ladybird.org/ , since it's not possible to contribute anymore.

This is not the same as source available - you can fork it, the license didn't change.

Re: Changing how we develop Ladybird

#128

Post by artyom »

torben-friis wrote: post #118
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…

There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs. It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM con…

I agree it's not "entitlement" specifically but there's something there. I guess by now everyone has experienced that type of person that "tries to help" by copy/pasting a bunch of AI slop and expecting you to work through the cognitive load of validating it.

The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.

Re: Changing how we develop Ladybird

#129

Post by abirch »

DrewADesign wrote: post #106
lucideer wrote: post #87

Earlier quoted context omitted.

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

I see AI as a barrier remover. Unfortunately some barriers are good or minimally necessary.

I think we'll need to revert to artificial barriers such as bonds, e.g., if you want to do a PR to my repository you need to pay a 10 dollar bond. If the PR is good and I want future PRs, you keep your bond. If it's slop and spam, I get 10 dollars for my time.

Re: Changing how we develop Ladybird

#130

Post by dwaite »

siwatanejo wrote: post #103
dgellow wrote: post #32

Earlier quoted context omitted.

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.

The open source definition does not mention community at all - it is a set of licensing requirements that certain rights to modify code must be maintained, not that upstream will accept your change or (for that matter) that you need to package it up and hand it to them.

And submitting a PR is almost wholly dissimilar from a conversation between friends over dinner or drinks. If you want to have a community around an open source project, it always has taken more than just accepting patches.

Post reply on HN