Ryan Heaton, the FamilySearch programmer leading the GEDCOM X project,
has just posted Requirements on the GEDCOM X blog.
It practically starts with the following statement (his bold):
I think all of the requirements for the project can be summarized into a single statement: GEDCOM X must be able to accommodate FamilySearch's Platform API.
He then goes on to point out a few implications (again in bolded text, but I'll spare you that). These are:
GEDCOM X must define a serialization format and an associated media type.
GEDCOM X should be extensible
and he adds that it does not imply that it doesn't mean that the goals of GEDCOM X are limited to the FamilySearch platform,
and adds GEDCOM X may define concepts that FamilySearch doesn't intend to initially include
as a non-implication
.
The GEDCOM X blog post mentions FamilySearch platform
without explaining what that phrase means.
It is nothing more than a grandiose sounding phrase for FamilySearch Family Tree (FSFT),
the second version of their decade-delayed social genealogy site, originally known as New FamilySearch.
So, when Ryan Heaton writes that GEDCOM X's one requirement is that it has to support the FamilySearch platform API
,
he is telling us that GEDCOM X has to support the FamilySearch Family Tree API.
Notice that it does not state that the GEDCOM X API must be identical to the FSFT API or the NFS API,
but merely that GEDCOM X must support
FamilySearch Family Tree.
Although FamilySearch is infamous for sloppy specifications,
it would be a mistake to casually assume that this as sloppy writing and dismiss it as such.
Ryan Heaton is a Java programmer, programmers tend to be annoyingly precise
in their choice of words about things like this, and he wrote this blog post for a reason.
The GEDCOM X site makes it clear that GEDCOM X is the new FamilySearch standard.
The GEDCOM X site makes it clear that GEDCOM X is the new FamilySearch standard.
GEDCOM X is not just the new data model, GEDCOM is the new file format and API too.
GEDCOM X replaces the previous standards.
GEDCOM X is the new FamilySearch file format, replacing GEDCOM.
GEDCOM X is the new API.
It remains hard not to wonder whether everyone within FamilySearch agrees with that viewpoint. After all, GEDCOM X is merely a work in progress, while the current API is in actual use. The current API, whatever it shortcomings, actually works while GEDCOM X does not really exist yet.
FamilySearch Family Tree (FSFT) is the second major version of New FamilySearch (NFS). That the second version of NFS has a different name is largely to misleadingly suggest it is another product entirely, which it isn't. However, the change in name also makes it easy to refer to the two different APIs the two different versions have; the NFS API and the FSFT API.
Right now, the phrase FamilySearch's Platform API
that GEDCOM X programmmer Ryan Heathon uses
arugably still means the NFS API, but read carefully, and you'll notice that he is already using it to mean the FSFT API.
The Requirements blog post is not reassuring vendors that GEDCOM X supports the NFS API,
he is reassuring vendors that GEDCOM X supports FSFT API.
FamilySearch's positioning of GEDCOM X as the new FamilySearch standard has caused concern about the future of the current API
among the FamilySearch partners using that API.
The GEDCOM X project was revealed in December of 2012.
FamilySearch confirmed that GEDCOM X is their new standard at RootsTech 2012 in February of 2012,
and FamilySearch Family Tree (NFS 2.0) went public on 2012 July 1.
For years FamilySearch told vendors to support the NFS API, then had them switch to the FSFT API, and then, around the time that FSFT finally goes into limited public beta, but still almost half a year before FSFT goes public, they announce that the API will be replaced already, even before the world had a chance to use the applications they created? What the FamilySearch!
NFS is not obsolete yet, so the NFS API is not obsolete yet.
FamilySearch is running NFS (version 1) and FSFT (version 2) in parallel now.
As long as FSFT and the FSFT API aren't ready yet, making FSFT the new standard is just a plan.
Still, the switch from the NFS API to the FSFT API already upset vendors who put a lot of resources into developing applications using the NFS API,
and announcing that GEDCOM X is the new API is sure to upset them more.
FamilySearch had been promoting GEDCOM X as not just a file format, but an API too. FamilySearch was already replacing the NFS API with the FSFT API, and is still in the process in the process of getting vendors to switch from using the NFS API to the FSFT API. The FamilySearch push for GEDCOM X as their new file format and API had vendors wondering where FamilySearch's push for GEDCOM X would leave their current applications. In their eagerness to promote the new thing, FamilySearch created uncertainty over the fate of the FSFT API. The blog post is intended to reassure vendors who created applications using the NFS API, and are switching to the FSFT API, that they will not need to switch to yet another API.
The Requirements blog post does not state that the FSFT API will remain supported
while GEDCOM X is being developed, but makes another, stronger statement.
The Requirements blog post states that supporting the FSFT API is not just a requirement for GEDCOM X,
but is in fact the requirement for GEDCOM X.
Thus, the Requirements blog post reassures vendors
that the applications they create for the FSFT API are in no danger of being obsoleted by GEDCOM X.
FamilySearch is promising compatibility.
FamilySearch is promising compatibility. The history of FamilySearch GEDCOM versions is no showcase for compatibility, but even that reality check does not provide reason to worry. There simply is very little reason to worry about compatibility, while GEDCOM X is merely a project in progress.
What should worry all vendors, not just the FamilySearch partners, is that the stated requirement directly contradicts previous FamilySearch statements about the nature of the GEDCOM X project.
FamilySearch claims that GEDCOM X is an open community standard for the industry. The GEDCOM X site presents GEDCOM X as the standard for the genealogy industry. However, even after the 2011 article GEDCOM X revealed the existence of the GEDCOM X project, complete with the GEDCOM X source code, and vendors began looking over that source code to figure out what it is, FamilySearch kept mum about it. FamilySearch kept the GEDCOM X site closed to outsiders for another two months. Only two months later, during RootsTech 2012, did FamilySearch open the website up to third parties.
Former FamilySearch CEO
Jay Verkler gave considerable attention to GEDCOM X during his RootsTech 2012 opening keynote.
The title of that keynote was Inventing the Future, as a Community
, and during that presentation,
Verkler took several minutes to argue that open is better than proprietary.
Never mind that some of Verkler's statements about GEDCOM are misleading at best,
that GEDCOM does supports Kanji as well Romanisation of Kanji, and that GEDCOM is extensible.
What matters is that he not only confirmed the existence of the GEDCOM X project,
but tried to create some pretty strong expectations for it as well.
He called GEDCOM X a A New GEDCOM
, and clearly stated that it is a file format, an API and repository model
.
The GEDCOM X site states that GEDCOM X is data model, file format, and API.
He made it clear that he expects other companies, such as Ancestry.com, to support FamilySearch's GEDCOM X standard;
the menu items on the transfer
drop-down menu in his mock-up demo of the GEDCOM X future are Ancestry.com
, Archives.com
, FindMyPast
, Geni
, MyHeritage
and More...
.
The Requirements blog post unequivocally states that theFamilySearch platform APIis the all-encompassing GEDCOM X requirement.
That may sound good, but as the industry watched the GEDCOM X project unfold,
it has become increasingly clear that FamilySearch uses words like
open
or community
in an unusual, FamilySearch-specific way.
The GEDCOM X site home page promotes GEDCOM X as Open standards for genealogical data communications
and publishes some documents and source code,
but that doesn't change the fact that it is a FamilySearch project for a FamilySearch standard.
The GEDCOM X article revealed that GEDCOM X started as part of the internal Data Framework
.
That bit of project history naturally makes you wonder whether FamilySearch continues to synchronise their internal Data Framework project with the public GEDCOM X project.
FamilySearch has not bothered to publicly address that issue yet, but perhaps the Requirements blog just did.
The Requirements blog post unequivocally states that the FamilySearch platform API
is the all-encompassing GEDCOM X requirement.
To a developer, that statement is nothing less than an outright admission that GEDCOM X isn't open community project, but a proprietary FamilySearch project.
The Requirements blog post is clear: the FamilySearch platform
comes first.
What it says there is that the FSFT API is more important than other APIs,
because FamilySearch Family Tree is more important than other social genealogy sites.
The blog post does not merely say that supporting the FamilySearch platform (FSFT API) is the major GEDCOM X requirement,
it actually says that supporting FamilySearch Family Tree, their own social genealogy site, is the only requirement.
The other social genealogy sites do not matter less, they don't matter at all!
Other social genealogy sites have been around for years, are bigger, and their data is less unreliable,
but FamilySearch's Family Tree is the only social genealogy site that matters to FamilySearch's GEDCOM X project.
That is an outright admission, from none other than the GEDCOM X project leader, that GEDCOM X is what practically everybody already thought it is: a proprietary FamilySearch standard.
FamilySearch keeps trying to paint GEDCOM X as an open community standard, but actions speak leader than words.
The FamilySearch rhetoric about an open standard for the community only fits when you understand open
to mean FamilySearch-dictated
and community
to mean FamilySearch Family Tree users.
The GEDCOM X FAQ states that GEDCOM X will not go stagnant like all the other standard efforts.
FamilySearch's chequered history makes it hard to believe that already.
It would not be the first time they announced something only to abandon a few years later...
The Requirements blog post gives more reason for worry.
That FamilySearch abandoned both PAF and GEDCOM when it started work on NFS and the NFS API is no coincidence.
They decided that the old stuff was not needed anymore now that they had decided to create something new.
One day, FamilySearch will replace FamilySearch Family Tree with something else.
It is not unreasonable to suspect that FamilySearch will abandon Family Tree and GEDCOM X together,
just as it abandoned PAF and GEDCOM together.
GEDCOM X isn't a community standard. GEDCOM X is a proprietary FamilySearch standard for FamilySearch products.
GEDCOM X isn't a community standard. GEDCOM X is a proprietary FamilySearch standard for FamilySearch products. The GEDCOM X blog just confirmed that.
FamilySearch is serious when they present GEDCOM X as the New GEDCOM
.
They want to pull another GEDCOM on the industry; they would like to regain the position of controlling the industry standard.
FamilySearch would like other vendors to support their system by supporting their standard.
That would make the world less challenging for FamilySearch,
but competing companies simply aren't in the business of supporting FamilySearch systems.
I am sure other companies have the same dream, about them creating their standard for their own use,
and all other players using whatever they created, without having to do anything in return.
Most companies have enough sense of reality to understand that this dream scenario is just a fantasy.
The GEDCOM X project is not ready yet, but most, perhaps all, of the big decisions were made by FamilySearch before FamilySearch opened up the GEDCOM X site. FamilySearch is not supporting the creation of a community standard, it is trying to dictate a FamilySearch standard to the community.
Many in the industry understood this already, and are not enthusiastic for yet another FamilySearch standard. That explains why large and leading companies like Ancestry.com and RootsMagic have not joined the GEDCOM X project, but the Family History Information Standards Organisation (FHISO) instead.
FamilySearch abandons GEDCOM X push, see GEDCOM X: no industry standard.
Text slightly rewritten; added NFS 2.0 paragraph to ensure future readers understand that FSFT is NFS 2.0, anc clearly distinguish between NFS API and FSFT API.
Copyright © Tamura Jones. All Rights reserved.