Genealogical Software

This post might ruffle a few feathers, but so be it. I want to take a tour of the different types of genealogical software, and consider what are the real differences and how do they affect different types of user? What even constitutes genealogical software, and how many different ways can it be put together?

If you look at typical comparisons, such as Comparison of genealogy software and Comparison of web-based genealogy software, then you'll see that they tend to focus on very specific and rather small-scale features (e.g. single-parent families, or more than binary choice of sex). They also tend to focus on building trees (which is only a part of genealogy) and sometimes show the hallmarks of being compiled by developers rather than by product managers or journalists.

Unfortunately, traditional categorisations such as desktop versus web-based may capture the main players but unintentionally exclude the many niche players out there: products that often provide valuable additional features or functions to certain classes of user.

Users

So, to begin this exploration, what do we mean by users? You might be thinking experienced versus inexperienced, but no, I'm thinking about the people who compile and maintain genealogical data versus those who are simply interested and want to see something they can relate to.

Let's refer to these as genealogists and readers. This distinction is not a modern one, and would have been evident even in the days of printed genealogy.

Nowadays, genealogists will want to perform their own research and add data to some form of digital storage; usually a database. They will also want to share it with selected family, extended family, friends, or the general public, but those readers will have a different set of requirements. Typically, they will not want to install a special product or add-on, or pay some subscription, or even have to create a special account, and will expect access to work on whatever device they are using.

The views that these classes of user see should also be different. The genealogist will want one suited to maintenance, and which makes the manipulation of their data easier, while the reader will want a read-only presentational edition. This difference is analogous to the production of an article using a word-processor, and then someone looking at a read-only rendering of it without the menus and buttons used for modifying its content.

Software

Readers of this article will be aware of this term, but few would be able to give an accurate definition.

Traditionally, it has been the instructions that drive a computer, including all forms of hardware from mainframes down to embedded devices, but there are lots of variations on how this can happen; the most common being that the instructions are written in a high-level programming language that has to be converted into the binary machine code for the computer by another software component called a compiler (and yes, that compiler has to compile itself at some point). Assembly languages (rarer these days) are similar in having to be run through an assembler, but the associated language would be considered low-level, i.e. closer to the basic operations supported by the computer. However, some compilers defer to an assembler to complete the last step of their conversion. Some systems take the high-level language and compile it on-the-fly so that it looks like it is being executed directly. Some systems interpret a script language, and this may be done directly from its source code (very slow) or from a pseudo-machine code that has been generated on-the-fly. Finally, some languages are compiled into a pseudo-machine code that is then executed in a virtual machine, which is itself another software component.

In this traditional view, software is a set of procedural data, but there are many types of data, these days, that are declarative rather than procedural, including mark-up languages (e.g. HTML, XML, or SVG), cascading style sheets (CSS), and more. They are informally described as software since they may be essential to the executable components. More recently, the property of being Turing complete has been used to define a set of data-manipulation rules as a programming language.

Configurations

Most software configurations fall into two distinct camps: desktop and web-based, but there are some other variations to consider.

In a web-based product, there is a component that runs in your browser (which could be a page involving script code, or an add-on) and another component running on a remote web server. A wiki is a form of collaborative web-based product that manipulates multi-media data.

The desktop category invariably includes laptops, too, as the difference is largely irrelevant, but does not include hand-held devices, such as smart phones and PDAs. Here, we will use the term local to refer to software running wholly on any local device that you are in control of.

At the time of writing, the Wikipedia page Comparison of genealogy software calls this local configuration 'client', but that is not true as the term has been misappropriated from client-server: another configuration that is common in fields such as business intelligence but I'm not aware of any such product in the genealogy field. It involves a local component and a remote component, communicating via an Internet or other communications link, and sharing data or processing services. These services provided by the server component are application-level ones, and so do not typically include cloud storage or remote databases as they're too general-purpose.

Local products have another aspect to consider which is whether they can be run offline, with no external connection from your device. As they generally use local resources (files, databases, etc) — in contrast to the other two configurations — then it would be rare, if not a commercial disaster, to mandate such a connection.

