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

171–180 of 602 posts

Re: Changing how we develop Ladybird

#171

Post by m4rtink »

rjh29 wrote: post #135
satvikpendem wrote: post #108

Earlier quoted context omitted.

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

For anything but the most trivial change, a prompt is not enough though. There's a long iterative process of generating the right code, reviewing it, testing it, experimenting with UX or design for maintainability, fixing bugs... even a predominantly AI-generated PR can capture a lot of value. But apparently trying to distinguish those from the 'one-shot' vibe coded PRs is too much work for the Ladybird team.

Migh as well just write the thing out yourself - you will learn something by doin that and it will be easier next time. :)

Re: Changing how we develop Ladybird

#172

Post by applfanboysbgon »

abirch wrote: post #129
DrewADesign wrote: post #106

Earlier quoted context omitted.

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.

This is entirely too much friction in the wrong place. Public open source will simply die before a system like that ever becomes the norm.

The previous barriers worked because they were organically perfectly in line with a contributor's internal incentives. A contributor gains very little benefit from submitting a patch; the likelihood is infinitesimally small they'll ever get any career advancement, financial recompense, or even much community recognition for it. At most, it shifts the burden of maintaining the code they're contributing from themselves to the community / long-term maintainers. The real incentive for a contributor was making the patch, because they get to see the feature or fix they want made for the software. The previous barriers were in making the patch, and contributors would overcome that friction to gain the benefit of having the patch they want. Moving the barrier to merely submitting the patch after it has already been made will simply result in people not bothering, because there is very little incentivizing them to deal with the friction.

Re: Changing how we develop Ladybird

#173

Post by broodbucket »

armchairhacker wrote: post #8

Why don’t they take the Linux approach? A browser is like an OS. Linux continues to accept public contributions, through an esoteric process that discourages lazy contributors: https://www.kernel.org/doc/html/latest/process/submitting-pa...

One commit per logical change, `git send-email` instead of `git push` and open a PR. Sending patches is not the difference maker here.

Re: Changing how we develop Ladybird

#174

Post by broodbucket »

afandian wrote: post #23
delusional wrote: post #13

Earlier quoted context omitted.

The Linux approach is under pressure too. Maintainers are beginning to warn about too many contributions and too much churn to review it all.

I know is a naive question, but it's genuine! Is this the direct result of a monolithic kernel? And would moving more drivers out-of-tree mitigate this?

The kernel has many different subsystems and the subsystems have their own maintainers and mailing lists.

Re: Changing how we develop Ladybird

#175

Post by Yokohiii »

cpcallen wrote: post #42

On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working. On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.

Open source development has become more and more superficial aligning with modern social network characteristics. It's more important to have an contribution, a active commit history, a few stars as a proof of pixel fame than the intrinsic value of the contributions or projects.

Before the rise of github, open source projects were heavily walled gardens. Little clubs that gave you a stare when you entered the room. Github commoditized getting in touch and lowered the barrier for how much effort you have to put in or even how much you have to care before you contribute. This is gone now and you have to build trust now before you can contribute to anything.

This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.

Re: Changing how we develop Ladybird

#176

Post by bayindirh »

lukaslalinsky wrote: post #122
bayindirh wrote: post #96

Earlier quoted context omitted.

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.

However many if not most of these companies use "Source Available" licenses which say "Thou shall look, thou shan't compile". This is very different than Open Source license of Ladybird itself.

Re: Changing how we develop Ladybird

#177

Post by ivanjermakov »

The core problem is that we don't have a PR respect system. 10kLOC from an unfamiliar person with empty GitHub is much different from a pal regularly contributing that you personally know.

Integrating some kind of proof-of-stake system might be a way forward for open source. Nobody wants to shuffle through a pile of low-quality PRs written by LLM.

Re: Changing how we develop Ladybird

#179

Post by [deleted] »

patates wrote: post #131

When AI first happened, I was afraid I was going to eventually lose my job. And while I've been lucky since, many did, and that hurt a lot. When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans, or at least hope that society keeps being fair to those who are most affected. Now I see communities being affected. When you kill PRs, you not only kill the co…

[deleted]

Re: Changing how we develop Ladybird

#180

Post by debugnik »

ivanjermakov wrote: post #170

> Ladybird remains open source. The source code will continue to be publicly available under an open source license. We usually call open source software without open collaboration source available software. This is terrible news, defeating core beliefs people had in Ladybird. Not an open browser I wished for.

Hell no, open source is just about the licence, and source available generally refers to proprietary licenses that at least let customers access the source.

This is just the cathedral model to open source, as opposed to the bazaar you clearly prefer, but it's still open source.

Post reply on HN