Modern Software Experience


webtrees logo

web genealogy


Webtrees is a new web app for genealogy. According to the webtrees home page, webtrees is the web's leading online collaborative genealogy application, which is no more than the usual hyperbole. Webtrees should not be confused with FamilyLink's WebTree.

Webtrees is an open-source application and it is completely free. Like many other web apps, it requires a system running Apache, MySQL and PHP. This web server, database system and scripting language are common on Linux systems. One way to run webtrees on Windows is to install a ready-made environment such as WampServer.

webtrees 1.0.0

Webtrees home page

The webtrees team introduced webtrees version 1.0.0, today, 2010 August 26. It is available for download now. You do not need to install it to form a first impression; they have a live online demo of webtrees for you to try.

If you do try it, you may note that it looks a lot like PhpGedView, just with another user interface theme. The simple reason for that is that webtrees is PhpGedView. Well, not exactly. More precisely, webtrees is a fork of the PhpGedView project. A bunch of developers left the project to take it into a different direction.

Webtrees demo

While the two products still look very much alike today, future versions will grow further apart. That webtrees does not look very different yet is because the webtrees team has been focusing on internal changes.
The webtrees product includes a wizard for converting a PhpGedView installation to a webtrees installation, but because of those internal changes, the first version of the wizard does not convert all custom settings yet.

I had email conversations with some of the people involved about why they started webtrees, how it is different from PhpGedView, and their plans for the future.


The PhpGedView project is hosted on sourceforge. Early 2010, sourceforge started to use IP addresses to block access to PhpGedView in certain countries, in accordance with U.S.A. export laws on encryption. It then allowed each project to determine whether they would unblock those countries, but that made the project managers responsible for that decision, which could have legal consequences.
In a PhpGedView forum thread about this issue the developers express dissatisfaction with this direct violation of open source principles, and discuss sourceforge alternatives. Several developers decide that they will not contribute another line of code to sourceforge, and leave the PhpGedView project.
That discussion thread ends on a gloomy note:

I am not sure what this will mean for PGV in the longer term, but for now it clearly means that little is happening in terms of daily development. Without Greg, and possible Gerry, Lukasz, and Brian, there is no development team left.

too complex

The PhpGedView project used to issue a new release every three months or so, but has not seen a new release since PhpGedView version 4.2.3 released on 2009 Dec 26.
The developers that left the PhpGedView project did not want to abandon it. Greg Roach, who was lead developer on PhpGedView for several years, had already been thinking about forking PhpGedView, so that is what happened next.

Greg and other developers had already been thinking that the development of PhpGedView needed to change. One of them notes in discussion thread that PGV tried to accommodate every feature request and be backward compatible with everything that had gone before.. They believe that PhpGedView had become too complex by many additions, and was in need of simplification.


John Finlay, the original creator of PhpGedView, admits that they have a point. He feels that PhpGedView is outdated and needs to be re-architected to meet today's Web 2.0 standards.

Forks don't bother him; he considers project forks a sign of a mature and stable project, and a desirable part of open source software evolution. He reminded me that PhpGedView has forked before; Genmod is another web application that started as a fork of PhpGedView.
If you count a project's success by the number of times it is has been forked, PhpGedView is doing fine.

Still, John Finlay does note that without a project lead, we should not be expecting another PhpGedView release soon. The PhpGedView project may attract new developers, or become stagnant. In a thread about the future of PhpGedView, he writes that PGV could be on the brink of its greatest future ever, or it could be heading towards its final ends..


The webtrees developers believe that PhpGedView contains too much custom code, and should make better use of industry standard libraries. If PhpGedView were to use more standard libraries, the code would become smaller, and the developers would be able to concentrate on the application functionality instead of effectively having to maintain their own libraries.

Nigel Osborne explains their viewpoint thus:

From technical standpoint we generally felt that PGV, as a very mature product, has had countless add-ons, tweaks and customisations over the years. This makes further development and maintenance very difficult.

PGV had a pattern of small, incremental changes, when what it really needed was for the development team to take six months out of the public eye to implement a lot of under the hood re-engineering, and make some bold changes to the GUI.

