Can GEDCOM 7.0 Succeed? - Tue, 15 Jun 2021

It’s been just over a week since FamilySearch released the official version of GEDCOM 7.0. See my article about the announcement.

Now we probably will go into a period of silence, where nobody hears anything more about GEDCOM 7.0 for a while. The expectation is that all the developers are hard at work implementing the new standard so that they can release it as soon as possible.

But are they?

Not likely.

Motivation. Why?

Developers need a good reason to go through the work to implement the new version of GEDCOM. That’s true for any new feature they add to their program. It needs to be something useful and worth their time. The benefits must be better to them than any of the other features they are thinking of adding.

And unless it is an absolute must-have, then there’s no way a developer will put their current work aside and make GEDCOM a priority.

Something will need to motivate developers to implement 7.0.

Is GEDCOM 7.0 a Must-Have?

Everyone got very excited about GEDCOM 7.0 when it was announced, first before RootsTech as a release candidate. And then again a week ago with the official release. It’s because FamilySearch has not released a new version of GEDCOM in over 20 years. It seemed like something was finally being done. Maybe finally, our data would transfer properly between programs.

If you looked closely at the new spec, you’ll see a good number of small changes. The assumption is that each of these is addressing the transfer of genealogy data that GEDCOM currently doesn’t transfer properly.

Do I see one item there that makes GEDCOM 7.0 a must-have? To be honest, I can’t say that I do. There’s a whole lot of small changes, small new things added, and small things removed.

Okay, maybe there are 3 or 4 really good and useful changes that I see and I as a developer would like to implement. I won’t list them because every other developer will have 3 or 4 different items that they want. The point is, do you go through the work of implementing the hundred other changes required for the 3 or 4 things you want?

The developer likely already had implemented those 3 or 4 things into their own GEDCOM export and import in their own non-standard and custom way. What they’ve done already works for them. Why change?  They’ll need a good reason.

Why Your Data Doesn’t Transfer

GEDCOM 5.5.1 limitations are not and never have been the primary reason why your data does not transfer between programs.

The primary reason why your data does not transfer between programs is because the programmers have not implemented GEDCOM 5.5.1 correctly.

An example: Source information. This has been the number one complaint of people who use GEDCOM to transfer data is that their source information doesn’t transfer properly between two programs. The blame is often placed on GEDCOM being incapable of transferring sources details.

That is False. The problem is that developers were lazy and did not take the time to look to see what GEDCOM had. If they would have, they would have seen the PAGE tag and how to properly construct it. They could then have exported any source citation to GEDCOM in a manner that any other program could properly import it again.

I have seen few, if any, programs that have implemented the PAGE tag properly.

As I said over 10 years ago:

Maybe what’s really needed is an education program. So that developers will be able to study and learn what treasures are really hidden in the old GEDCOM standard. So that they’ll be able to learn how to implement the features correctly.

FamilySearch Needs to Be A Leader

Developers need a reason to use GEDCOM 7.0. If one developer is the first to implement GEDCOM 7.0, nothing is gained. There are no other systems to exchange data with. If two developers implement, they can exchange. If a dozen implement, they can all as well. (Assumption: they are all implementing it correctly, or we’re back to data loss.)

FamilySearch has emerged 20 years later from their abandonment of GEDCOM. They now want to lead the charge towards a new standard. For the others to follow, they really need to lead by example.

FamilySearch needs to show their commitment to their own GEDCOM 7.0 in a strong and demonstrative way. They need to show the rest of the genealogical community that GEDCOM 7.0 is required and they need to do so through their FamilySearch Family Tree.

You cannot export a GEDCOM from FamilySearch. The FamilySearch Wiki says:

Currently, a GEDCOM file cannot be exported directly from FamilySearch Family Tree. However, you can use partner programs of FamilySearch to get the data from FamilySearch Family Tree, and then create a GEDCOM file in those programs. Here is a list of the programs that are compatible with GEDCOM and FamilySearch.

What FamilySearch has done is developed GEDCOM X as their means for transferring data within their Family Tree and between Family Tree and partner programs. GEDCOM X is a programming interface to transfer the data directly. It does not produce an intermediate text-based file such as GEDCOM.

If FamilySearch really wants to commit to GEDCOM, they need to program into Family Tree a means for any user to export their tree to GEDCOM 7.0. In so doing, they’ll no longer be making a standard that they believe will work, but they’ll be putting the standard to test and see what works and what doesn’t and what needs to change. That will make the standard solid, and produce GEDCOM files from FamilySearch that other developers will want their programs to be able to input, and that alone will encourage developers to implement GEDCOM 7.0.

Supporting their own standard is not something new for FamilySearch. During the development of GEDCOM 2.0 to GEDCOM 5.5.1 from 30 to 20 years ago, FamilySearch had their program PAF (Personal Ancestral File).  Every time a new version of GEDCOM was released, a new version of PAF (usually with the same version number as GEDCOM) was released which used the new GEDCOM format.

PAF was free, and was an excellent and very popular program. And it still is being used by many people as it continues to work on Windows 10 even though FamilySearch dropped support of the program 8 years ago.

Maybe its time for FamilySearch to release PAF 7.0 to support and promote GEDCOM 7.0? That might do the trick.

Otherwise

Otherwise, I’m sadly quite pessimistic about GEDCOM 7.0.

I think FamilySearch could have done a much better job with this release. The goal needs to be to help developers do GEDCOM right. We don’t need “new expressivity”, “new flexibility” or “new compatibitlity”.  The old ways weren’t that bad. The developers just weren’t implementing them properly.

I was one of 10 genealogy developers and GEDCOM experts who worked during 2018 and 2019 to contribute our thoughts and ideas towards the GEDCOM 5.5.1 Annotated Edition and the GEDCOM 5.5.5 document that followed that were both edited by Tamura Jones.

Tamura is a well-known GEDCOM expert who posted scores of articles about GEDCOM over the past 15 years, including many detailed analyses and sets of best practices. He was encouraged to put these best practices together into a document to help developers. He did so in 2018 as the 5.5.1 Annotated Edition. Then a year later, Tamura released 5.5.5 as a “Maintenance release. Quality. Simpler & Stricter”. 5.5.5 has already been implemented by several different GEDCOM validator programs.

In my opinion, 5.5.5 is an excellent and important improvement over 5.5.1 for developers, without introducing anything new for developers to deal with. It is much superior to FamilySearch’s 7.0 which changed too much for no real apparent reason.

If FamilySearch is truly interested in advancing GEDCOM, they should be including what the genealogy programming community wants. The work and best practices of Tamura Jones are not something they should be ignoring. In fact, FamilySearch’s best move would be to contact Tamura and invite him to be a managing editor (or even THE managing editor).

Otherwise, I repeat, I’m sadly quite pessimistic about GEDCOM 7.0.