Nineteen Years in a Twenty-Four Year Old Drupal

Back in 2008, Josh Mitchell was handed a brief that sounded more like “build a private Facebook for Grammy members” – complete with CRM integration and high-fidelity audio and video sharing on Drupal. Tackling that member platform for The Recording Academy pulled him deep into the world of open source and set the tone for his next nineteen years in the Drupal ecosystem.

In an engaging conversation with Alka Elizabeth, sub-editor at The DropTimes, Josh traces his origins back to 2005 when he created his first Drupal.org account while teaching web design and introductory computer science courses at Pacific University. He then went on to become the very first CTO of the Drupal Association, spending week one triaging the Heartbleed bug, wrangling manual deployments across development, staging, and production, and helping steer the five-year development sprint that produced Drupal 8.

Today, as founder of consultancy M6L, Josh advises government teams on compliance-driven digital transformations, mentors developers on pull-request best practices and local DDEV workflows, and still finds daily refuge by playing guitar covers by ear before ever looking up the original chords.

TDT [1]: Do you remember the first time you came across Drupal? What was the project, and what pulled you in enough to stick with it?

Josh Mitchell: I created my first Drupal.org account (I have two) 19 years ago. In 2005, I was the Director of Online Services for Pacific University. I also taught in their media studies and computer science programs as an adjunct. My primary programming language at that time was Coldfusion, and I can’t remember actively building out a site with Drupal at that time, so it had to be more of a test and explore moment. Around this time, many of us were writing our own CMS platforms from scratch. I wrote a couple myself, but I was constantly on the lookout for an open-source project that I could use for large complex websites.

My first couple of significant Drupal sites would have been around 2008 at The New Group—a digital agency that was just figuring out how it wanted to use open source for ambitious digital projects. I think the first site I launched was a product catalog for Hitachi, but probably the most impactful to me learning Drupal deeply was the member platform for The Recording Academy (the Grammys). Both projects were pretty ambitious, but I remember the member platform having a lot of crazy requirements to integrate with a CRM and basically provide a high-quality audio/video sharing capability. The goal was to basically create a Facebook for Grammy members.

TDT [2]: In those early days, Drupal was still maturing. What kind of problems were you trying to solve, and how did Drupal fit into your workflow at the time?

Josh Mitchell: The workflow for using Drupal and even deploying a production site was so very different back then. It wasn’t atypical to have a dev, stage, and production instance and to sync code between those stacks using manual tools like Beyond Compare, which was basically an rsync-like tool using FTP. CI/CD and automated testing were still a few years away. There were no real industry-leading hosts like Acquia, Pantheon, or PlatformSH at that time. You basically had to build a lot of your own tooling and workflow. I’m pretty sure those first couple of sites were on Subversion or Mercurial instead of Git as well. Git wasn’t quite a thing yet.

TDT [3]: When you became the first CTO of the Drupal Association, the job had no blueprint. How did you go about defining what it should be, and what surprised you about the role once you were in it?

Josh Mitchell: My first week was also when the Heartbleed bug was publicly disclosed. So, the thing I remember the most was being immediately in risk evaluation and remediation mode with community members on the security team and the small staff of developers at the DA.

You May Like

Blog

Documenting DrupalCamp England: A Behind-the-Scenes Story

Blog

Documenting DrupalCamp England: A Behind-the-Scenes Story

After that initial excitement, it was mostly about meetings… so many meetings! I think my first six months on the job were primarily meeting community members and attending working groups. Some of these community members were significantly burned out from the migration to git that had been completed in July 2011. There were a lot of passionate, strong opinions to unpack and turn into a plan for improving Drupal.org.

I had a lot to learn about the infrastructure that was in place and how we were maintaining those complex systems with a limited budget. The limited budget and need for community-member input made prioritization and project/product management an immediate area of focus.

We wanted to hire up a team quickly to try and accelerate the release of Drupal 8 and some critical branding updates to Drupal.org. In 2014, we were essentially about a year out from DrupalCon Portland 2013. That DrupalCon represented a lot of revenue for the DA and allowed the board to commit to a significantly larger staff—I think we peaked at around 33 total staff (around 11 on the tech team) in 2015. Prior to staffing up, Drupal.org was mostly community contribution with a little funded work using contractors to maintain the systems.

By hiring up, we were able to expand on the ecosystem of Drupal.org sites to include Drupal Jobs, the new event platform for DrupalCons, DrupalCI, the Composer endpoints and the integrations that allowed for issue credits among other priorities. All of those efforts required a mix of staff and community volunteers, but the dedicated staff time allowed for much more rapid change, even if it felt like it wasn’t nearly fast enough to meet the demand.

TDT [4]: You led the DA during the transition to Drupal 8, which was a major turning point for the platform. What was one decision from that time that still sticks with you, either as a win or a lesson?