Some functionality might be presented as a service, and almost invariably an online one, but we'll examine this in the section on presentation. We're using this term in the generic sense, here, rather than for 'web services', which we'll mention later.

Platforms

This category is the hardware and software environments supported for the product, i.e. the environments within which a product will run. In the two-component configurations (web-based and client-server), we will ignore the remote component as it is hidden from the user.

In principle, the operating system of a machine is separate from the hardware, but many are tied together in practice. For instance, iOS runs on iPhones, and Windows runs on Intel hardware — Microsoft did port Windows to other hardware (such as Alpha AXP) but it was commercially unsuccessful. As a result, we tend to think in terms of brands for Apple's MacOS and Microsoft's Windows. In either case, though, the operating-system version is significant, and this can be attested to by developers who have expended effort to ensure their product still works under the many changes within Windows 10.

Operating systems such as  Android (used in hand-held devices and small streaming units) and Linux are supported on a wider range of hardware.

If the product runs within a web browser then we have a similar set of issues with the software variations (e.g. Chrome, Firefox, Edge, or even the old Internet Explorer) and the associated web-browser versions.

Web-based products rarely require an installation (unless an add-on is involved) but even local products may get away with no installation being required. This can depend on the complexity of the product (e.g. being able to rely totally on system calls rather than on other software libraries or classes) and whether it includes its own support (products written in Java often include all their own classes).

An add-on (or 'add-in', or 'plug-in') is an adjunct component that extends the features or functions of a given product. We have already mentioned them in relation to web browsers but the concept may also be provided by genealogy software.

Licensing

Software is subject to copyright in many jurisdictions, but a licence establishes certain rights and restrictions for the usage of a software product. An end-user license agreement (EULA) is a contract that has to be accepted in order for the licence to be effective.

That licence may dictate how many users can run your copy of the product, whether it can be copied or redistributed, whether it can be re-sold, etc. Even when a product is free then a 'free software licence' may grant additional rights to reverse-engineer or modify it.

Where there is no physical copy of anything being installed (e.g. web-based products) then there might be a set of terms and conditions (or 'terms of use'), a similarly binding contract that covers more than the EULA (e.g. services).

