Should we mark all the drupal.org projects as unmaintained and obsolete

We at Omega8.cc continue to actively maintain all key Aegir 3 projects and related modules, including Drush 8, on GitHub. This includes full support for modern stacks such as the latest PHP, Percona (MySQL) versions, and Composer integration. We are committed to maintaining these components for the foreseeable future.

To avoid the misconception that Aegir 3 is abandoned or unmaintained, we would like to propose formally recognizing our ongoing maintenance efforts and making this more visible to the broader community. With the previous method of installing and upgrading Aegir via Debian packages no longer available, we believe the time is right for us to take over official maintenance of Aegir 3 components and clarify that the project is still actively supported and being developed—primarily through our BOA (Barracuda Octopus Aegir) stack integration.

For users seeking a stable and supported path forward, BOA offers a mature and production-ready solution. To further ease adoption, we are working on two key extensions:

1. A BOA in-place conversion tool to allow any Aegir 3 server (running either Nginx or Apache) to be converted to a native BOA configuration without requiring site migration.

2. An enhanced BOA migration script to automate the full transfer of Aegir instances—not just between BOA-managed servers, but also from legacy Aegir 3 servers to BOA if preferred.

In addition to Aegir, we also maintain our Drupal 7 core fork and are committed to publishing timely security and feature patches. Our work builds upon various community-led initiatives to keep Drupal 7 LTS alive and sustainable. At the same time, we are also preparing a contingency plan for the future, in case Drupal 7 eventually loses even the current LTS options. If that situation arises, our goal would be to migrate Aegir 3 to Backdrop CMS as a long-term solution. Only at that point would it make sense to officially retire Aegir 3 on Drupal.org, but we believe we are still years away from such a transition.

We welcome your feedback on this proposal. If the community agrees, we would be happy to proceed with maintaining Aegir 3 "the BOA way," ensuring its ongoing availability, development, and compatibility with modern hosting needs.

@memtkmcc that sounds great to me, presumably in that case you'd want to keep maintaining things on github, and essentially change the drupal.org pages to point to those projects, similar to: https://www.drupal.org/project/drush → ?

Probably want to wait for anyone else to weigh in before going down that road though.

@steven-jones Rather than migrating everything entirely to GitHub (though we do maintain active GitHub and GitLab mirrors), our intention is to continue maintaining the canonical repositories on GitHub, while also keeping the Drupal.org codebases in sync. This way, we preserve the existing issue queues and community history, and allow contributors to continue engaging with Aegir on Drupal.org. We believe this approach strikes the right balance between forward momentum and continuity for long-time users and contributors.

Okay, makes sense. I guess we'd need to make sure that it was clearly stated that it wasn't a continuation of the relatively unopinionated Aegir project, but was BOA, which last time I looked was far more opinionated?

@steven-jones Yes, that's correct—BOA is indeed more opinionated by design, but that comes with many significant advantages that aren't possible with a fully system-agnostic Aegir setup. It's a virtual tradeoff in that sense: while BOA enforces certain conventions, it dramatically improves security, performance, and reliability out of the box.

This opinionated structure also removes much of the manual overhead and sysadmin expertise typically required to run and maintain Aegir. At the same time, BOA still provides a broad range of configurable options, so users retain flexibility where it matters most. Ultimately, the goal is to empower users by simplifying complex tasks, not to limit them—making Aegir more accessible and sustainable for a wider audience.

At worst, I'd suggest "Minimally maintained" and "Maintenance fixes only".

Significantly better though is Omega8.cc's offer:

To avoid the misconception that Aegir 3 is abandoned or unmaintained, we would like to propose formally recognizing our ongoing maintenance efforts and making this more visible to the broader community. With the previous method of installing and upgrading Aegir via Debian packages no longer available, we believe the time is right for us to take over official maintenance of Aegir 3 components and clarify that the project is still actively supported and being developed—primarily through our BOA (Barracuda Octopus Aegir) stack integration.

I fully support this proposal.

Are the fixes/patches done for BOA being contributed back onto Drupal.org at the moment? Or are they elsewhere?

I'm concerned that people out there who are expecting their Aegir installs to continue indefinitely aren't going to understand that they'll be moving to a different system: BOA to continue to be able to get maintenance updates etc.

For example...Aegir supports Apache, but last time I looked BOA was nginx only, right? So we'd need to make sure people aren't using Apache features etc. if they want to move to BOA.

Just to clarify further: BOA has never used Apache, and therefore does not develop or test against Apache-based setups. However, we have also never removed or altered Apache-related code or templates in Aegir itself. This means that while Apache-based Aegir setups will continue to function, they will only receive minimal support moving forward.

That said, we are not introducing any changes to Aegir that would prevent someone from continuing to use Apache if they prefer, or if they just want to apply selective patches (for example, to ensure compatibility with newer PHP versions).

At this time, we haven’t yet committed patches or updates back to the Drupal.org repositories (and haven't done so in quite a while), but assuming there's consensus—and it seems that way so far, which we greatly appreciate—we're preparing to resume active contribution here.

Importantly, since we don’t plan to publish new releases (tarballs) on Drupal.org, these changes won’t impact anyone still running standalone Aegir, whether with Apache or otherwise. The updates will be available only in the Git repositories, and will be clearly documented to distinguish between upstream Aegir usage and BOA-powered Aegir setups.

We’ll make it very clear across all Aegir project pages that while the code on Drupal.org will reflect the full set of BOA-driven improvements, the only supported environment will be BOA. To make adoption easier, we’re working on helper scripts to streamline the upgrade path—even for users currently running Apache—so they don’t have to manually figure out how to switch to Nginx or adjust their system configuration.

We also plan to restore Ubuntu support in BOA for users who have institutional requirements to run Ubuntu—though this will be without systemd. For Debian-based systems, we already support and encourage easy migration to Devuan as a systemd-free alternative.

One more important clarification: while BOA still installs the main Aegir instance in the default /var/aegir path, just like all standalone Aegir setups, it doesn’t actually use it for anything beyond serving as the central web server configuration point. Its main purpose is to include the virtual hosts for BOA-specific Octopus instances located in /data/disk/foo.

This approach improves compatibility and helps avoid conflicts, allowing BOA and standalone Aegir instances to co-exist on the same system. BOA also leaves the /var/aegir directory structure intact—even if it automates its upgrades—while most BOA-specific features apply only to the Octopus instances in /data/disk/foo.