Josh Mitchell: First, I wouldn’t say that I led the DA. I definitely had a role in the leadership team, but Holly, Megan, Matt, Joe, the board of directors, working groups from that time, and (of course) Dries were a collaborative force making some really hard decisions together. Keep in mind, the DA tech team was focused on decisions to improve the tools for developing Drupal and funding the work of the Drupal Association to increase Drupal’s impact. We were not the ones “building Drupal” itself. Building Drupal core and setting its direction was all Dries and core maintainers with lots of community input.

That said, there were so many lessons! 

Drupal 8 started development in March 2011. The first Drupal alpha release was cut about a month after DrupalCon Portland in June 2013. The official stable release of Drupal 8 was on 19 November 2015. That was almost five years of development. Every prior version of Drupal had a much shorter development timeline. The longer timeline was directly related to how ambitious a rewrite Drupal 8 was compared to Drupal 7. 

Drupal 8 introduced Composer, Symfony, semantic versioning, Twig, and so much more. We also introduce much more stringent testing requirements for getting changes into the core. To accomplish those testing goals, we had to build a testing framework from the ground up that we called DrupalCI. That testing framework lasted close to nine years before we were able to move into Gitlab’s CI tools.

Drupal 8 was also a schism in the community. Backdrop was created as an alternative to taking on the complex, and often expensive migrations. It could be argued that Drupal 8 actually slowed the adoption of Drupal a bit while everyone waited to see when and how it would be released. I wish that the transition from D7 to D8 could have been more incremental for everyone.

There is a saying that hindsight is 20/20—suggesting it looks perfect in reflection—but I prefer to say that hindsight is 20/10. It looks even more crisp in nostalgic reflection than it did at the moment we were experiencing it.

TDT [5]: After stepping away from the DA, you founded M6L. What kind of gaps were you seeing in teams or processes that made you want to start your consultancy?

Josh Mitchell: I didn’t immediately start my consultancy. I have to give a hat tip to Jeff and Frank (and team) at Phase2 Technology for taking me on as a Director of Engineering. I was able to do some amazing work with the team at Johnson & Johnson, building their global brand platform.

My consultancy actually grew out of an opportunity with the City of Portland, Oregon. I had been a volunteer on the city’s Technology Oversight Committee for a number of years and they asked if I would consult with them on the city’s migration to Drupal 8. Specifically, they wanted me to teach/coach an internal team to become an internal Drupal agency.

My work as a coach and mentor has been quite rewarding. Not only do I get to help lead the strategy and present complex ideas to senior leadership in these organizations, but I also get to spend time pair programming with developers and designers, teaching them how to do Drupal well. My focus has been on showing developers with a range of experience from junior to more seasoned how to do things like properly create a pull request or to set up a local development environment with Lando or DDev.

I’ve also been fortunate to teach and to learn from literally thousands of editors on the platforms I’ve helped architect.  It’s such fun and rewarding work.

TDT [6]: You’ve done a lot of work modernizing digital infrastructure for local governments. What has that work taught you about balancing speed, compliance, and long-term maintainability?

Josh Mitchell: So far, my work with governments has been focused on larger organizations serving populations of over 500,000. That’s going to be significantly different needs (scope, schedule, and budget) than smaller jurisdictions. These organizations have budgeted personnel costs for team building and maintaining their Drupal sites. It changes what you can accomplish with Drupal to have an internal team with growing expertise year over year. The developers that work in these roles have often been with their organization for five, ten, or even 20 years. You scale differently with an internal team than you do when you contract an agency for a project with a specific launch date. 

One way I would explain it is that agencies optimize for repeatable processes to deliver very similar projects for as low a cost as possible with as high a profit margin as possible. Internal teams tend to optimize for an increasing number of integrations with other internal systems. They also prize stability and predictable costs for maintenance and operations. Neither option is bad per se, but they have different expectations of success. 

I’m hoping that site templates will open up modern Drupal to a lot of smaller governments that need better digital solutions where they “own” their code. I think too many small governments have shifted to SaaS solutions that lock them in and don’t allow for as much innovation. If we can lower the cost of a Drupal project for these smaller sites, it will make governments an even bigger market than it currently represent.

Whether a government is small or large, whether their project is with an internal team or an external agency, all governments have unique needs surrounding accessibility. Especially in light of the 2024 DOJ ruling for jurisdictions in the United States and the earlier European accessibility act.

A big part of my work planned for the next year or so is accessibility audits and remediation, not strictly Drupal work as many of the biggest issues are in legacy systems provided by SaaS vendors.

TDT [7]: In your recent blog, you described rebuilding your blog with Drupal CMS after a decade on GitHub Pages. What was that transition like, and how did the new stack compare to your old workflow?

Josh Mitchell: Well, technically, I am still on GitHub Pages for hosting. I’m using Tome to export my Drupal site locally and commit those changes to GitHub to build the pages site. It’s actually quite an affordable and more importantly, secure approach to deliver static sites. 

