Comment by jeremyjh
9 hours ago
> 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.
You state these things as if they are facts, but they are completely contrary to the lived experience of open source maintainers - not only my own and the TFA's but quite a large number of others who have shared similar pieces.
Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years that forms the basis of your expertise on this matter?
Yeah, I am employed by an open source company (to be clear not open core) and most of the external code contributions we get are a net cost for us. It takes more time to review than it would have taken for our team to code and review.
The real value we get from being open source is high quality bug reports and trust from our customers, not the external contributions. The only reason we welcome external contributors is marketing and generally being welcoming. If LLMs make this cost even higher for us then we might have to stop accepting external PRs.
> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years
Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs).
There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed.
From the other side, I have spent thousands of hours debugging and writing PRs to over 100 FOSS projects (e.g. glibc, busybox, util-linux, lz4, GHC and tens of Haskell packages, Jenkins, Chromium, GTK, Consul, OpenCV, Signal, many more).
Many of them are small or medium fixes ("drive-by fixes"), where you propose a PR, the owner reviews, says "great, thanks", and the bug gets fixed.
This is a fundamental workflow for open source work. The project gets free contributions and time investment outsourced to "the community" who fix its bugs, the developer-users/community get their problems fixed upstream, permanently.
This not possible for projects that don't have an easy way to submit code with low effort for both sides.
Accepting drive-by fixes is what clears up developer time and helps clear out the countless small issues in software.
If AI slop PRs are a problem, it seems better to establish clear rules and reject contributions that don't follow them with a single click, rather than banning developer contributions altogether. It seems to work acceptably for nixpkgs so far.
Thanks for your work on nixpkgs but I think that shapes your perspective quite a lot - its a very different project from Ladybird. Not to belittle your contributions there but the majority of commits there are a few lines of code and much of it is declarative. I'm sure a lot goes into review of entirely new packages and there are some complex interactions between dependencies to consider on some changes but not in a program structure or logic sense. Vibe slop may not be so much an issue there.