Ladybird seems to have received a nice boost in momentum in the past two years. If you've ever watched one of Andreas videos on YouTube you'll find he's incredibly driven and knowledgeable in this area. I can imagine someone like him would go from being a "10x programmer" to a "100x programmer" with AI assistance. I am not entirely sure to what degree AI is being leveraged to speed up development, but I am indeed happier I might be able to ditch FF and begin using their browser soon.
Ladybird seems to have received a nice boost in momentum in the past two years.
I'm still very interested in the project and look forward to each monthly update, and I can empathize (though not agree) with the reasoning, but something is off ever since they announced the decision to close the project to outside contributions. It's still Open Source, but only a self-selected group of maintainers gets to write and merge code, at least for the time being.
Somehow that's not the "a new independent Open Source browser" future I thought we had signed up for with our attention.
Again, I understand all the arguments for why at this particular time they feel that they cannot afford the energy expense required need to run a community. First-hand, actually, because I am involved with running a very large one myself.
But it makes me think a lot about the value proposition of the product. Re-creating Firefox/Chrome can still be a useful exercise, but from an end-user POV another exchangable web browser will not rock their world. Wouldn't the real product be healthy governance?
The flood of low effort AI-contributions makes accepting anonymous contributions impractical nowadays. They'd waste hours reviewing things of no value. I know because it happened to several of my moderately successful projects. At some point I had to stop caring. I now only review the PR if the message is a single unformatted paragraph with few emojis, I find this to be a good signal that it was made by a human and not an agent (the code could still be LLM but a human cared enough to write their own message). I'm sure I will miss genuinely good and valuable contributions, but the signal-to-noise ratio is just too low.
It would be 100x worse for them because who wouldn't want to have a browser in their contribution portfolio when seeking a job?
A lot of folks might not want to hear it, but realistically some there's going to have to be a cultural realization that machine-generated low effort slop is not any more desired or helpful than human-generated low effort slop.
That's not an outright rejection of LLM-assisted code, it just means that a real person needs to be awake, at the wheel, and just as significant of a contributor. Literally anybody can point Claude at a repo and say "add X feature" or "fix Y bug" and so PRs that do that carry no value.
The value of a feature or a bugfix is not calculated from the effort required but from the need or desire for said feature or bugfix. So whether or not the barrier to entry has been lowered by llm's is irrelevant. What matters as to it's value is the result.
The important part is the quality of the code, how well-considered its design is, how well it gels with existing code, how readable it is to other humans, how well documented it is, how well its author understands it (and thus, can make surgical changes if needed), and how well it was tested.
A PR that implements a sought out feature or bug fix can be practically worthless if it doesn’t check some percentage of those boxes. The line differs per project naturally, but almost nobody wants a PR that is missing all of them.
That might be true of the raw, unknowable "true" value of the thing, but that's not the same as what people are willing to pay for a thing.
When one evaluates a purchase, implicit in that evaluation is the option to do the work one's self. If the price you are offering a thing is more than the cost of doing it myself, then I will not buy from you.
LLM coding proponents keep saying that it reduces the cost of development to near-zero. We keep hearing about all the "things we wouldn't have done before because it was just too expensive to get people to do it."
If this is true, any day now, the customers and clients and consumers are going to catch wise and start doing it for themselves. I mean, it's been almost a year since LLMs supposedly "10x'd" everyone's productivity. I'm still waiting to see where all this singularity is, so I doubt it actually is true. But it doesn't mean you're going to achieve ungodly margins on your software sales, especially when we're talking about open source software. Value absolutely does have a component that is the cost of the inputs.
Again, I understand all the arguments for why at this particular time they feel that they cannot afford the energy expense required need to run a community. First-hand, actually, because I am involved with running a very large one myself.
This is a problem brought on by AI, and does not seem fair to imply it's Ladybird's problem to solve.
Writing a browser/engine from scratch is a massively ambitious undertaking by itself. I don't expect them to also solve the tangential AI problem that every other open source project is contending with. Others can step up for that one.
I agree with your concerns but also think that a new viable browser engine will be such a benefit to the health of the open web that I'm willing to overlook such irregularities, at least for now. sqlite doesn't accept contributions either and it's done well for itself, and if Ladybird ends up going sour there's always the possibility of a fork. This is similar to my stance towards Firefox: despite the actions of Mozilla Corp, having at least one non-Blink engine is too important, and for friends and family that I care about, working ad-blockers are essential so there's no practical alternative.
Multiple browser engines reimplementing the same things fragments engineering resources and blink based browsers do have working as blockers. In fact ladybird uses the same adblocker as Brave, which is blink based.
Free and open-source software licenses never promised that any given project would absolutely accept code contributions from the general public. You're as free to exercise the Four Freedoms with Ladybird as you are with Firefox or Chromium, including the freedom to fork it; and your practical ability to get your own change merged into upstream Ladybird is probably about as good as it is for Firefox/Chromium, too.
Linux had an existing population of Unix engineers who had a strong incentive to build something that could replace the Unix systems they were paying for.
Ladybird doesn’t replace something developers are already paying for, so the incentive to make substantial, high-quality contributions is much weaker.
It's still Open Source, but only a self-selected group of maintainers gets to write and merge code, at least for the time being.
That is the way the BSDs are developed and they're free software. If you want to you can pull the code and modify whatever you want. Let them get the thing up and running first, then see how the project handles external contributions. If they somehow fail to see the brilliance of some external contribution a fork will soon take over from where they dug themselves in, something which has happened many times over in free software land: Firefox (took over from the Mozilla Suite), Libreoffice (took over from Openoffice), Nextcloud (took over from Owncloud), egcs (took over from gcc, later became the main gcc branch), etc.
Ladybird [0]: "We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers. [...] There will not be a separate process for submitting patches by other means."
FreeBSD [1]: "So you want to contribute to FreeBSD? That is great! FreeBSD relies on the contributions of its user base to survive. Your contributions are not only appreciated, they are vital to FreeBSD’s continued growth. [...] If you are submitting a simple patch to the src repo, please consider submitting it to the project’s GitHub mirror as a pull request."
Don't BSDs accept new contributors and patches tho? A long time ago I worked in the freebsd documentation project (translating th handbook) and it was pretty easy to join the core group. And ooenbsd pioneered anoncvs didn't it?
For ladybird it seems the group is closed to outsiders.
That's not really relevant. "anoncvs" was just the ability to retrieve source code from the project's repository without an account, as opposed to being forced to download a tarball. It didn't do anything more than ladybird's public github-hosted repository[1] to facilitate contributions.
Think of ladybird's github issues like the openbsd mailing lists. If you start submitting good issues with patches there, and you do it often enough that they would rather let you merge your patches yourself, there's a high likelihood you'll no longer be an outsider. (I don't know this from personal experience with ladybird, but it's the vibe I get from their posts about the matter.)
Comments
I didn't expect to see Twitch working so soon!
Ladybird seems to have received a nice boost in momentum in the past two years. If you've ever watched one of Andreas videos on YouTube you'll find he's incredibly driven and knowledgeable in this area. I can imagine someone like him would go from being a "10x programmer" to a "100x programmer" with AI assistance. I am not entirely sure to what degree AI is being leveraged to speed up development, but I am indeed happier I might be able to ditch FF and begin using their browser soon.
I'm still very interested in the project and look forward to each monthly update, and I can empathize (though not agree) with the reasoning, but something is off ever since they announced the decision to close the project to outside contributions. It's still Open Source, but only a self-selected group of maintainers gets to write and merge code, at least for the time being.
Somehow that's not the "a new independent Open Source browser" future I thought we had signed up for with our attention.
Again, I understand all the arguments for why at this particular time they feel that they cannot afford the energy expense required need to run a community. First-hand, actually, because I am involved with running a very large one myself.
But it makes me think a lot about the value proposition of the product. Re-creating Firefox/Chrome can still be a useful exercise, but from an end-user POV another exchangable web browser will not rock their world. Wouldn't the real product be healthy governance?
The flood of low effort AI-contributions makes accepting anonymous contributions impractical nowadays. They'd waste hours reviewing things of no value. I know because it happened to several of my moderately successful projects. At some point I had to stop caring. I now only review the PR if the message is a single unformatted paragraph with few emojis, I find this to be a good signal that it was made by a human and not an agent (the code could still be LLM but a human cared enough to write their own message). I'm sure I will miss genuinely good and valuable contributions, but the signal-to-noise ratio is just too low.
It would be 100x worse for them because who wouldn't want to have a browser in their contribution portfolio when seeking a job?
A lot of folks might not want to hear it, but realistically some there's going to have to be a cultural realization that machine-generated low effort slop is not any more desired or helpful than human-generated low effort slop.
That's not an outright rejection of LLM-assisted code, it just means that a real person needs to be awake, at the wheel, and just as significant of a contributor. Literally anybody can point Claude at a repo and say "add X feature" or "fix Y bug" and so PRs that do that carry no value.
The value of a feature or a bugfix is not calculated from the effort required but from the need or desire for said feature or bugfix. So whether or not the barrier to entry has been lowered by llm's is irrelevant. What matters as to it's value is the result.
The important part is the quality of the code, how well-considered its design is, how well it gels with existing code, how readable it is to other humans, how well documented it is, how well its author understands it (and thus, can make surgical changes if needed), and how well it was tested.
A PR that implements a sought out feature or bug fix can be practically worthless if it doesn’t check some percentage of those boxes. The line differs per project naturally, but almost nobody wants a PR that is missing all of them.
That might be true of the raw, unknowable "true" value of the thing, but that's not the same as what people are willing to pay for a thing.
When one evaluates a purchase, implicit in that evaluation is the option to do the work one's self. If the price you are offering a thing is more than the cost of doing it myself, then I will not buy from you.
LLM coding proponents keep saying that it reduces the cost of development to near-zero. We keep hearing about all the "things we wouldn't have done before because it was just too expensive to get people to do it."
If this is true, any day now, the customers and clients and consumers are going to catch wise and start doing it for themselves. I mean, it's been almost a year since LLMs supposedly "10x'd" everyone's productivity. I'm still waiting to see where all this singularity is, so I doubt it actually is true. But it doesn't mean you're going to achieve ungodly margins on your software sales, especially when we're talking about open source software. Value absolutely does have a component that is the cost of the inputs.
Looks like we need some kind of reputation mechanism for contributors.
https://github.com/mitchellh/vouch
This is a problem brought on by AI, and does not seem fair to imply it's Ladybird's problem to solve.
Writing a browser/engine from scratch is a massively ambitious undertaking by itself. I don't expect them to also solve the tangential AI problem that every other open source project is contending with. Others can step up for that one.
I agree with your concerns but also think that a new viable browser engine will be such a benefit to the health of the open web that I'm willing to overlook such irregularities, at least for now. sqlite doesn't accept contributions either and it's done well for itself, and if Ladybird ends up going sour there's always the possibility of a fork. This is similar to my stance towards Firefox: despite the actions of Mozilla Corp, having at least one non-Blink engine is too important, and for friends and family that I care about, working ad-blockers are essential so there's no practical alternative.
Multiple browser engines reimplementing the same things fragments engineering resources and blink based browsers do have working as blockers. In fact ladybird uses the same adblocker as Brave, which is blink based.
It also fragments power, which makes it worth it.
Power is proportional to browser market share, not the engines the browsers use.
Free and open-source software licenses never promised that any given project would absolutely accept code contributions from the general public. You're as free to exercise the Four Freedoms with Ladybird as you are with Firefox or Chromium, including the freedom to fork it; and your practical ability to get your own change merged into upstream Ladybird is probably about as good as it is for Firefox/Chromium, too.
Said announcement: https://ladybird.org/posts/changing-how-we-develop-ladybird/
Linux had an existing population of Unix engineers who had a strong incentive to build something that could replace the Unix systems they were paying for.
Ladybird doesn’t replace something developers are already paying for, so the incentive to make substantial, high-quality contributions is much weaker.
That is the way the BSDs are developed and they're free software. If you want to you can pull the code and modify whatever you want. Let them get the thing up and running first, then see how the project handles external contributions. If they somehow fail to see the brilliance of some external contribution a fork will soon take over from where they dug themselves in, something which has happened many times over in free software land: Firefox (took over from the Mozilla Suite), Libreoffice (took over from Openoffice), Nextcloud (took over from Owncloud), egcs (took over from gcc, later became the main gcc branch), etc.
No, it isn't.
Ladybird [0]: "We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers. [...] There will not be a separate process for submitting patches by other means."
FreeBSD [1]: "So you want to contribute to FreeBSD? That is great! FreeBSD relies on the contributions of its user base to survive. Your contributions are not only appreciated, they are vital to FreeBSD’s continued growth. [...] If you are submitting a simple patch to the src repo, please consider submitting it to the project’s GitHub mirror as a pull request."
[0] https://ladybird.org/posts/changing-how-we-develop-ladybird/
[1] https://docs.freebsd.org/en/articles/contributing/
Don't BSDs accept new contributors and patches tho? A long time ago I worked in the freebsd documentation project (translating th handbook) and it was pretty easy to join the core group. And ooenbsd pioneered anoncvs didn't it?
For ladybird it seems the group is closed to outsiders.
That's not really relevant. "anoncvs" was just the ability to retrieve source code from the project's repository without an account, as opposed to being forced to download a tarball. It didn't do anything more than ladybird's public github-hosted repository[1] to facilitate contributions.
Think of ladybird's github issues like the openbsd mailing lists. If you start submitting good issues with patches there, and you do it often enough that they would rather let you merge your patches yourself, there's a high likelihood you'll no longer be an outsider. (I don't know this from personal experience with ladybird, but it's the vibe I get from their posts about the matter.)
[1](https://github.com/LadybirdBrowser/ladybirdP)