Where usage of a product or services is not free then a software license usually involves a one-off cost (although that may not cover version upgrades — I'm thinking of precedents like Microsoft Windows or Office here), but a web-based product almost always requires a subscription or pay-per-access.

Royalties are slightly different and relate to the for-profit usage of some asset, such that the owner of that asset is paid a percentage of the gains from that usage, or possibly an amount per unit sold. Software developers can occasionally be paid in terms of royalties on future sales rather than for their development time. It would be rare to see this type of payment employed in the field of genealogy software but it could be applied where histories or trees are published in some way using specialised tools (see below).

Locales

There are two main aspects to a product supporting other locales: whether you can enter locale-specific data (e.g. I am English but have a German ancestor), and the user-interface locale (e.g. the product was created in the US but I am French). It is often equated with support for different languages, but support for a locale additionally includes things like dates, calendars, numbers, and more rarely support for the different structures of place names and personal names.

For the user interface (UI), simply claiming that text data is held in Unicode is insufficient to also claim the product UI can be made applicable to other locales (i.e. be localised). Even if text messages have been translated, there is a lot more to localisation than just the messages (see Software Concepts and Standards). For two-component configurations then product text should not (if well-designed) be coming directly from the server side. For instance, errors would be signalled by "throwing an exception", or indicated in a communications response, and an a corresponding client-side message reported to the end-user.

If a date (or time) is formatted as a readable text value (computers use ISO or some binary date formats internally) then it should be appropriate to the end-user's locale, and ideally to their preference too — locale libraries (NLS) usually have options for customisable full, long, medium, and short date formats.

When entering dates relevant to some other locale then the original textual representation may be unfamiliar (although preferably kept intact as evidence) but they would be converted to a standardised internal format ... unless they are not Gregorian dates. For foreign (non-Gregorian) or ancient calendars then there is no international standard for the digital storage of their dates, although GEDCOM has a go at supporting them.

One of the traps that a product can fall into when storing data values in a textual form (e.g. in a GEDCOM file, or even in a settings file) is storing them in the current locale (for which there can be two different ones in a two-component configuration) rather than a locale-independent format. The stored data should always be independent of the end-user's locale (see programming locale), and this is especially relevant where there are multiple genealogists updating the same data.

Evolution

If you're using an old product then you may be accepting that there will be no further revisions or fixes, but that does not mean that licensing is then irrelevant. I have tried to get a software licence for a deprecated and unsupported library, and was quoted such a ridiculous amount of money that I simply wrote my own version.

There are two aspects to the evolution of a product: active, meaning that new features may still be added in subsequent versions, and supported, meaning that problems will be addressed and ideally fixed. These are distinct, and a product may have reached the end of its active life but still be supported for a given period of time.

Data Manipulation

Let's consider the types of data that a genealogist can add, change, or leverage through their software product.

The data might be private to a single genealogist or to a small selected group of genealogists (as with a family project or a family history society), and local products fall into this category. Web-based products could involve either private or shared data. Back in What to Share, and How, the terminology of "unified trees" and "user-owned trees" were cited as being used in some blogs. They correspond to the private and shared terms used here, but we will not specifically consider "trees" at this point as they are merely a visualisation of some data.

Lineage is likely to be the thing most people will associate with genealogy — possibly because of the shared etymology with genetics — although products often get sucked into non-lineage complications. The mention of "single-parent families", at the start of this article, is one example: we all have two progenitive parents, even if they are unknown. Including adopted or fostered individuals is another example. In both of these cases, it's the concept of a family that causes the complication since lineage, families, and marriage are all separate concepts that do not necessarily coincide (see Happy Families).

With many products, and especially ones updating shared data, it is assumed that the people and relationships being represented are real (i.e. that they exist, or once did). But they might tentative or hypothetical if part of a research project, and they might even be fictitious if you're a writer. Depending on the nature of your research — for instance, a one-name or one-place study as opposed to a specific family — then the people and relationships might have to be disjoint, or include incidental people who were unrelated but still part of the history.

The way a product treats places can be crucial, depending on the nature of your research. In many products, a place is simply a string of jurisdictional names — a stance shared by the current GEDCOM specification. For example, "Americus, Indiana, US". However, places exist (or existed), have an identify that may need confirming, are part of a hierarchy (as with person lineage), may have multiple names, have a history, have documents associated with them, etc. The point being that they can be treated as historical subjects in a very similar way to people. More enlightened products can accommodate this depth of properties, and go beyond some specific place name.

Images, whether photographic or document scans, are probably supported by all products that maintain genealogical data. But they may be thumbnail images in a tree visualisation, an image gallery for a person/family (or for a place), or a portrait image accompanying biographical details.

It is not unusual these days to have a product help you with maintaining evidence and citing sources, but this wasn't always the case. It's definitely a move in the right direction, although the reality often falls short of an academic standard. On its own, a source reference, and particularly a simple hyperlink, does no more than identify a source of information. That information needs to support (or refute) a claim for it to be considered evidence of something, and so an indication of how the information is relevant to the claim is essential.

A product will usually involve a database to store all the data that it holds, but this is not true of all products. In fact, we'll explain in a moment that a database can be a limiting factor. The question of whether genealogical software actually needs a database at all was questioned back in Do Genealogists Really Need a Database?

Databases are good at storing discrete items of information and indexing them; what they're not good at is handling bulk text, but why is text important? Well, in addition to documenting real history, it's also needed for making proof arguments and general inferences, and for transcriptions; both of these latter forms requiring rich text (with formatting and mark-up) rather than plain text. An important comment on this perspective may be found at significant issue, and a brief discussion of different types of text may be found at Types of Text. This is not the same as the simple notes that we're led to believe is sufficient for our purposes. One reason for ignoring the requirement of real text — often implying that you just use a word-processor for that — is that bulk text is not only hard to store effectively but the semantics are also beyond the control of the software, and woe betide our software letting real genealogists be in control of their data. Linked to this limitation is the BS view that software can generate narrative from the discrete items of information in its database.

When a product uses data that is not of its own creation, or generates data for explicit consumption by other software, then we refer to it as import/export. It typically occurs with data files such as GEDCOM ones, but it can also involve an API (application programming interface). An API presents a programmatic view of the external data, and this may involve a communications link. That communication link can involve web services, which are more of a machine interface than an application interface.

Presentation

There are many different approaches to publishing genealogical information for consumption by readers, and this can involve the product used by the genealogist (via some explicit publishing operation, or by simply sharing the genealogist's view) or some separate more-specialised product.

There are some distinct forms that can be generated for presentation: reports, web pages, or physical objects. The actual content of these forms will be discussed below, but as an example, a report here could include biographical text, images, trees, or all of these.

A genealogist using a local product may be able to view an on-screen report, but for it to be shared then one option is to generate a printout of it. The content would obviously be static (with no interaction being possible) but it can be shared on a very selective basis. Such static reports could also be emailed to selected readers.

A more dynamic form would be web pages, i.e. *.html or *.htm files; *.svg files (employing Scalable Vector Graphics) can also be used, but there are security implications when SVG is used on its own (see What is SVG? Publishing Trees for Free). Web pages would be viewed in a web browser and so can interact with the reader to give a richer feel, or to present access to more parts of the information, but it is harder to control their privacy. Unless they are behind some gateway requiring authentication then they would usually be accessible to everyone. Requiring an add-on to be installed is another way to implement selective privacy but this would deter some readers. Another option is to email copies of the web pages since the recipients can then view them privately on their own computer, and with no loss of functionality. Web-based products might attempt to take shortcuts and simply present the same view to readers that the genealogist would have, or at least some slightly limited version of it. If this requires a subscription, or even an account creation, then it could deter readers. A recent summary  of how various familiar products generate online presentations may be found at 8 Places to Put Your Family Tree Online.

The production of physical objects requires specialised support, which would be seen as a service rather than a software component, and hence have service-related payments and conditions. Examples include plaques involving metal, wood, ceramics, or resin; scrolls and framed prints; and grave markers exhibiting QR codes to locate online information. Most services in this category would be online, or at least have an online option, but the days when we had to send in our image for printing on a memory stick, or even a roll of film, are not that far behind us.

Books, magazine/journal articles, and blog articles are an obvious form of publishing, but they are disjoint from our genealogical data. Although there are tools for creating tree visualisations to include in such publications, there is no easy route to generate the associated text, especially if your product uses a database. Even a wiki-based product is unlikely to offer enough formatting control to produce anything more than a simple printed article.

But what about the published content itself? The visualisation of relationships that we term family trees will be ubiquitous, but there are structural variations (see A Tree By Any Other Name Would Smell As Sweet) as well as different formats (e.g. fan charts). Bulk text in the form of historical/biographical narrative, or images, etc., as identified in the previous section, may also be involved.

While the published content is unlikely to be in a proprietary format requiring a specialised viewer (I'm certainly not aware of any examples), the act of publishing may require extra local software in the form of a standalone product accepting imported data, or an add-on to the genealogist's product, or some more complex arrangement (e.g. an add-on invoking a standalone product).

Possibly an untapped mode of visualisation is graphics that show geographical movements of people or families over time, or correlate the locations of people to help establish identities, or link evidence and useful information to source material (transcribed or scanned).

Conclusion

It should be clear, by now, that simple feature-by-feature comparisons for local and/or web-based products do not capture the full scope of existing products, nor do they acknowledge the wide range of possible functions and configurations. Focus tends to remain fixed on the software used by the genealogist as though that is a be-all and end-all to genealogical research, with much less effort and consideration being given to readers. As James Tanner remarked on his own blog, very recently: You can't take it with you!