Folks, I'm concerned that our expectations may be unrealistic. After following this list and the regular TMG list for a while, I get the sense that many people seem to assume that all other packages aspire to be TMG and they just haven't gotten there yet. So we will just sit back and wait for the other packages to "mature" to the point we can utilize them. So far, I haven't seen that attitude on the part of any of the other packages. In fact, there has already been some push back from the RootsMagic community. A post by one person on the RootsMagic list said [paraphrase], "I looked at TMG and did not like it. That is why I am a RM user. I don't want RM to become TMG!" That post received quite a few rather emphatic "me too's!" Another post I saw was frustrated with the fact that TMG import seemed to have captured all of the attention of the RootsMagic developers to the exclusion of issues of importance to the RootsMagic community. The list of features on our web site fundamentally says, "Nothing else is adequate. I want my TMG!" That may be exactly the way we feel, but I doubt is a realistic expectation. There appears to be little hope if any that someone is going to "clone" TMG. My impression is that these other packages are scrambling to make TMG import as friendly as possible, but primarily it is an effort to shoehorn as much TMG data into their existing packages as possible. I have seen almost no indication that they are interested in implementing TMG features. Certainly if new features come along, it does not appear they will happen any time soon and they probably will not be driven by the desires of the TMG community. They may implement a few features that 1) they consider a good fit with their existing product, 2) that would be useful to their current user community, and 3) would also assist with TMG migration. But the first two criterion will be weighted much more heavily than the third. For example, I think it was already on the RootsMagic wish list to handle alternate names a little more like TMG. After a while, I anticipate these other packages will move on with little or no further concern for compatibility with the obsolete TMG package that has fewer and fewer users every month. For this TMG-REFUGEES effort to be the most effective, I think 1) we need to be producing a "top 5 list" of the features most important to TMG users, 2) We should consider how our TMG data could best be moved into the existing structures of the other programs instead of expecting the other programs to adapt to our TMG data, and 3) those of us who have some programming expertise may need to collaborate on how TMG data can be "massaged" en masse to better fit the format of other programs. John N.

John (regarding your message pasted below), The way I see it is that we're in it for the long haul and it's all about figuring out an exit strategy. Some TMG users will "jump" early and others will wait. This list is great in that users in the TMG list complained about chatter related about finding another program to move to. So, whether in the short or long haul, the issues can be freely discussed here - that's great! TMG user expectations may be realistic or unrealistic as you note below; doesn't matter to me, as this will sort out over time. I doubt whether other "packages" as you note below aspire to be like TMG, agreed. I concur with your notes that other software programs will react over time, adding TMG direct import or enhanced gedcom import changes may also improve over time, and existing users may complain over resources diverted, OK. So what. Their user base will grow and their otherwise shorter term goals may move out a bit. So what, they will complain on their lists, and we will advocate for and figure out our own TMG exit strategies. You advocated for a "top 5 list" of TMG features. My take is that an overall comparison list as already posted as a goal by this TMG Refugees list would be more helpful to me than a condensed top 5 list. In other words, your "top 5" may be different than my "top 5." It's also a daily moving target. Example, several TMG users noted that TMG person ID number does not "port" over to RM. In less than one day, a RM user wrote a sql lite routine to convert the RM person ID to the TMG person ID numbers. Similarly, when we raised the issue of lack of latitude/longitude import to RM, that was addressed / solved in a few days time - it's all a moving target. You said, "2) We should consider how our TMG data could best be moved into the existing structures of the other programs instead of expecting the other programs to adapt to our TMG data." Agreed. There is a RootsMagic document prepared with assistance of expert TMG user input advising of changes within TMG prior to an import to RootsMagic. So, each one of us can review and figure out which of the recommendations we choose to work on within TMG and which ones we postpone due to amount of change and/or work involved, etc, knowing that future RM changes may lessen the changes or another software may do it better. I agree with your comment that users posting here, "... expecting the other programs to adapt to our TMG data" is unrealistic. However, my takeaway in those quick reads is simply to note the TMG features so as to understand how it affects my TMG projects. Tom M. > -----Original Message----- > From: tmg-refugees-bounces@rootsweb.com [mailto:tmg-refugees- > bounces@rootsweb.com] On Behalf Of John Nunnally via > Sent: Sunday, September 28, 2014 8:54 PM > To: tmg-refugees@rootsweb.com > Subject: Re: [TMG-REFUGEES] Reality check.. > > Folks, I'm concerned that our expectations may be unrealistic. After following > this list and the regular TMG list for a while, I get the sense that many people > seem to assume that all other packages aspire to be TMG and they just > haven't gotten there yet. So we will just sit back and wait for the other > packages to "mature" to the point we can utilize them. > > So far, I haven't seen that attitude on the part of any of the other packages. > In fact, there has already been some push back from the RootsMagic > community. A post by one person on the RootsMagic list said [paraphrase], "I > looked at TMG and did not like it. That is why I am a RM user. I don't want > RM to become TMG!" That post received quite a few rather emphatic "me > too's!" Another post I saw was frustrated with the fact that TMG import > seemed to have captured all of the attention of the RootsMagic developers to > the exclusion of issues of importance to the RootsMagic community. > > The list of features on our web site fundamentally says, "Nothing else is > adequate. I want my TMG!" That may be exactly the way we feel, but I doubt > is a realistic expectation. There appears to be little hope if any that someone > is going to "clone" TMG. > > My impression is that these other packages are scrambling to make TMG > import as friendly as possible, but primarily it is an effort to shoehorn as > much TMG data into their existing packages as possible. I have seen almost > no indication that they are interested in implementing TMG features. > Certainly if new features come along, it does not appear they will happen any > time soon and they probably will not be driven by the desires of the TMG > community. > > They may implement a few features that 1) they consider a good fit with their > existing product, 2) that would be useful to their current user community, and > 3) would also assist with TMG migration. But the first two criterion will be > weighted much more heavily than the third. For example, I think it was > already on the RootsMagic wish list to handle alternate names a little more > like TMG. > > After a while, I anticipate these other packages will move on with little or no > further concern for compatibility with the obsolete TMG package that has > fewer and fewer users every month. > > For this TMG-REFUGEES effort to be the most effective, I think 1) we need to > be producing a "top 5 list" of the features most important to TMG users, 2) > We should consider how our TMG data could best be moved into the existing > structures of the other programs instead of expecting the other programs to > adapt to our TMG data, and 3) those of us who have some programming > expertise may need to collaborate on how TMG data can be "massaged" en > masse to better fit the format of other programs. > > > John N. > > > *** > To unsubscribe from the list, please send an email to TMG-REFUGEES- > request@rootsweb.com with the word 'unsubscribe' without the quotes in the > message subject and body. > ------------------------------- > To unsubscribe from the list, please send an email to TMG-REFUGEES- > request@rootsweb.com with the word 'unsubscribe' without the quotes in the > subject and the body of the message