The webtrees team hosted webtrees on launchpad instead of sourceforge, and started to prune the project, much like Firefox was started by pruning the NetScape project.

development philosophy

The webtrees developers feel that PhpGedView tries to do too many things, and that too often none of those things works particularly well. Greg Roach explains their alternative development philosophy for webtrees thus: in the tradition of Unix utilities, we will do one thing, and do it well.

database system

Most changes are under the hood, but that does not mean that users do not notice. The most important change concerns the database. In PhpGedView, data is stored in a mix of text files and a central database, webtrees moves all data to the central database.

PhpGedView supports multiple database systems, webtrees does not. PhpGedView supports MySQL, PostgreSQL, SQLite and Microsoft SQL Server and even the little-known Firebase although there is just one PhpGedView user interested in that option. Developers particularly disliked SQLite because it lacks referential data integrity. The webtrees team decided to support just one database system, MySQL. This allows considerable simplification of code and performance tuning for that database system.
Greg Roach explained that decision thus:

MySQL is universally available, and by dropping support for PostgreSQL, SQLite and some other obscure platforms, we are able to streamline our database access and shift a great deal of processing from the webserver to the database server.  This will give some considerable performance gains, as well as improved data integrity.

Users do no longer have a choice of database systems, but do get a more reliable and faster product. The team provided some anecdotal evidence that the speed-up is considerable, for example that GEDCOM import is about four times as fast.


PhpGedView uses many different, overlapping libraries, most notably quite a few different JavaScript libraries. The webtrees team has decided to standardise on the Zend Framework and jQuery, as these are two actively maintained and well-supported industry-leading libraries. All existing code is being converted to use these two libraries. The reduction in third-party libraries makes the webtrees code easier to understand and maintain.


Webtrees comes with its own themes, but the main difference between with PhpGedView and webtrees 1.0.0 is speed. Moving all data into the central database and no longer allowing a choice of database systems has led to considerable simplification and speed improvements.

PhpGedView had many different interfaces to support extension modules. Webtrees has just one extension interface and consequently does not support the same modules that PhpGedView supports.

Quite a few users of PhpGedView run their websites using the very latest development builds of PhpGedView. These users have come to expect the development builds to be as stable as the official releases. That had a stifling effect on the developers, who hardly dared to make breaking changes anymore. Webtrees breaks with that PhpGedView tradition. There may be reasonable stable betas in the future, but webtrees users should not expect development builds to be stable or supported.

The webtrees team wants to keep things simple. An example of their simplification which you may run into when try to convert, is that PhpGedView allows multiple user accounts with the same email address, but webtrees demands that all users have unique email addresses.

new features

Webtrees does have some new features. The most important one is a new relationship engine, which deal with the names of relationships in different languages. I did not know, but the developers told me that what's known as a 3rd cousin in English is known as a 6th cousin in Polish, and that an g-g-g-g grandfather in English is an g-g-g grandfather in Danish. The naming conventions are so different that proper internationalisation required an relationship engine that supports these differences.


Translation of PhpGedView is relatively difficult because it has its own, custom system for that. Webtrees replaced it all with the fairly popular GNU gettext. This has considerable advantages, including an on-line system that allows translators to contribute directly. Webtrees was available in multiple languages even before it was released.

The webtrees 1.0.0 release does not force Amglish on you, but supports English, Amglish, and Australian English. It additionally supports Finnish, French, German, Italian, Polish and Spanish. Support for Catalan, Danish, Dutch, Estonian, Hebrew, Hungarian, Norwegian, Russian, Slovak, Slovenian, Swedish, and Turkish is being worked on.


Future releases of webtrees may see further speed improvements. Webtrees 1.0.0 uses MySQL exclusively, but still does so through PHP Data Object (PDO). A future versions may use the native MySQL interface, which cuts out of the overhead of the PDO library and allows more complex queries.

In webtrees 1.0, the privacy logic is still implemented in PHP, which is slow, especially for large genealogy databases. A future version will move the privacy logic into the database server, to take full advantage of its ability to handle large data sets with ease.

Many of the changes made so far have not changed the functionality of the product, but have provided a good basis for future development. Future plans include improvements to the way places are handled, a complete rewrite of the Google Maps integration and simplification of the administration pages.