TMG-L ArchivesArchiver > TMG > 2011-03 > 1299773167
From: Rick Van Dusen <>
Subject: Re: [TMG] Import and export
Date: Thu, 10 Mar 2011 08:06:07 -0800
References: <009801cbdd9d$7168f920$543aeb60$@net> <201138104644.628638@Terry> <00a001cbddad$b52b0fd0$1f812f70$@com> <4D7668EC.email@example.com> <firstname.lastname@example.org> <00d601cbde67$37c5f8b0$a751ea10$@net> <4D77AFBA.email@example.com> <firstname.lastname@example.org><4D78EF90.email@example.com>
I agree factually. The really big problem with this whole subject is
that the market demand is in fact minuscule but existent. If there were
more of a market, or no market at all, this thread would have died by now.
A key point you note is that nobody will buy a gen app that doesn't
support import/export via GEDCOM, and you quite correctly note that this
demand exists even though GEDCOM is very limited.
Some of us who want to continually collaborate with others have tried to
use GEDCOM, but there are limits.
While I was using FTM6 and my Johnston cousin had FTM8, she could only
send me a GEDCOM, because her v8 files were beyond my v6. However, the
GEDCOM export and import process worked fine, virtually lossless,
because neither FTM version really exceeded the limits of GEDCOM.
When my Boxaca cousin was ready to get into a gen app, we researched and
agreed on TMG; in other words, I changed apps, rather than try to
import/export. (My Johnston cousin joined me in converting.)
(BTW, my Boxaca cousin and I have collaborated via email and machine
translation through the six years of working together. Not sure we
thought about it this way, but we didn't need any more "translation"
activity between us.)
I think we really can't know what the real market demand for a truly
viable data import/export functionality really is until there is such a
thing, and people who have taken other approaches to data exchange start
jumping on its bandwagon. There seem to be a lot of people out there who
are doing some less-than-adequate form of communicating with others.
Who knew when email went provider-, platform-, and client-independent
that it would explode upon the culture and totally change things. Who
knows but that "Son of GEDCOM" could have the same result within genealogy.
Darrell A. Martin wrote:
> The ability to do lossless transfers is a driver for only a *TINY*
> section of the marketplace (if you exclude backup and restore as a form
> of transfer). There are only two groups of people who even care:
> - 1. People who want, or need, to abandon their current program and
> switch to another; and,
> - 2. People who want to be able to collaborate on a project using
> different programs.
> The first group may be large at a given time, which is what happened
> when UFT was orphaned. I, along with a lot of other UFT refugees,
> created a marketplace opportunity for Wholly Genes. TMG 4.0d was the
> result. But this kind of situation drives software development only on
> the import side.
> The second group, those who want to collaborate using different
> programs, is minuscule. The problem is not technical; it is that there
> is only a microscopic subset of this group that has the organization and
> discipline to keep data versions under control even when the *same*
> program is being used. A networked database is the real solution to this
> need, IMHO.
> If I were a genealogy software developer I would have a great interest
> in a truly standardized lossless genealogical data transfer protocol.
> This is because the market would resist those who did not support it, as
> it resists those who will not support GEDCOM (even with its well-known
> limitations). However, I would not waste effort on a method for my own
> program to export its data -- directly -- to others.