open source

Every successful software project I've worked on reaches a point where architectural changes need to be made to ensure the project's continued success. I've been involved in the Drupal community for over a decade, and have written about the successes and failures resulting from a major rearchitecture in version 8. Apple's Macintosh OS had two major failed rewrites which were ultimately scrapped as Apple moved on to Mac OS X.

It's a common theme, and because change is hard, the first response to a major shift in a software project is often negative. Distrust over the project's stewards, or anger about a voice not being heard are two common themes. Even though it has nothing to do with the change (which was being discussed 3 years ago), the acquisition of Red Hat by IBM last year didn't do anything to assuage conspiracy theorists!

October 2020 Update: This post still contains relevant information, but one update: the community.kubernetes collection is moving to kubernetes.core. Otherwise everything's the same, it's just changing names.

The Ansible community has long been a victim of its own success. Since I got started with Ansible in 2013, the growth in the number of Ansible modules and plugins has been astronomical. That's what happens when you build a very simple but powerful tool—easy enough for anyone to extend into any automation use case.

There's been a ton of writing about OSS stewardship, sustainability, funding, etc. in the past year, along with story after story of burnout. In this time, I've become very strict in my open source maintainership:

Unless it's generating income, it's for me and I'm not going to spend more than a couple hours a month looking at it—if that.

There are a number of projects that I maintain, which I'm not actively using on money-generating projects. I don't normally touch or even look at the issue queues on these projects until a CI test fails, or unless someone who contributes to my Patreon or GitHub supporters—or who I know from previous contributions—pings me directly about them. Every now and then I'll run through the list of PRs and merge a bugfix or docs fix here and there, but that only happens maybe once per repository per year.

tl;dr: You can now sponsor my open source development work via GitHub Sponsors.

GitHub Sponsors is the latest foray into building a more sustainable future for open source software development. There have been many attempts before, a few of which I tried (Gratipay, Patreon, etc.), but most of them never reached a critical mass, and at most you'd end up getting maybe $20-50/month out of the platform. Another prolific open source contributor I've long followed wrote about the topic of open source support and developer burnout in a post this year, Webform, Drupal, and Open Source...Where are we going?.

As you get deeper into your journey using Ansible, you might start filing issues on GitHub, chatting in #ansible on Freenode IRC, or otherwise interacting more with the Ansible community. Because the Ansible community has grown tremendously over the years—and as Ansible has been subsumed by Red Hat, which has various support plans for Ansible—there's been a greater distinction between parts of Ansible that are 'core' (e.g. maintained by the Ansible Engineering Team) and those that are not.

When everything works, and when you're living in a world where security and compliance requirements are fairly free, you would never even care about the support for Ansible components (modules, plugins, filters, Galaxy content). But if something goes wrong, or if there are security or compliance concerns, it is important to be able to figure out what's core, what's 'certified' by Red Hat, and what's not.

I'm on the flight home from this year's North American DrupalCon. Couldn't sleep, so thought I'd jot down a few words after a great experience in Seattle.

Last year, some remember seeing me walking the halls in Nashville akin to a zombie. But not the hungry, flesh-eating kind... more like the thin, scraggly, zoned-out kind. Last year my health was very poor. I went to DrupalCon mostly because it was the first DrupalCon within driving distance of St. Louis since DrupalCon Chicago several years ago. In hindsight it might not have been the best idea, and I had to skip a number of events due to my health.

Since that time, I experienced a grueling surgery and recovery, and learned to live with my new friend, the stoma. (Warning: scatalogical humor ahead—hey, it's my coping mechanism!).

It's been five years since Drupal VM's first release, and to celebrate, it's time to release Drupal VM 5.0 "Flynn Lives"! This update is not a major architectural shift, but instead, a new major version that updates many defaults to use the latest versions of the base VM OS and application software. Some of the new default versions include:

• Ubuntu 18.04 'Bionic' LTS (was Ubuntu 16.04)
• PHP 7.2 (was PHP 7.1)
• Node.js 10.x (was Node.js 6.x)

See the full release notes here: Drupal VM 5.0.0 "Flynn Lives"

There are also a number of other small improvements (as always), and ever-increasing test coverage for all the Ansible roles that power Drupal VM. And in the Drupal VM 4.x release lifecycle, a new official pre-baked Drupal VM base box was added, the geerlingguy/drupal-vm Vagrant base box. Using that base box can speed up new VM builds by 50% or more!

Thoughts about Drupal 8, Drupal 7, Backdrop, the Drupal Community, DrupalCon's meteoric price increases, DrupalCamps, and the future of the framework/CMS/enterprise experience engine that is Drupal have been bubbling up in the back of my mind for, well, years now.

I am almost always an optimist about the future, and Drupal 8 promised (and usually delivered) on many things:

• Vastly improved content administration
• Views in core, and even better than ever
• Media in core
• Layouts in core
• Modern programming paradigms (fewer #DrupalWTFs)
• 'Getting off the island' and becoming more of a normal PHP application (kinda the opposite of something like Wordpress)

But one thing that has always been annoying, and now is probably to the state of alarming, for some, is the fact that Drupal 8 adoption has still not hit a level of growth which will put it ahead of Drupal 7 adoption any time soon.

Earlier this year, I completely revamped Hosted Apache Solr's architecture, making it more resilient, more scalable, and better able to support having different Solr versions and configurations per customer.

Today I'm happy to officially announce support for Solr 7.x (in addition to 4.x). This means that no matter what version of Drupal you're on (6, 7, or 8), and no matter what Solr module/version you use (Apache Solr Search or Search API Solr 1.x or 2.x branches), Hosted Apache Solr is optimized for your Drupal search!

The St. Louis Drupal Users Group has hosted a Drupal Camp in the 'Gateway to the West' for four years (since 2014), but this year, the organizers have decided to take a year off, for various reasons. Our camp has grown a little every year, and last year we even increased the scope and usefulness of the camp even more by adding a well-attended training day—but life and work have taken precedence this year, and nobody is able to take on the role of 'chief organizer'.

All is not lost, however! There are other great camps around the Midwest, and this year we're directing everyone to our northern neighbors, in Iowa: DrupalCorn Camp is going to be held in Des Moines, Iowa, from September 27-30, 2018!