One quick point, as always, we receive no financial benefit or consideration for any product or service we review/recommend/discuss here. Everything we discuss is our opinion alone, and we talk about it because we use it.
It’s been a year since MacKiev’s Family Tree Maker dominated this blog, as they struggled to deliver their first version since they took over from Ancestry, and this is what we’ve learned: MacKiev’s Family Tree Maker is garbage.
It’s strong language, but their product continues to be literally dangerous to your data. FamilySync has been a COMPLETE disaster since the moment it was promised (then delivered 4 months late), with MacKiev choosing a synchronization strategy that creates data corruption. Companies like RootMagic have delivered sync without issue, and without risk. But nearly a year since MacKiev finally delivered their FamilySync, it’s still buggy and unreliable. It’s dangerous to your work. It’s garbage.
We’re starting to think that it would have been better to let Ancestry kill the product off. It would have been a hard year, but at least we wouldn’t have wasted that year hoping that MacKiev could actually create/support software.
First off, let me say that I have a LOT of experience working with software delivery…with both commercial products and deploying/supporting in-house developed software. I’ve been doing it for 25 years. And if this was product was deployed in the large corporate environment I currently manage for a Fortune 50 company, we’d pull it out. At all costs. We’d never support this horrible effort, with so little partnership from the vendor.
And, for you loyal readers, you might be asking why we’re using FTM anyways. Didn’t we give away free copies of RootMagic to readers who’d paid for the FTM upgrade last August when MacKiev couldn’t get their act together? We did. And we still use/love RootsMagic…but…
The way RM manages citations just isn’t workable for how we support facts in our trees. For example, we created a custom citation in RootsMagic for the 1900 US Census for Roman and Mary Jones and copied the source to each of the 3 Roman’s facts supported by the citation (Name, Birth, and Residence). When we run a TreeSync with Ancestry, everything went off as expected, but it created 3 separate copies of the same citations…one for each fact. Additionally, there’s no central place to manage/edit/view all sources for a tree, which makes it VERY hard to update citations, etc.
So, we still use RootsMagic for our 60+ speculative trees, but we went back to using FTM for our main, public tree.
Since going back to Family Tree Maker, it’s been one disaster after another. First, there was the months of “Orange” sync status late in 2017 (which we missed, luckily, because we’d kicked them to the curb). About 6 months ago we had to start over and re-download the tree from Ancestry, which destroyed all of our source citations. After two months of work, the database corrupted, and we started a cycle of restoring databases, and getting about a month’s use of Family Tree Maker, and then hitting corruption. We have to restore, and repeat the process.
It really seems that this corruption is happening during FamilySync, and if that’s completely inexcusable. Their sync process HAS to be robust enough to not commit records until the system has no risk of corruption. I’ve worked with data replication since 1997 and every tool has a non-destructive method of committing data, and backing out changes if there’s failure/corruption. Plus, RootsMagic has figured this all out…we sync constantly, and there’s never red/orange/green OR corruption. Just repeated success.
The issue is just with MacKiev.
We’ve figured out how to mitigate the risk of FTM corrupting our data by doing constant syncs (change a record, sync, change another record, sync, etc.) and by reviewing the sync reports each time. For example, the last time we had sync stop working, we noticed that the marriage record for Felice’s side of the family was causing changes in the birth record attached to Rick’s grandmother. By deleting both facts we were able to sync successfully and then re-add the facts, and not have to resort to a restore…but I’m only comfortable doing this because I have 20+ years working with/troubleshooting database issues.
But the real nail in the coffin is how MacKiev has chosen to deal with their corruption issues. Instead of architecting a proper deployment, or fixing their code, or building in better error trapping, they turn it back on the users of their product to protect themselves from Family Tree Maker’s failures. They are insisting that you add the following steps to every FamilySync:
- Backup your database (32 minutes for our 3700 person tree)
- Compress your database (6 min.)
- Wait for Green conditions (0-240 min.)
Recently, we did a day’s worth of tree building and citing/sourcing (6 hours) and then we had to stop our work and take nearly an hour to sync. Then, we waited for 2 hours for MacKiev’s FamilySync to go back to Green. Then, the database corrupted anyways, and we lost all 6 hours of work and had to repeat it.
If we back up every hour, we risk less data, but we cut our productivity in half (work an hour, back up for an hour)…assuming we don’t have to wait for Green.
In the mean time, I switch over the RootsMagic and work on some speculative side project, with regular FamilySync’s, while FTM is dead in the water waiting to “Go Green”.
As much as I have invested in Family Tree Maker, and as much as it is the tool that really meets my reporting needs the best, We’re starting to think that it would have been better to let Ancestry kill the product off. It would have been a hard year, but at least we wouldn’t have wasted that year hoping that MacKiev could actually create/support software.
5 thoughts on “There’s no other way to put it – MacKiev’s Family Tree Maker is garbage”
Geez, either it’s totally a Mac issue or its your Mac because my 19,000-person tree backs up in less than 1 minute on my PC!!
It’s soooooooo spotty, so random. Lots of users have never had an issue, lots have it essentially bricked or barely usable, it doesn’t surprise me we would have a wide variation. Although, we always back up media, and that’s the long item…but it’s only 2800 images…
Perhaps your database is indeed corrupted. My 3500 base syncs relatively quickly and it backs up nearly instantaneously.
Yeah, it was corrupted. What I can’t believe is that it’s so poorly programmed that a sync process could expose this simple database to corruption. I’ve done a lot of database sync and/or replication projects, and that’s really the first rule…ensure the database can’t be corrupted by syncing!