Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

61–70 of 602 posts

Re: Changing how we develop Ladybird

#61

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.

If you grew up in a junkyard, getting adjusted to the social norms of a bazaar might feel like your way of life is being threatened.

Re: Changing how we develop Ladybird

#62
Are they going to be using gerrit or a private repo and push changes back regularly?

Sometimes the discussions on PRs are equally valuable to see how a commit was arrived at, and I'd be sad if that got lost in this change.

Re: Changing how we develop Ladybird

#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 rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.

It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.

> a pull request no longer tells us as much as it used to about the person submitting it

Nobody should need to know anything about any person submitting a pull request. Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.

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

This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.

As a project you can always ignore or close a PR you want to write yourself instead. But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.

Re: Changing how we develop Ladybird

#64

Surely you can just autoclose any PRs from 1. People you don't know and 2. That are over 100 or even 50 lines? That way new contributors are forced to start small.

I think it's not the issue with the added PR count, but the fact they have to review them. 1 big PR review is the same as 5 small PR reviews if you have to look at how it holds, edge cases and what not...

Well, then add some backpressure. Each contributor gets only a few small PRs a month, until they prove themselves. Contributors that don't have a credible online presence are automatically rejected. Etc

Re: Changing how we develop Ladybird

#65
post #54

Earlier quoted context omitted.

> Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences. It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the…

It's still open source, but not open for public contributions. That's pretty much how it was before the advent of these forges.

I think I didn't put the emphasis right in my comment above. The code is still fully open source, but the project that produces the code isn't. It's not dissimilar to other projects producing open source software.

This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.

Re: Changing how we develop Ladybird

#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 surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.

Re: Changing how we develop Ladybird

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

Re: Changing how we develop Ladybird

#68
post #4

I feel like the project just died.

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

Re: Changing how we develop Ladybird

#69

While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.

> Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.

Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.

Re: Changing how we develop Ladybird

#70

We need stricter verifications / credentials behind GitHub accounts and PRs. And this we should have had already before AI.

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 the real issue here) that's fine too.

My guess is they want to reduce the amount of PRs, and ensure that the quality of the PRs passes an extremely high bar.

Post reply on HN