Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- You are lucky that you got valid PRs that actually fix something.
I got PRs that either never worked or even broke stuff
by kkapelon - One thing that really interests me is declining to issue CVEs. I get a lot of AI submitted security issues and they all want CVEs. But some are simple idor to access information around an age rating on selfhosted software for friends and family.
Does anyone have any advice when to decline CVEs?
by majora2007 - While exploring an open-source project recently, I noticed a bug in the initial setup. I asked Claude to verify it, and the AI confirmed the issue. When Claude asked if I wanted to file a bug report, I agreed, assuming it would simply generate a formatted text block for me to copy and paste. However, I soon realized it had actually submitted the issue directly to GitHub. It turned out I had the GitHub CLI installed and was logged in with my work account.
Out of curiosity, I then asked Claude to draft an enhancement request for a new feature. It created a highly detailed issue and went on to generate the corresponding code for the enhancement.
I haven't submitted a pull request because the code is written in a language I don't know. Part of me considered submitting it anyway since it works and could be useful, but after reading this post, I think I'll just keep it under wraps.
by krisgenre - > it had actually submitted the issue directly to GitHub
Did you fix that? Apologize to the people running the repo and all?
by hypfer - I think opensource has decided to become big corporate cheerleader for a while and not actually done things strictly in the interest of users or developers, but providing the ideological justification as to why big companies can use their code and not give a dime back. I think aside from free software there could have been a movement where contributing to a free-software project would have allowed contributors to get payed and this would have to preclude companies simply using code as they can in say the MIT license and not give back.
Instead opensource is full of cynical projects and real important projects that do amazing work with maintainers who shoulder a great burden having to listen to people bitch about them for features and fixes while giving nothing and dealing with bad PR's (or even just having to evaluate good and mediocre PR's). Often the only pay is that you can go to HR and shit corp with your CV and say "Here is what I have done, can I now be treated like a bitch for more money".
I think opensource has allowed a lot businesses to treat developers with contempt and this is fully manifest with the way they conceive of AI agent's and Open source has probably become a vector for demoralization and devaluation more then anything.
by kodoman - I also maintain a popular open source repo and have seen similar. If I receive a low effort single-pass obviously-Clauded PR (many people (agents) don’t even bother using the AGENTS.md file I provide right in the repo?!) with no associated issue I also have no qualms closing. I do generally leave a short note about why I closed (volume of these is around 5/week) showing how far off they (Claude) was and encourage opening an issue where we can start a discussion which rarely happens for the drive-by folks. So I totally feel this but I find myself more disheartened by the practice than angry. It feels like slowly watching open-source go the way of email. Open and free until no-cost spam ruined the inbox for everyone...by J253
- Interesting analogy.
Sounds like an opportunity for GitHub/others to better filter these.
by jbs789 - > If I receive a low effort single-pass obviously-Clauded PR (many people (agents) don’t even bother using the AGENTS.md file I provide right in the repo?!)
Claude doesn't read AGENTS.md automatically, it only looks for CLAUDE.md.
by bhaak - This makes sense. Apart from the original thing, I no longer upstream anything. It just takes comparatively more effort than maintaining a private fork with my own idiosyncratic fix. This must mean that even small fixes that non-contributors would make in the past are just happening off the books, so to speak. e.g. I upstreamed a tiny fix to Thrift codegen because some function could be much faster. These days I wouldn't bother. I'd just fork and leave upstream to be upstream.
I suspect many people are like me since it feels like a very normie position to take. That means that contributors are even more likely to be useful because both the drive-by genuine contributors have chosen otherwise and these contributors have increased.
It must be quite painful to be an open source maintainer right now. One wonders what to make of such projects in a future where a feature-list is a sufficient prompt.
by arjie - How could it take less effort to maintain a fork? You have to merge the upstream in every week and fight endlessly on conflicts with your patches.by jspdown
- Discussing the issues, achieving consensus, making sure the fix fits the existing patterns and actually warrants the change, etc. These are and have always been a challenging part of contributing to open source. Typing code in your private fork that satisfies your “idiosyncratic fix” has always existed and been always the easier aspect of such changes. Chances are many of these changes would never be accepted into the repository anyway in the past.by geraneum
- I ran through exactly this thought process & LLM based resolution just 8 hours ago with a segfault compiling a project which likely doesn't care about the given platform combo much.by zamadatix
- Fair enough not to want to get involved but seems problematic for 2 reasons :
- code gets re-regenerated over and over again, so waste of resources
- no signal back upstream that it is indeed a genuine need that is in fact so important some users did dedicate resources for it, maybe more users would benefit from it
by utopiah - I’ve heard about similar issues with Hacktoberfest’s T-shirts back in 2020, but it was not as automated back then: https://news.ycombinator.com/item?id=24643894by yeputons
- I was thinking the same. The amount of effort people went through just for a t-shirt. Now you can try to boost your career, far more valuable, and even with less effort. Of course it will happen, unfortunately.by matsemann
- I think the author meant 'burnish' there, which is a clever way of showing they didn't use AI :-)by ChuckMcM
- Furnish makes more sense.by alansaber
- Hi Neil, fun to see you on HN. I agree with your points and I you summarized it very well as "Ultimately, open source is built on trust".
AI is destroying trust in open source and many other areas and I think this will discourage teams from publishing their source code in the future.
On the other hand, personal connections are becoming even more important, which is unfair to the younger generation and people who don't live near tech hubs.
by timokoesters - Today's conception of open source is different from the original anyway. It used to be "we made this thing, here's the code" but now it's turned into some kind of weird parasocial thing more akin to Facebook.by inigyou
- So the fixes are still fixes, but we (I am also a OSS maintainer) are unwilling to accept them as they boost the contributor’s status where we think the merit is very or extremely limited.
Why not have these PRs counted differently (by the platform), and/or colored differently in the timeline(s) thus made less visible or more clear?
by smooc - The whole idea of "counting PRs" as a vanity metric is flawed because vanity metrics are flawed.
I don't think that there is a technical solution to be found here, as the problem is anything but technical.
__
A hack/trap:
Comment "Ah yes thanks a lot for the hint :)", then make the changes yourself.
Then see how the person reacts to that.
Hack the grifters. Hack the planet.
by hypfer - These fixes, regularly destroy the architecture, accrue bloat for little gain, refuse to rewrite while demanding to rewrite- and many other such funny noises. Most code contribution by LLMs is garbage if you long-term care about the project. Look at closed source projects that ingest all this madness - windows with its seconds to open the explorer and other catastrophes.by 21asdffdsa12
- > So the fixes are still fixes,
maybe, the maintainer would need to review them to determine that, and that can be time-consuming especially because LLMs tend to provide walls of sometimes dense text
since the human submitting the PR (if there is one) couldn't be bothered to understand whether the change is a valid one (and therefore submit the change as their own work), why should the maintainer take on that work. if they wanted an LLM to find bugs in their code they could run it themselves with less work than sorting through LLM-generated PRs.
- I think what you're saying is fair, tbh. Imagine you put in months or years into a project to make it a quality piece of work. It develops into something notable and you took all the risk. Then someone comes along to fix a spelling error with a pull request so their name effectively appears on the repo as a "contributor." And you just know right after its going on their resume as "contributed to [...]" or maybe if they're bold "software engineer working on [...]" which implies substantial investment. Then you're effectively sharing credit for YOUR work with someone who did nothing. That is rage inducing. ((Of course: it probably is just juniors trying their best in this horrible industry.))
On the other hand: lets be careful not to dismiss valid but inexperienced attempts to contribute. Having someone want to genuinely contribute to your software is incredibly generous. If someone seems like they're trying its better to give advice than act like a snob because its not good enough. Often pull requests only need small fixes to get in, anyway.
by Uptrenda - Why not let them have the status boost? This isn't zero sum.by bwhiting2356
- Change is bad unless it's great.
Unless the change is an obvious improvement, it has to be worth the time for the maintainers to spend attention reviewing it (and supporting the code forever, and all the rest).
Even if these particular changes are "harmless" and easy to review, accepting them sets a precedent that encourages an unsustainable flood of AI-generated changes that will overwhelm the project.
by Arainach - IMHO, the days when open source contributions are often positive signal for hiring are long gone.
Actually, if I see someone doing open source like it's a performative career checkbox, that will not be positive signal, and could easily be negative. I understand that people will do what they need to do to get a job, but that pragmatic career checkboxing itself isn't positive. I will have to look for positive signal elsewhere for that person.
The problem is that our industry has gotten very bad at hiring, and now we have everyone playing all sorts of games with it -- rehearsing Leetcode interviews, bad faith open source contributions, feigning enthusiasm, spamming AI-tweaked resumes, outright cheating on interviews -- rather than focusing on doing good work, and being part of a team.
If you're involved in hiring, and you care about effectiveness and culture, consider pushing back against the prevailing dysfunctional big-corporate-cattle-herding practices. Especially if your company has no excuse to be big-corporate dysfunctional, and can't afford to be.
by neilv - The moment something becomes a clear signal for brilliance, it immediately stops being useful as it will be imitated.
Reminds me of this xkcd: https://www.explainxkcd.com/wiki/index.php/2899:_Goodhart%27...
by expedited123 - > IMHO, the days when open source contributions are often positive signal for hiring are long gone.
After reading your comment, I had a thought that the key could be to separate random, drive-by open source contributions (which are easily gamed by pointing a bunch of AI agents at GitHub) from committing to maintain a small number of open source/community projects for the long term.
by ValentineC - Doing good work leads you nowhere. You need to be in the game of power. Be visible, know every 3 levels of managers by name. Otherwise you’re only number in payroll’s sheet. Modern tech companies are not different from world war 2 era factories imho. Account xyz@bigcompany pushing lines of code to endless repo. No face, no name. Boring. Boring reasonable and reliable. That’s not what hiring people are looking for. You must be a rockstar, conference speaker and leader of few open source projects now. Skills, experience and good work ethic is not enough.by lnsru