2 ms·

> Why do we need AI here? As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do i

> Why do we need AI here? As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1] https://github.com/RsyncProject/rsync/issues/929#issuecomment-4582947505 https://github.com/RsyncProject/rsync/issues/929#issuecommen... > The issue tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive. https://github.com/RsyncProject/rsync/issues/929#issuecomment-4582951270 https://github.com/RsyncProject/rsync/issues/929#issuecommen... > @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude. [1] https://news.ycombinator.com/item?id=43077833 https://news.ycombinator.com/item?id=43077833

fzeroracer 5mo ago
[flagged]
- lukaslalinsky 5mo ago
  The result might be closing bug trackers for the core open source projects. Or make them invite only. Even fundamental projects like Linux or LLVM accept AI contributions.
- throwaway7356 5mo ago
  > But I think if people want to continue using LLM shit, they need to be ready to weather ALL criticism that comes with it. And if they don't then too? Because why should they not have to weather ALL "criticism" that comes with writing open source software? Apparently there are lots of people defending comments that "are obviously out of line and [...] ragebaiting". That sure makes being an open source developer enjoyable!
ddosmax556 5mo ago
I agree, if I was the maintainer this would be an extremely tiring community feedback. People coming in "I encountered a bug, I don't know what the bug is but I thought about it for a second and it's obviously your descision to do xyz". As a maintainer, what are you supposed to do? It's not more useful than a ticket "somethings wrong idk what" which is useless enough to close without further action. But it puts the burden on the maintainer to a) figure out what's wrong based on basically no data whatsoever, then b) if they find it out figure out why then c), and that's the tiring part, review their process and create a defense for their approach, or admit that that thing that random user felt after trying out your software for 10 minutes is right, and that you were what? stupid to even think this would ever work? They never asked for any of this, and they're already doing so much work for free. If the rsync maintainer reads this: You're doing incredible work and humanity appreciates your obviously incredibly competence in it, and not everyone feels the way these people do. Moving to agentic workflows is obviously the right step and it already provides enough benefits to do it already. And mistakes are bound to happen (if the issue is even a mistake!) and there will always be people who cannot comprehend the power of agents and who will point the finger saying "I know it from the start! I've worked with these tools for 2 hours already and I can see they don't work! Idk why you think they do!". They're wrong. But mistakes will happen that otherwise wouldn't have - but that's the learning experience.
- ruszki 5mo ago
  I don’t know the details of this exact instance, but saying that there are reliability issues is a valid feedback if reliability plummets. As far as I know, nobody with data claims that vibe coding doesn’t affect reliability negatively. People will connect these two things. Many times, when reliability doesn’t plummet really. For example, there were huge negative news about a Samsung phone a few years back, that it easily causes fires. Sales were affected by this. Interestingly, next year, they released basically the same thing under different name, and complains were never that loud again. And as far as I know, when they were loud, there was nothing special about that particular model regarding this. So it’s possible that outrage is not validated at all. They will also connect these, when reliability plummets, but it’s not because of vibe coding. And they will connect, when it is the real culprit in general, but their problems are not affected by vibe coding. And of course also when vibe coding really causes their problems. In any case, the original statements will be true. Do we really want to make a product less reliable to implement features and bugs which we deemed not that important before? Especially with a stable product? Of course, these on the maintainers, but it’s interesting that forcing AI and their consequences on us - like how Microsoft, Google, etc do - is the default, and not the other way around according to many in this thread and others.

fzeroracer 5mo ago

[flagged]

lukaslalinsky 5mo ago
The result might be closing bug trackers for the core open source projects. Or make them invite only. Even fundamental projects like Linux or LLVM accept AI contributions.
throwaway7356 5mo ago
> But I think if people want to continue using LLM shit, they need to be ready to weather ALL criticism that comes with it. And if they don't then too? Because why should they not have to weather ALL "criticism" that comes with writing open source software? Apparently there are lots of people defending comments that "are obviously out of line and [...] ragebaiting". That sure makes being an open source developer enjoyable!

ddosmax556 5mo ago

I agree, if I was the maintainer this would be an extremely tiring community feedback. People coming in "I encountered a bug, I don't know what the bug is but I thought about it for a second and it's obviously your descision to do xyz". As a maintainer, what are you supposed to do? It's not more useful than a ticket "somethings wrong idk what" which is useless enough to close without further action. But it puts the burden on the maintainer to a) figure out what's wrong based on basically no data whatsoever, then b) if they find it out figure out why then c), and that's the tiring part, review their process and create a defense for their approach, or admit that that thing that random user felt after trying out your software for 10 minutes is right, and that you were what? stupid to even think this would ever work? They never asked for any of this, and they're already doing so much work for free. If the rsync maintainer reads this: You're doing incredible work and humanity appreciates your obviously incredibly competence in it, and not everyone feels the way these people do. Moving to agentic workflows is obviously the right step and it already provides enough benefits to do it already. And mistakes are bound to happen (if the issue is even a mistake!) and there will always be people who cannot comprehend the power of agents and who will point the finger saying "I know it from the start! I've worked with these tools for 2 hours already and I can see they don't work! Idk why you think they do!". They're wrong. But mistakes will happen that otherwise wouldn't have - but that's the learning experience.

ruszki 5mo ago
I don’t know the details of this exact instance, but saying that there are reliability issues is a valid feedback if reliability plummets. As far as I know, nobody with data claims that vibe coding doesn’t affect reliability negatively. People will connect these two things. Many times, when reliability doesn’t plummet really. For example, there were huge negative news about a Samsung phone a few years back, that it easily causes fires. Sales were affected by this. Interestingly, next year, they released basically the same thing under different name, and complains were never that loud again. And as far as I know, when they were loud, there was nothing special about that particular model regarding this. So it’s possible that outrage is not validated at all. They will also connect these, when reliability plummets, but it’s not because of vibe coding. And they will connect, when it is the real culprit in general, but their problems are not affected by vibe coding. And of course also when vibe coding really causes their problems. In any case, the original statements will be true. Do we really want to make a product less reliable to implement features and bugs which we deemed not that important before? Especially with a stable product? Of course, these on the maintainers, but it’s interesting that forcing AI and their consequences on us - like how Microsoft, Google, etc do - is the default, and not the other way around according to many in this thread and others.