A Recipe for GEDCOM - Sat, 3 Aug 2013

You can hear rumblings from the GEDCOM volcano of genealogy bloggers.

On August 1, James Tanner wrote Sharing Data Files or What Happened to GEDCOM? He says most genealogists are not aware there is a file compatibility issue until they are personally faced with the problem.

Dear Myrtle wrote Genealogy data sharing REVISITED where she laments the fact that FamilySearch is “dropping the GEDCOM X ball”.

Randy Seaver wrote Standards, GEDCOM, FHISO, and my Genea-Fantasy with the idea that the FamilySearch API might be the vehicle.

James Tanner followed up his first post the next day with: Is Moving Towards a Solution for Establishing Data Communications Standards Possible? where he argues that developers have no incentive to share their program’s unique features with the standard.

I’ve been working with GEDCOM for over 15 years. In that time it hasn’t changed. The standard has been GEDCOM 5.5 and the de facto standard has been GEDCOM 5.5.1. My work with Behold has made me have to delve into and try to understand every nook and cranny of the existing standard, as well as find a way to handle the non-standard extensions that vendors are including.

I’ve followed and contributed to many technical GEDCOM discussions on the GEDCOM-L mailing list, BetterGEDCOM, Gedcom X and have supported and contributed a paper to FHISO. I’ve watched with interest as various programs implemented different ways, outside of GEDCOM, to transfer data. And I’ve seen and looked at dozens of GEDCOM alternatives that have been proposed.

So what can we do to bake a new GEDCOM cake?

All the needed ingredients are now available:

1. The GEDCOM standard, used at least partially by almost all programs today.

2. Dozens of alternative standards that would change the world for everyone.

3. Billions of ideas of all the teensy details that “need” to be in the new standard.

We have the cooks:

1. A FHISO team to do the baking.

2. Promised support by dozens of top vendors and genealogical organizations.

Here’s the recipe:

1. Start with the goodness. A lot of thinking went into GEDCOM. The fact that some parts of it were not used by some vendors is not entirely GEDCOM’s fault. Decide what is good about GEDCOM and keep it.

2. Find what’s broken and doesn’t work. Fix those things. Don’t fix what works.

3. Keep it simple. Every complexity makes it more difficult for the developer to integrate it to their data model and to program correctly. This will spoil the cake.

4. Don’t add something unless it’s absolutely necessary. Nobody will be able to lift a cake that’s too heavy.

5. Don’t strive for perfection. The last 5% takes 95% of the time. The wedding won’t wait for the cake. Improvements can be added in future revisions.

6. Bake the first cake quickly (strive for a year). Get tasters to try it and tell you what is good and what isn’t. Then update your cake recipe regularly (every two years).

I’m excited for FHISO. They are starting anew with Drew Smith at the head, and I’m looking forward to see if his common sense and leadership will bring this to fruition.