I think it’s unreasonable to complain that the guy is not working enough for free.
I think it’s reasonable to alert people that rsync is not being properly maintained anymore and to seek alternatives.
I would prefer the maintainer to announce publicly that he can’t maintain the project anymore and is looking for help/someone to take over instead of breaking the project silently.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync’s existence? Your comment implies that tridge didn’t call for help before, which is far from the truth.
This is thankless maintenance on critical software, not some *-arr toy project for hobbyist self-hosters.
The thing with old, critical software is that after some time people don’t really want to dig through decades of C code and prefer to write something new using modern tools. Those projects get plenty of support because people actually do want to work on them. If no one wants to work on rsync than what the maintainer is doing now is just prolong it’s agony a couple of years. I would say he should do the minimum work, announce end of life date and move on. People that need tools like rsync will develop something.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:
rsync: 99.0%
restic: 93.2%
rclone: 87.5%
union: 82.9%
syncthing: 74.4%
As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That’s just the nature of most open-source software.
Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync
People that rely on rsync start looking for alternatives
They try to switch and figure out what functionality is missing
They contribute to some of the alternative to fill the gaps
For example, I’m about to setup some syncing for my homelab and I will not use rsync for that. That’s why talking about the state of rsync is important. As I said, it’s not about attacking the dev for not working hard enough. It’s about long term planning.
I remember when the maintainer for discord.py stepped down. He eventually stepped back in because no one wanted took over the project and he didn’t want to see it die. This was before the current AI era, all someone had to do was continue to develop it.
I think almost everyone will do step 2 and 3 but not step 4.
The fact that open source exist and functions so well for decades shows that people do step 4. If no one wants to step in it usually means the project is not important.
I don’t know the degree to that, but bugs do happen occasionally either way as long as there are changes. In the article, they explain why the changes are necessary. Prioritizing security over no-change-stability seems reasonable and warranted.
yes, there were regressions in some use cases of rsync in the 3.4.3 release. I quite deliberately tried to err on the side of fixing security issues for that release, and there were some valid (but unusual) use cases that got caught up in the changes.
So as I said, I don’t think it’s fair to scream at him to work harder. I do think it’s fair to worn people that rsync is having issues with stability. The author claims he knows what he’s doing and it’s all on purpose. You are free to trust him and ignore the whole affair. Other people may prefer to look for alternatives.
I think it’s unreasonable to complain that the guy is not working enough for free.
I think it’s reasonable to alert people that rsync is not being properly maintained anymore and to seek alternatives.
I would prefer the maintainer to announce publicly that he can’t maintain the project anymore and is looking for help/someone to take over instead of breaking the project silently.
But where will the maintainers for these alternatives come from, when barely anybody has stepped up in the 30 years of rsync’s existence? Your comment implies that tridge didn’t call for help before, which is far from the truth.
This is thankless maintenance on critical software, not some *-arr toy project for hobbyist self-hosters.
Universal Healthcare would increase the pool of willing developers by an order of magnitude here.
No disagreement here but I’m not sure that’s on the menu right now
Either Universal Healthcare is on the menu or society falls apart, pick one.
https://github.com/rclone/rclone
https://github.com/restic/restic
https://github.com/bcpierce00/unison
https://syncthing.net/
The thing with old, critical software is that after some time people don’t really want to dig through decades of C code and prefer to write something new using modern tools. Those projects get plenty of support because people actually do want to work on them. If no one wants to work on rsync than what the maintainer is doing now is just prolong it’s agony a couple of years. I would say he should do the minimum work, announce end of life date and move on. People that need tools like rsync will develop something.
Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.
Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:
As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That’s just the nature of most open-source software.
Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync
How I imagine this:
For example, I’m about to setup some syncing for my homelab and I will not use rsync for that. That’s why talking about the state of rsync is important. As I said, it’s not about attacking the dev for not working hard enough. It’s about long term planning.
I remember when the maintainer for discord.py stepped down. He eventually stepped back in because no one wanted took over the project and he didn’t want to see it die. This was before the current AI era, all someone had to do was continue to develop it.
I think almost everyone will do step 2 and 3 but not step 4.
The fact that open source exist and functions so well for decades shows that people do step 4. If no one wants to step in it usually means the project is not important.
The trouble with some of those projects (e.g. unison and sun thing) is that they don’t solve the same problem, not really.
A rewrite with modern tooling would be better done if it was incremental.
Is that your assumption given that they’re using AI? Because it’s not at all what I have taken away from their article.
Is “not properly maintained anymore” your interpretation of them using AI? Or what do you base that on?
The whole story started because rsync stopped working for some users. That’s “not properly maintained” in my books.
I don’t know the degree to that, but bugs do happen occasionally either way as long as there are changes. In the article, they explain why the changes are necessary. Prioritizing security over no-change-stability seems reasonable and warranted.
The author said:
So as I said, I don’t think it’s fair to scream at him to work harder. I do think it’s fair to worn people that rsync is having issues with stability. The author claims he knows what he’s doing and it’s all on purpose. You are free to trust him and ignore the whole affair. Other people may prefer to look for alternatives.