[dragontamer]

There must be some degree of communication from customers to developers. Even if it is a free volunteer service.

Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary.

This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated.

Problems aren't solved by shutting up and ignoring things. And based on the discussion in this topic, it's clear there's a lot of people who are worried about rsync code quality here.

[lukaslalinsky]

Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too strong, block people. Rsync has been maintained for a very long time. Bugs happen, even regression bugs happen. People don't get to dictate how should the volunteer do development.

[akerl_]

If I were the rsync maintainer I’d probably set the repo to only allow issues and PRs from prior contributors until people learn to behave.

[llbbdd]

If I were the rsync maintainer after this I'd unpublish it everywhere I had control over, delete the repo and turn off my computer to go walk in the park. The linked thread is insane.

[lukaslalinsky]

Just going away from computers for a few days should be enough, the mob will get tired soon.

[dragontamer]

Yes. That's called firing the customer in my line of work.

This doesn't seem egregious enough to fire the customer.

[akerl_]

Again, this is not work and they are not customers.

This is somebody spending their free time on code they enjoy and then putting the result online.

The reason businesses are careful about which customers they fire is because they want to keep having customers. Open source maintainers have no reason to deal with that shit.

[account42]

No this is part of the foundation that many open computing systems are built on. It's long past being just someone's experimental personal repo.

[akerl_]

How many people have to star your repo before it's no longer yours?

[dragontamer]

Then he can fire the customer. By simply closing the issue.

[dragontamer]

And it seems like regressions that lead to rsync losing data is just as serious.

Again: we are talking about rsync here. This new methodology being used this year seems to be associated with a regression (ie: Data loss since this is rsync after all....) that likely wouldn't have happened any other year.

Or at least: the regressions at play are consisting of thousands of lines of changes that was only navigated by Claude later down in the discussion.

We are reaching the point of AI developed code that requires AI itself to analyze. One step at a time. It's right for the open source customers who are used to understanding changes and smaller patches than this.

[pibaker]

Before you call yourself a customer of an FOSS project, perhaps show us the receipt that a monetary transaction had actually taken place between you and the developer.

Otherwise, you're just a beggar. And beggars don't get to choose.

[akerl_]

These are not customers.