Changing How We Develop Ladybird
67 points by raoulmillais
67 points by raoulmillais
It is so wretched review "contributions" in clang these days, there is just an endless stream of garbage PRs. People have gotten better at disguising the obvious tells (the ones who are still ignoring the slop disclosure requirements), but it still reasonably obvious most of the time - but it still burns time. For the people who actually acknowledge their use and say how it was used you still have to work out whether what they're saying there is true, or whether it's just a complete slop PR and they're hoping that by acknowledging, but minimizing, the use that will result in a bad PR being accepted.
Also I still don't understand vibecoders: I have now seen a lot of these PRs now, and I don't think I've seen a single one that was actually good - some are "ok" and the author actually starts doing work themselves, but most just disappear - and others are just obviously bad, not obvious in the "I work on clang so I know how these things should be done" but "this is getting some of the most basic coding concepts completely wrong".
Vibecoders must surely see this?
The other option, which is a step down even from vibe coding making a (or let's be honest: downloading from someone else) a script that automates the fuzzer->bug->llm->pr pipeline, and will create PRs that both catastrophically misunderstand the actual bug, "fix" the bug in similarly broken ways, and then include tests that are bad, sometimes wrong, and, in at few cases, don't even include the original failing test case (and indeed, one of those PRs didn't even fix the original failure they were "fixing").
It's so unbelievably frustrating and time consuming to deal with, and it reduces the time available to (and frankly interest in) help new contributors develop their skills. As in: "this PR is from a name I don't recognize, and it's saying it is fixing a crash" - is this going to be a pointless exercise in time wastage, or might this actually be someone interested in contributing.
I think the last point is important: if a person is just throwing slop at a project, they're not interested in contributing, they're not interested in helping, they're not interested in actually learning anything. Honestly my feeling is that most of these vibe coding "contributors" are looking for resume items ("contributed to clang", etc).
Honestly my feeling is that most of these vibe coding "contributors" are looking for resume items ("contributed to clang", etc).
The D website has a contributors list auto-generated by merged PRs. Some newb came on the chat asking about how that list is updated then quickly put in some trivial pr and nagged the guy to merge it. Then he kept coming back to the chat saying "why does the list update? why aren't i on it yet?" I just kept thinking, dude, why do you care so much? He let slip he is young but after the website updated....... gone.
Joke's on him though, someone reading that resume will be like "D? what's that?" lol.
tbh though, I kinda remember being young and dumb myself. I saw a website by a prominent open source personality that said you can mirror it. I did, and even emailed him to be added to the list of mirrors. Never got a reply. Probably for the better. But yeah. I also subscribed to the nmap dev mailing list so level up as a 1337 hax0r. Never said anything, never even tried to contribute a patch. But still, I think I was not so different than this new kid.
Not that it excuses anything but today's environment is crazy competitive for young developers and I really do get why they think they need to go through all this.
My first interview, back in 2002 or so, was basically "can you do this in Flash?" -- I did about half of it because I'd only worked with Flash 4 (nothing newer than that would run decently on my ancient PC), then went like, uh, I can tell you what I need to do from here but I have no idea how to do it in Flash MX. It was fine, my future boss said yeah, OK, we'll get you a Flash MX book.
Whereas these days I have HR/recruiting occasionally telling me with a straight face that some of the CVs they get for internship positions are kind of thin and barely have any credentials -- no prior internships, barely any FOSS contributions or personal projects, they're basically just "I'm studying CS". Nineteen year old kids. Barely any credentials.
I hate AI slop as much as any engineer with a modicum of self-respect but in this particular case I really think they're a symptom, not the plague itself.
TBF no FOSS or side projects is pretty telling of if this is a person who's been into coding since they were a kid or just another person who picked this major for some reason or other.
No FOSS or side projects for a nineteen year-old kid is pretty telling of a gazillion of other things, from living in a remote area with poor connectivity where all they could do was tinker with computers but not do a lot of FOSS work, to growing up poor and having to work part-time since they were twelve and never having time to stick to a project long enough, to having ultra-religious parents who never let them touch computers until they could get away from home so almost all the software they ever wrote before they got to university was on paper. All of which I've seen, and more.
Plus, even if that weren't the case, it shouldn't be a minimum threshold for making it to a screening interview. There is such a thing as being smart, hard-working and professional without having been a gifted child, and wanting to work in a field is as good a reason for picking up a major as any. If someone's good at it, I want to work with them, I don't really care how old they were when they started coding.
As someone who grew up poor, in the middle of nowhere with no internet and conservative parents and wrote many reams of paper of qbasic code I completely agree with you.
However when we're talking about a job seeking process candidates are being compared against each other. Obviously if no applicant has any side project (online or on paper) then you can't include that in an evaluation. But if I have two applicants and one can talk about this thing they wrote once and the other only has coursework... I mean of course that's a factor?
But if I have two applicants and one can talk about this thing they wrote once and the other only has coursework... I mean of course that's a factor?
Sure, but not even giving an applicant who doesn't have it the chance to do a screening interview over the phone is absurd IMHO. Like, they applied, they're in a CS program so they're not in our inbox because they're just clicking Apply on every job ad out there -- why exclude them right away?
I get that the barrier of entry for initial contributions and amateur work is lower with software but taking that as an indicator of competence is an odd choice in my book. You can be perfectly good at something without doing it in your spare time. Including better than people who do it in their spare time.
Assuming that’s true, that doesn’t indicate whether or not they would be good at the work.
In my experience it's a pretty good indicator or passion which is a pretty good indicator of "being good"
Of course it isn't infallible. Even a full interview process isn't. It's just a signal
I have to admit I got a big thrill out of getting into the V8 AUTHORS.md file a few years ago (especially because it wasn't from a trivial patch). I can kind of understand their position.
Best "that's my name on a list!" for me came a month ago; I was showing off a game I like (UnReal World) to a friend's kid and opened the credits screen: in there, at the top of a list of special thanks was my name "for helping out throughout the years". I didn't even understand why at first, before I realised that I kept sending the author money whenever I had extra income when I was in university.
The problem statement is clear to everybody.
For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.
The solution, IMO, is a strictly worse version than what we chose in the Zig project (banning LLM contributions).
AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.
Things that worry me about this choice:
open source is a tough business and you need to leverage the good things about it to make it worth doing. contributors bring in a huge amount of value that they offer you essentially for free (see contributor poker), on top of being a hugely valuable recruitment funnel. They're rejecting all of that, which seems insane to me.
one could argue that LLMs could fill that gap but, first of all they could have just banned LLM usage only in PRs from untrusted contributors, and second even the best LLM:
removing the influx of code that comes from PRs means that over time the whole project will have a small number of contributors that own all the code, making it easier for the project to do a license rugpull. when copyright ownership is well distributed this kind of thing is harder to pull off.
Overall, this is not good in my opinion. They're making open source a more problematic business model for them than it has to be, while at the same time making it harder to recruit more core contributors, as the code ownership coalesces to small group of people.
This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler. I guess only time will tell.
To be fair, open source is not the same as open contribution or community governance. Sqlite is a good example of a project that does not allow any 3rd party contributions, and they seem to be doing pretty well.
I learned the hard way that any time you suggest SQLite doesn't allow 3rd party contributions D. Richard Hipp will call you out for it.
Fair enough, they did use to have this policy, and now they technically do allow them, but with so much rigmarole that they de facto don't.
Yes, but sqlite has always done things this way, and is in a stable place, while Ladybird is a rapidly developing new project, a good chunk of which has been done by outside community members.
Absolutely true, but I suspect SQLite has no issues with funding, while projects like Zig and Ladybird are not in that same position, and if you don't play it smart, you risk either running out of funding, or having to accept requests you would never agree to otherwise.
Ladybird seems pretty well funded as far as I've been able to tell. In my personal experience it's surprisingly easy to find funding when you can demonstrate any sort of competence building these types of projects people want to see happen.
Future will tell if it's the right move, but I do think running large open source projects has changed with LLMs, the quality of contributions has dropped precipitously and managing that is time consuming as a maintainer. It's up to every project to deal with that, somehow, and going closed-contributions may not be that bad of a move, especially if you're working toward some concrete goal with a finite runway.
I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler.
Look at the list of sponsors and make an educated guess. I find a few of them problematic in other ways, but don't see a group here who'd benefit from a rug pull on a browser.
I do wonder what's really behind the change. For a project that brags each month about the number of different (and new) contributors at the start of their status reports, this is a very abrupt about-face. The explanation they've given seems incomplete, to say the least.
Hi Loris, I'm paid to do (some adjacent variation of) opensource, meaning my employer is a commercial distro called SUSE and day job isn't exactly writing browsers, compilers or dbs, more like maintaining "downstream versions" of the above. Salary over here comes from corporations paying for support. That's to characterize/illustrate to my POV (blind spots included); own opinion follows.
Both Zig and Ladybird are trying to find a way forward in a future none of us asked for. I sat comfortably under a rock for years and quite frankly didn't see any of this coming (sounds so naive in retrospect.. almost cringe). Never the "right thing to do" has seemed so unclear.
My question for you and Zig, quite a rhetorical one I admit (like "agree to disagree"), is you can't tell apart an LLM PR from a handmade one. Low effort garbage sure, but "I'll ban AI" requires you to be able to run some sort of Turing test which to be frank me and my claude pro license can pass hands down.
What "I'll ban AI" does is, the moment one gets caught having sent LLM code and claimed to be handmade, you can go after that person and their reputation. Is this how you want to spend your time? Like, we're gonna have the equivalent of Karl Jobst (Australian youtuber who uncovers speedrun cheaters) for people who pretend to code by hand and use LLM instead.
You won't prevent LLM PRs, you're shifting the game into "catch me if you can."
Do I like reading Andreas making a rugpull wrt Ladybird? My first reaction was, chills down my spine. Second reaction, guy has balls gotta give him that. LLM assist and trust is a real real real problem and I want to see both people like you at Zig and Andras with Ladybird thinking out of the box because within the box, there is nothing good to see.
No, that's not exactly the right comparison. No one insists that you proactively have to perform witch hunts. (Okay, some people certainly do, but I don't, and disallowing slop PRs isn't the same thing.)
Saying that you disallow LLM generated PRs or require a full disclosure of LLM usage is about establishing a baseline of rules.
If someone goes ahead to send the pull request either way, this implies that 1) they did not read the contribution guidelines and are not familiar enough with the project, in which case it will most certainly be obvious, or 2) they are actively trying to deceive people about their LLM usage.
If they are in the second category and no none notices, then that's arguably fine, or at least not a significant source of harm. Like, the point isn't to catch "everyone", just like our "don't steal stuff" laws don't mean that we need cameras everywhere to catch every last thief.
Again, the point is the baseline of getting to say "So you slopped it up, knowing that we don't want you to slop it up?" and to decline new contributors (or ban people) on that basis without needing to have a large discussion about what the rules "should" be every single time.
I think the biggest problem is that anyone who will submit a slop patch is definitely someone who doesn't read contribution guidelines. So then they keep on coming anyway...
you can't tell apart an LLM PR from a handmade one. Low effort garbage sure, but "I'll ban AI" requires you to be able to run some sort of Turing test which to be frank me and my claude pro license can pass hands down
The same can be said about artisanal plagiarism, or – more generally – about the declaration that submitter holds the copyright to submitted code and has right to publish it under project's license (either a formal declaration like a DCO/CLA, or implied by submitting code to be merged into an open source project). Does this mean that projects should explicitly allow plagiarized/"pirated" submissions too?
[...] declaration that submitter holds the copyright to submitted code and has right to publish it under project's license [...]
I don't think this is a real issue but I haven't read the ToS of Claude or ChatGPT to know for sure. Are there concerns that the code is not owned by the LLM user/corporation but it's owned by the LLM creator? That wouldn't make sense since the LLMs (a) cannot bear responsibility (i.e. appear at court) and (b) these models are trained primarily on open (and nowadays judging by the ubiquitous usage by startups, probably closed) source code.
I doubt Uber, to mention a random example, would use LLMs extensively if that was the case.
Last but not least, at this point, I assume that any kind of code most engineers write using their editors have been written in some howto, stack overflow, other project in the exact same fashion. Is that plagiarism?
Hi, I think the parent commenter isn't saying "yo if you use LLM we've got a copyright situation let's discuss."
I think they meant it as an analogy (ofc they're welcome to correct me): there are rules you accept and abide to. Project demands you to not plagiarize? You do not plagiarize do you. People generally don't object to such rule with "A-ha! I'll plagiarize all I want, catch me if you can."
So they say same goes for Zig and AI ban. They kindly ask you to not use LLMs, you do not use LLMs. "It's easy to break the rule" has never exonerated anybody from commission of wrongdoing. "Your honor, I'm aware I broke the rule, but it was easy, so I thought it was OK."
I think this is the argument being made. Unrelated to LLM v. copyright infringement. More like general morality and rules of behavior in community/society.
Personally I do maintain that a rule requires a reasonable path to enforcement, for practical reasons, which I'm not seeing, but it's an opinion. It's being discussed by other commenters, there are several other point of views.
Both Zig and Ladybird are trying to find a way forward in a future none of us asked for. I sat comfortably under a rock for years and quite frankly didn't see any of this coming (sounds so naive in retrospect.. almost cringe). Never the "right thing to do" has seemed so unclear.
Ladybird asked for it and gratefully accepted it.
Ok I think I see where this is from, there is clearly disappointment geared towards Ladybird and Andreas for their unconditional embrace of AI-assist. Now, give me some rope here, but I read your comment as: I don't like AI-assist, Andreas does, I don't like Andreas, Andreas traitor (again, you didn't say any of this, I did, but please bear with me, rope).
My remark here is: the same person (project really, but c'mon it's him calling the shots) embracing AI, is the dude who wrote an entire OS, by hand, from scratch, for fun. Not really prime-time ship-shape OS, but not toy either. And built a community around it, showing that software craftsmanship can be a happy place to find peace in. The whole point of Serenity was to be pointless. You're characterizing him (well, again, you didn't say, but with such a short message you leave us wonder) as some "vibecode a saas business and scale it to $10k/day" kinda guy.
I am strawmanning, 100% aware. Point being: there is baby, there is bathwater. Andreas has done good stuff. He has more than proven that he's not a grifter, and he's committed. The shit is very polarizing, and sometimes looks to me the two camps have more in common than what's immediately apparent.
As you admit, you're putting a lot of words into my mouth that I didn't say.
You're drawing the wrong conclusion from it.
Perhaps that's all my fault for adding such a brief comment and a link. I'll give you more, and ask that you argue against my actual points now if you care to, instead of your strawman.
I find the current LLM industrial complex problematic in several ways that don't really matter here. To say that "I don't like AI-assist" leaves a ton of nuance aside, but it's fair to say that I think the trillion dollar industry has serious downsides that outweigh any productivity gain they could feasibly offer. I think fully embracing them is a mistake, but I'm judging the action, not the person with that.
I think that by enthusiastically promoting the current LLM industrial complex, the way Andreas and others have, and encouraging others to use it, the way he did in the X post I linked, you're going all-in in a different way than someone who personally uses it where they see some utility.
My comment was really much simpler than you're making it out to be, though. The comment I was replying to and that I quoted said that "[...] Ladybird [is] trying to find a way forward in a future none of us asked for."
"future" in that presumably refers to Andreas' complaint that:
For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.
AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.
My point is simple: by enthusiastically promoting LLM assistance in coding, and encouraging others to use it too, Andreas was asking for people of all skill levels and motivations to use that in their work. Very foreseeably, that generated the slop contributions to his project, in reaction to which he is now cutting off his contributor pipeline. He's reacting to a future that he very explicitly asked for, not "a future none of us asked for."
first of all they could have just banned LLM usage only in PRs from untrusted contributors
It's not possible to ban LLM usage because there is no good mechanism to enforce it. If an untrusted contributor puts up a PR and says that it was written without AI, how can you know that's true without spending time or money on it? If banning AI contributions was easy, I don't think so many open source projects would be going through such tribulations.
even the best LLM: is a cost, not just free value, and the price of tokens is increasing
I've been using Gemini for a while and Google is so aggressively subsidizing it that you get a substantial amount of free tokens every day. I haven't paid Google a dime. Similarly, you can still get a lot of free LLM usage on the web interfaces for chatgpt, claude, etc. Unfortunately a large chunk of code is not even proof that the contributor spent a few dollars on tokens, since there's so much available for free.
Thanks for putting this into words! I was feeling uneasy about the change as well. I don't see how it can be sustainable in the long term, unless they manage to replicate the SQLite story...
I think most projects never attract substantial contribution. And if someone really wanted to work on Ladybird (not just drive by a patch that never lands) they can still put in the years of social effort to get included I expect.
I looked into Ladybird org's bylaws (https://ladybird.org/assets/documents/public-records/2024-03-25-bylaws.pdf), and I've been dismayed to learn that Christopher Wanstrath is a co-BDFL of the org. I didn't pay close attention before, I was under the impression that he only donated $1M and helped set up the org, which is perfectly fine by me.
But he's in fact a Designator. From my reading (IANAL), he's guaranteed this position for life (unless he resigns or becomes incapacitated). Designators make decision by majority vote, which, at 2 designators, means that both need to agree. Designators designate Directors, remove them, and their consent is needed to change the bylaws. So he effectively has an unchecked veto power over the nonprofit. So does Andreas, but Andreas is the author of a substantial part of the work, cares about it, and is not a billionaire. Wanstrath is a billionaire, pledged to donate a tiny fraction of his wealth, and is not involved operationally with the project, and has the same power.
Unless there's a good legal reason I'm missing, this does not sound like a great governance structure for an open source project.
I understand the change, but wonder how it's going to work out long term for projects which closed for contributions recently. At some point some of the core trusted people will leave and I'm worried they won't have a clear successor because there are no proven long-term contributors. They're on a path to burnout and abandonware by default so I hope they'll find a way to overcome that.
Hopefully the LLM crazy will stabilize or die down and/or (possibly other) projects will figure out a sustainable way to deal with the onslaught of "contributions". So I assume this is only temporary (and the post seems to imply that they don't expect to stay like this after the stable release).
I just don't see that as leadership of any kind.
It isn't a step in the right direction. It isn't an idea about how we can all live together. I know the pressures are real, but it still disappoints me when the response feels cynical and defeatist rather than energetic and hopeful.
Why do you see it as not the right direction?
Open software stays open when many people contribute. I don't use AI at all, ever and they're slamming the door just as much in my face. How am I supposed to feel about that? Sure sounds like if I want a community I can belong to their message to me is: "look elsewhere"
As part of this change, we will close all currently open public pull requests.
Yikes. Several years ago I had a PR closed when the project in question decided they didn’t have the resources to review PRs. It stings badly and it’s not fair to the contributors who have put work into those PRs.
I understand it might sting but don't think it's justified to call it unfair, unless the maintainers actually requested someone to make those PRs.
I've seen a lot of commenters on other sites (maybe not maintainers, I suppose) indicating that Ladybird actively wanted people to contribute things that helped them get closer to alpha, like fixing broken web compatibility tests, and the like. My impression of Ladybird has been, up and until this point, that they actively wanted new people to jump in. Maybe that's never been the case, and these people have simply been speaking out of turn, but I always believed the project to welcome new contributions with open arms.
If they have actually made a commitment somewhere to actually review all incoming PRs, that's different of course, but I doubt they have done that, and I think everyone should understand that any commitment like that would still come with a limited capacity, meaning there could still be a chance nobody ever looks at your PR.
The given rationale is understandable, but the decision is worrying. Not necessarily bad (if it’s temporary and a different tradeoff is struck later), but worrying.
Not the first worrying sign, I’d say. I feel similarly about their LLM-assisted rewrites to Rust. Sure, unlike Bun, they were relatively cautious - a component of reviewable size, clear inputs/outputs, running the new and old component in parallel to catch discrepancies. Still, not something I want to see in a browser engine.
I’m rooting for Ladybird. I do want to see a new browser engine to challenge the oligopoly. But also, good to see that Servo is also progressing nicely (after years of stagnation) in case Ladybird goes sideways.
I'm rooting for Servo. Remember who's the lead behind Ladybird, and the opinions they hold – even if it becomes successful, I don't want those behind one of the most important applications on my machine. And at least for now, there's that.
What opinions does Andreas hold? I've heard him described as a "tech bro", but if there's anything more worrying, I missed it.
I only know Andreas as the guy behind his SerenityOS live-coding videos (which I found impressive and inspiring)
You could look for Drew DeVault's post about Ladybird for some opinions he's expressed. I believe there was a more substantial compilation of statements somewhere else, but couldn't find it in 30 seconds.
As a very basic litmus test, look at some of the tabs they're showing off in this tweet: https://xcancel.com/awesomekling/status/2061376386623737905
(DHH & 4chan, i.e. well known far right to fascist bastions)
They use ai slop for their implementation of rust, they are pro DHH ie white supremacy and anti lgbt, they seem quite aggressive. Don’t see this one going far.
I think they will be missing out if there isn't a funnel to become a contributor from the outside, even if it means a more serious commitment than just dropping drive-by PRs. That would increase the talent pool who knows the code base for when they want to add developers as well as letting outside organizations scratch itches that isn't prioritized by the core team, which will both help adoption as well as offloading work.