As of this writing, Aegir has been around for 11.5 years (!), which is pretty ancient in the software world. It was originally targeting Drupal 5, and ran on PHP 4. Drush was in its infancy and the plethora of configuration management tools we see today did not exist.
Challenges inherent in this architecture:
d()): PHP 4’s object-oriented features were… limited. To overcome that, we basically invented a dependency injection system, among other things.Additional challenges built up over time as a result, including:
As a result, some very interesting feature requests weren’t feasible without major changes, including:
Another fundamental challenge that Aegir faces is that it tries to serve two constituencies simultaneously, namely sysadmins and developers. The former appreciate the reliability and security-conscious approach that Aegir takes. The latter most appreciate the efficiency and extensibility it offers. These competing interests can lead to design trade-offs that can leave everyone frustrated.
However, Aegir has largely been developed by sysdamins, for sysadmins. As a result, useability hasn’t been a priority. One glaring example is the Aegir Drupal update/upgrade process. You won’t find a button labelled “update” or “upgrade” anywhere in Aegir core (though it exists as a contrib module). Instead, we use “migrate”, which describes the actual process of upgrading a Drupal site, but is entirely un-intuitive.
That all being said, Aegir does some things really well:
Aegir5 is meant to be a thorough re-write in order to address some of these fundamental challenges, and to better leverage modern components.