Before I was using Jekyll, which basically converts Markdown files into a site by passing them through a template generator. The git workflow using Drupal + Tome is similar, but I get all the familiar Drupal development and editing options for my local environment which is in DDEV.

To migrate the content from the old Jekyll format, I just created a Jekyll template that would output those posts to a CSV format and then imported them using the Feeds module. That part was maybe a couple of hours.
Overall, it was a quick migration and it helped me write a bit more this year.

TDT [8]: Drupal CMS comes bundled with a set of default modules and structure. As someone who usually builds things more custom, what did you learn by leaning into those defaults?

Josh Mitchell: I generally coach developers to use core first, contrib if it solves a need and the module is well-maintained, and custom modules and code as a last resort when the requirement is unique and unlikely to be needed by others in the Drupal community. 

Drupal CMS may change those recommendations slightly as it provides some opinionated but well-implemented defaults that I could see a lot of sites using to their benefit. For instance, after using it for a bit, I’m a huge fan of what they’ve done with the Gin theme. It really enhances the editor/admin experience.

I wrote a whole post on some of the delightful surprises I found when testing Drupal CMS. I am pretty sure that every future project I start will include ECA, Simple Add More, and Simple Search Form. The recipes included with Drupal CMS include a lot of well-structured defaults for things like creating basic page, article, and event content types with solid choices around pathauto and metatag settings.

That said, I probably would not do a full Drupal CMS install for a new project. There are a lot of modules there that would need to be removed from your composer.json if the project didn’t need the feature. This is the beauty of the new composer drupal:recipe-unpack command that was part of a recent May release. If you want some of the recipes of Drupal CMS, just apply and unpack them. The resulting composer.json will have the dependencies to the modules needed by the recipe, but not the recipe itself. So nice!

TDT [9]: You pointed out some rough edges in the current CMS experience, like page load times and accessibility issues. From a developer's perspective, what would you prioritize fixing before calling it ready for broader adoption?

Josh Mitchell: Many of the issues I saw in December and early January have already been addressed. The pace of Drupal CMS development has been amazing to watch. I think many of the recipes could be used right now on projects that have the need. I would expect those recipes, and recipes that agencies looking to speed up initial builds of new sites create for themselves, are already broadly adopted. 

I don’t think we’ll be seeing a marketer launching a Drupal CMS site without a developer, a stated product goal, happen before we have site templates. Drupal CMS is a fine-looking blog out of the box, but it also will look like every other Drupal CMS site until we have a few more themes that make it look unique out of the box. I think Experience Builder may be an important step towards broader adoption in that medium-sized organization space.

TDT [10]: The idea of content branching and merging is powerful, but also tricky in real editorial environments. What would a workable solution need to look like for it to actually help editors rather than overwhelm them?

Josh Mitchell: Oh, wow. Great question! I responded to Dries' post on AI’s impact on content management earlier this year with a few ideas around this. For content branching and merging to work, there needs to be the ability to compare what is changing with a visual diff. As developers, we’ve been using visual comparison for merge/pull requests for years. It was a game-changer that GitHub pioneered, but every Git UI needs this view for a solid code review workflow.

If editors could have the equivalent of a merge request, I think we could train them to use that. On the other hand, we might be over-optimizing a bit for smaller sites with fewer editors. It definitely should be an optional workflow and not “the one workflow”.

TDT [11]: You’ve worked as a designer, developer, architect, mentor, and musician. Which of those roles still pushes you creatively, and which one helps you step back and reset when things get noisy?

Josh Mitchell: That’s a tough one. Design is probably the area I feel the least accomplished in at the moment, which is a bit ironic as visual design was such a big part of my early career. I’ve been doing visual art, in one form or another, since middle school, but in the digital space, so much has become boilerplate templates provided by a range of frameworks. It’s hard to really introduce a new idea in human-computer interaction. All the more so as we seem to be shifting from visual design to text-based interaction with AI chatbots for a lot of interaction. 

As for a reset, I play the guitar and write/sing songs nearly every day. My wife and I have a game we play where she’ll tell me the name of a song, I’ll look up the chords, and if they seem reasonable (which they usually are at this point), I’ll play a cover of the song before I listen to it. We then listened to the song to see how close I was. 
It’s a great skill for summertime campfires.

TDT [12]: What’s something you’ve been enjoying lately that has nothing to do with tech? Maybe a trail, a song, or something that just helps you breathe a little deeper?

Josh Mitchell: I’m fortunate to live in a beautiful part of the Pacific Northwest of the U.S. I run nearly every day through the many parks in Portland—several of which I can get to starting from my front door. I also bike a fair bit and make it out at least a couple times a week to ride along the Columbia River alongside eagles and osprey with a snow-capped Mount Hood in the distance. That’s kinda hard to beat