On Sync 2.0's Pricing Model

[xtraeme]

I'm curious how VV, for example, would resolve the scenario you just provided.

 

I have a VVEngine schedule that does syncs every hour on the hour. If there is no conflict, VV silently copies the files over to the other machines easy peasey. When a merge conflict crops up VVEngine sends out an alert saying that a manual merge needs to happen.

 

This would require BT Sync to have knowledge on how Scrapbook interacts with files and how those files are formatted.

 

There is no reason for BT Sync to auto-attempt a merge. That would be awful. All it needs to do is keep a shallow history to show that the two files are no longer operating from the same base.

 

Computer 1 / Computer 2:

Hash 0: File A (rev. 0)

Computer 1:

Hash 1: File A + mid file edit (rev. 1)

Computer 2:

Hash 2: File A + data append (rev. 1)

BT Sync tries to merge:

 

Hash 1 != Hash 0

Hash 2 != Hash 0

Hash 1 != Hash 2 (obvious merge conflict, notify user to resolve the problem, rather than using whichever is newest -- which is what BT Sync currently does -- dangerously overwriting data).

At this point if BT Sync were doing things properly it would do one of two things:

1. Send out an alert that a manual merge needs to occur

2. Run a user-defined script to resolve the conflict. If the user defined script fails (return code 0: success, 1: failure), send out the alert in #1.

 

This takes time and still leaves you without a change because you have to pick only one of the files and discard the other. It's also clunky and depending on the number of conflicts can be very time consuming.

 

I am not sure if you have done software development work before, but if you have you probably know developers like to submit their code to Perforce (or to whatever SCM system they use) as early as possible because whoever checks in code afterwards has to resolve any merge conflicts that exist. The general rule of thumb is to submit code often because resolving complicated merges can become a nightmare down the road. Sometimes this is unavoidable. When significant code changes need to happen, it is a good practice to create a branch so updates from the mainline can be regularly merged in to the experimental branch to keep the two branches from diverging too much.

 

In any other solution you would have to choose which of the two files you want to go with.

 

Not really. If the files were binary, sure, but they are not. The scrapbook example is a somewhat simple case. Since the scrapbook.rdf is RDF/XML. All that has to happen to automate the merge is to create an XSLT transform to sort the data by the id value (a date/timestamp). Next do a command-line diff. If an item has been deleted/added/edited on one side and hasn't been touched on the other. The script would insert or remove the data on the opposite side. If the data inside the element is different between both sides a manual merge needs to happen. This is just par for the course. Manual two way merges are a normal part of day-to-day life when doing development work.

 

 

I would say based on your example, that Scrapbook is the real problem. It should be using more than one change file so as to allow increments. By only using one file, and not providing any kind of cloud back end, how would any changes get merged with the one file unless Scrapbook is doing the merging itself?

 

This assumes merges have to happen at the file level rather than at the content level. Imagine if two people are trying to work on an ASCII text document together. They could choose to use something like TitanPad (which isn't private) or create a text file and try to synchronize it between their machines. Setting up a full SCM like SVN for a simple text file is overkill. A simple shallow merge tool is all that is needed and that is exactly what Vice Versa and BT Sync are expected to be able to handle. If BT Sync only handled differences at the file level that would mean the two people working on the text file would have to break up each paragraph as separate files. That is completely unworkable in any sort of real world scenario.

Edited June 24, 2015 by xtraeme

[fragtion]

Moving to Syncthing and will deal with it's quirks until they undo this subscription bs in BTsync 2.0 and all the bloat, big mistakes imo

[syberjj]

I never got a reply to my post, so I am posting it here again hoping for an official statement. I am very in favor of paying, I just think you are approaching it from the wrong dirrection. Here are some ideas on how to get more subscribers and make MORE money while, at the same time, making users happier:

 

My thoughts:

• It's unthinkable to charge a fee from every user trying to access a folder with advanced features
  • If I pay for my shares, I have to be able to share them with free users and they must get those advanced features when accessing my folders. Don't restrict my usage just because my customers/friends/family don't have upgraded versions. You must charge ever user that wishes to CREATE advanced folders, but not every user that wishes to ACCESS them. This is important!
  • Imagine a company using sync. The company pays, but the company's customers can't download the files properly because they don't have a paid version. This approach is not only uncomfortable, it is not well structured and needs to be changed.
• U$ 40,00 a year per user doesn't work. Make it a monthly payment of U$ 4,00/month and give the home user the option to go yearly for U$ 20-25 a year. All this while limiting those folders to a maximum of 5 users accessing them. Then, charge more if more than 5 different users need access to the folders (which is basically a company environment or 'advanced usee') upping it to U$ 40,00/year.
  • Why? This makes it easy to understand, transparent, and accessible for personal use. Your objective here should be: Don't restrict personal users, give them a cheaper version to pay for and get all features. Or you will end up with just a bunch of free users complaining about the high price and no one will pay for it because it is not popular. I am a private user, and I wish to pay, but make it reasonable.

If you follow these tips, I will be totally open to paying a fee, but make it reasonable. Notice that spotify/Netflix charge users 5-10 U$ a month for development AND the costs of hosting, streaming and the content, so my pricing model should be more than reasonable.

 

I hope you read this and give it through thourhts. I would instantly upgrade to the 'personal' plan and probably upgrade to professional in 3-5 months.

 

Feel free to contact me for aditional thourhts and ideas.

[epounds]

Hi syberjj…thank you for your thoughts on Sync Pro. Your initial thoughts did not go unnoticed, as many on the team read through each thread. I understand where you are coming from and many options were discussed/evaluated.

 

I have sent you a personal message so we can discuss this further.

 

-ErikP

[syberjj]

 

Hi syberjj…thank you for your thoughts on Sync Pro. Your initial thoughts did not go unnoticed, as many on the team read through each thread. I understand where you are coming from and many options were discussed/evaluated.

 

I have sent you a personal message so we can discuss this further.

 

-ErikP

 

 

Thank you ErikP, I hope I could help. This is the best sync software I could find anywhere and I am eager to use it both personally and profesionally.

 

-JJ

 

PS: Got your message and already replied.

[avatarhammer]

I can understand why all the hate by personal users, but for business use BTSync is a winner. I've been using the program since 1.4 to back up data and dBases for a small orthodontic practice. The program works. Maintains compliance with HIPPA an other Govt rules. The annual fee is more than reasonable compared to Enterprise versions of Carbonite etc... Outstanding means of disaster recovery in case of natural disaster -- synced files are 3000 miles away!!! Only reason I haven't gone PRO yet is due to issues to BTSync caused by not readily apparant hardware failure, which have now been resolved.

[alankeny]

As a business user I don't consider BTSync an obvious winner at all.  From my perspective there's far too much risk placed on the end-user with the rental pricing model Bittorrent has chosen.

 

I've been burned by vendors that made major changes to their software after I bought it.  If I buy a license, I can continue to use the last version that worked for me without continuing to pay.  I simply stop paying maintenance and move on.

 

With BTSync's rental pricing, I would have to pay every year, even if I gave up on new releases a long time ago.  That ties up limited funds that could be used to pay for other software.

 

In my case I've found other software that works more like Dropbox.  It relies on a central server, so it's not as flexible as BTSync.  I bought a commercial license for my staff, because we like the extra features available in the Professional Edition.  These features won't suddenly disappear if I stop sending them money.

 

I sincerely wish Bittorrent would provide a similar license option.  I feel their current pricing model places all of the risk on the end-user, while they demand a yearly reward.