open source

Enabling a stale issue bot on my GitHub repositories

For the past few years, the number of issues and PRs across all my GitHub repositories has gone from a steady stream to an ongoing deluge. There are currently over 1,500 open issues across my 194 GitHub repositories, and there's no way I can keep up with all of them.

Initially, I went through each issue in each project's issue queue on a monthly basis (mind you, this was—and is still—done on nights and weekends in my spare time). That slipped to a quarterly task... and has now slipped to only happening for higher-profile projects once or twice a year.

Probot Head from GitHub Probot project

Collections signal major shift in Ansible ecosystem

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!

The Kubernetes Collection for Ansible

Opera-bull with Ansible bull looking on

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.

When I started, I remember writing in Ansible for DevOps about 'hundreds' of modules—at the time, mostly covering Linux administration use cases. Today there are many thousands, covering Linux and Windows server administration, network automation, security automation, and even stranger use cases.

Jan-Piet Mens summed it up succinctly in a blog post last year, titled I care about Ansible:

In my opinion they’re being inundated.

Saying 'No' to burnout as an open source maintainer

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.

Sponsor my Open Source development work on GitHub

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

GitHub sponsors geerlingguy

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?.

Discovering whether an Ansible component is 'core' or 'community'

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.

DrupalCon Seattle 2019 is a wrap! It's all about the people

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!).

Drupal VM 5 ('Flynn Lives') brings updates to all the things!

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!

Drupal 8 successes and failures

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.

Hosted Apache Solr now supports Drupal Search API 8.x-2.x, Solr 7.x

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!

Hosted Apache Solr - version selection

Pages

Subscribe to RSS - open source