Hi Acrosync folks (gchen?),
As a frequent user of rsync on linux, I was glad to see that there's a native rsync client for Windows. That, by itself, is an achievement, and I see that Acrosync has some other interesting features.
However, as a prospective customer, I suggest that your product gratuitously misses the mark by putting up several obstacles:
1. It can't be used like rsync. A large proportion of prospective customers already know how to use rsync, which means, from the command line, using the suite of options that rsyn offers. If Acrosync was usable from the command line, those customers would be able to adopt and use it immediately. You would hit a sweet spot if customers could quickly acertain that Acrosync would immediately solve their problem, at just the cost of the product, and zero hours of learning and uncertainty of how to make it work for the desired workflow.
Instead, Acrosync goes out of its way to not be operable like rsync, and throw into doubt whether it can be effectively used in a workflow that the rsync-savvy user already knows how to set up.
2. The GUI does not look like it would work for serious use. Apparently every rsync task one has every set up, and might want to use again, continues to appear as a tab. How is that going to work after configuring 20+ tasks? There seems to be no mechanism to just maintain a bunch of task specifications in a directory somewhere that one can open as needed. There's no way to copy and paste tasks.
3. The task specifications (profiles) are stored in the registry. GAAAAA! A thousand times "No!" on that idea. (a) I don't every want data like this jamming the registry. (b) I can't do anything (easily) with the registry that I can do trivially easily with files, such as copy them, edit them, version them, use them on another machine etc.
This is a key conceptual problem: The term "profile" suggests something that users would only ever have a few of, and they rarely change. But the thing being configured here is not of that type -- it's a task. A user might have dozens of them, only some of which are long-term, others are ad hoc, some need to be composed by scripts or programs, and so on. Forcing Acrosync's functions to be available only through the profile GUI severely underestimates the uses that customers could be putting it to (and inclined to pay for.
4. Acrosync has a scheduler, but if I want to schedule work on a Windows machine I already have a way to schedule work, and I want Acrosync to run subsidiary to that, which it is poorly suited to. Yes, I could set up profiles that have the other scheduler call Acrosync on those profiles. But those profiles then show up in the tabs, inviting disruption when Acrosync is used manually. And the tasks as known to the scheduler don't contain the details of what's copied where (just the name of a task), and nor can they be (easily) composed by programs or scripts.
5. It can't be used like rsync. Yes, I'm repeating this one, because the complaints of items 2, 3 and 4 are really side effects of the issue that Acrosync can't be entirely driven from the command line (plus additional parameter files, such as include/exclude lists, like rsync). If it could then there would be no problem with tabs being unable to scale with number of tasks, and task info being inconveniently stored in the registry.
In short, Acrosync perceptively identifies a hole in the market -- an rsync tool for Windows. But then misidentifies what that demand is about. It's not simply "let's have a tool on Windows that can move files around quickly". It's that we need a tool that fits into the rsync ecosystem with minimum hassle, an ecosystem in which rsync is run from scripts and cron jobs etc.
So, while I applaud your efforts to produce a native rsync client, I can't help feeling you're missing a significant proportion of the demand by omitting the command line interface.
Graham
Comments