81–90 of 602 posts
LLMs might be part of why Ladybird is making this decision, but they aren’t the only possible one: SQLite, for example, has been developed this way pretty much forever. To each their own, I guess.
It’s MIT licensed, and the maintainers are always grateful for bug reports, but all the code in the project was written by just 3 people.
This rather feels like it's completely stepping away from the thing that made the community around Serenity and Ladybird so good.
I lost all trust in the project since the LLM rewrite. This new step is another red flag to me.
Fascinating 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…
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.
No. Having access to a slop generator doesn't entitle you to acceptance to any and all open source projects. You're still responsible for the quality of your contributions. Something that is completely lost on bullshit artists.
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
Nowadays any AI lunatic with a couple of tokens to spare can spare no effort, have no understanding and still flood you with a wall of code that on first look might even look okay (spoiler: it's actually trash). That is tiring for maintainers.
This is all about AI
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.
I look forward to the book: The Cathedral, The Bazaar and The Junkyard.
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…
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 post-ai world. They were always out of line & continue to be.
Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.
It says something about the fragility of contemporary software that a fragment of bad code could result in doom. I think we need to move to much more restrictive computation architectures, inherently partitioned, functionally pure, and resistant to type confusion, pointer manipulation, memory issues etc.
You're always going to have to trust some core same-privilege code--a browser renderer is a great example of this: it has to be able to see the entirety of the DOM it's rendering, right?
Higher-level languages can still help code review--for example, memory safety makes it harder to hide a backdoor via unsafe memory operations leading to code injection. But you're still, fundamentally, trusting these community contributions.
I think the real problem (as others noted here) is that:
- writing code is now much, much cheaper than ever
- understanding and designing code is still fairly expensive
So doing the former (in the form of a PR that compiles and passes CI) is not a good "staking mechanism" to prove someone has done the latter.
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.
I 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.
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 that compiles and passes tests.
Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).