Drupal VM's future

[geerlingguy]

Hello everyone! It's me, the main maintainer of Drupal VM for <checks git history> 7 years, almost 100 releases, and almost 2,000 commits.

I wanted to post this issue to give an honest overview of Drupal VM's current status in terms of maintenance, support, and future development:

1. I am no longer using Drupal VM actively for any of my own projects (nor do I work somewhere where it is the main development tool in use).
2. I still actively use and maintain most of the Ansible roles which make up Drupal VM.
3. I still use VirtualBox and Vagrant quite a bit.
4. I do not have the bandwidth to continue maintaining Drupal VM on my own (not to mention trying to fix some longstanding issues, like the Docker build still being broken due to some pesky postfix issue).

I'm wondering if someone in the community would like to take up the mantle of Drupal VM and I could pass my maintainership keys to that person (either through blessing a fork, or giving over access to this repo in my namespace).

If not, then at that point I will continue to minimally maintain the 6.x version of Drupal VM until it becomes a burden (e.g. until CI tests start failing regularly), and then deprecate it.

You may be wondering what I use now, if not Drupal VM? Well, mostly custom Docker environments with a docker-compose.yml file specific to each project. Not that I do as many these days, it's mostly Hosted Apache Solr, Server Check.in, my personal site, and the Raspberry Pi Dramble site.

Anyways—I thought instead of just letting things start to sit and wither more (the issue queue could use a good pruning), I'd open up the floor to discussion about what the future of Drupal VM should look like.

In any case, I am extremely pleased with how many people Drupal VM has helped over the years—far beyond the dozen or so I envisioned when I first open sourced this repo—and I will continue to help people automate frustrating tasks (like local environment setup) no matter what!

[geerlingguy]

Also just as a reference, here are some of the maintainer-ly things I do currently (that someone else would need to take on):

• Periodically check the issue queue and PRs, label issues appropriately, try to help if time allows
• Monitor status of CI and get notifications when builds fail, then fix them
• Periodically use ansible-requirements-updater to update all the Drupal VM roles to the latest version (and make sure it doesn't break CI)
• As needed, release new versions
• Build Drupal VM Vagrant Box periodically (typically whenever VirtualBox is upgraded) (and maintain it)
• Ensure the Drupal VM Docs site is working / somewhat maintained
• Ensure the Drupal VM website is working / somewhat maintained (static site codebase here)
• Maintain (heh...) the Drupal VM Docker Composer Plugin. (Does anyone actually use this anymore?)

[mglaman]

I know this is a tough decision. DrupalVM is viable for bootstrapping environments that are hard to pull into a Docker environment.

Recently a project had a strange setup and file structure. Dropping in DrupalVM was the fast route via Composer require.

However. I do think it is the secondary or tertiary solution for most folks now.

I know several larger agencies require DrupalVM for their stacks. Maybe their could be some kind of support offering available to ensure maintenance.

I wonder if we could encourage them to take a more prominent role in issue triage. But, that's hard.

I think making this discussion is the right step :)

[frob]

My hope is that the various aspects of maintainer-ship could be split out to different people. This is a deceptively large project with many tangential areas of expertise needed to run it all.

If the user-base is still large enough maybe an appointed BDFL could take on the administivia while others can dig into the spessific tasks for which they are suited.

[drupalicus]

I used Drupal VM in several projects, it's great tool. Now docker is the big thing. Thank you @geerlingguy for keep this project going and all its awaresomeness.

[serge-melis]

You've done an amazing job. Not only with the tool itself, but having it act as a gateway into Ansible.

Everyone should check out your book!

[crasx]

Hey Jeff! Thanks for putting together and maintaining such a solid project. I personally prefer drupalvm to a docker solution at this point. Especially in an agency context where I need to support multiple developers, I want a solution that "just works". That being said, I probably have enough knowledge to at least partially support the project going forward. I do try to maintain as much of a work/life balance as I can, so I definitely can't commit to Jeff Geerling level of dedication.. but I'd be happy to help out and watch the issue queues.

[florianmuellerCH]

Very sad to see such a wonderful and widely used solution go to rest :-(
However I understand your points... for us, especially for small projects, DrupalVM was a perfect tool which (as others already mentioned) just work and provides everything one needs.

I have very little knowledge of ansible, so I'm no candidate in taking up a stake in this - however if anyone else would, I'd be really glad to use DrupalVM for as long as sustainably possible :-)

[geerlingguy]

After many months without much progress in transitioning the project over to another maintainer, I'm going to wrap it up and archive this project on GitHub. All releases will still be able to be downloaded and cloned from GitHub or installed via Composer, but no new development will occur.

Most of the underlying roles are still maintained (and I use many of them!) but I have since moved on to using Docker environments for my local development. I often recommend DDEV for those who are not interested in maintaining their own Docker environment.