This blog post was inspired by my time at DrupalCon Portland and the Driesnote, announcing Starshot.

There has also been a story about Drupal being a series of building blocks for building your own CMS (or other application). Often, it has been compared to building a LEGO® set. The idea is that you have Drupal core and contributed modules, acting as individual pieces, to build an application that meets your desired needs. Oftentimes, this could be done without writing any code. As someone who built with Drupal, this made so much sense. You take disparate components, build on a solid base, and have this magical software built with minimal code (if you choose) that meets your needs. That metaphor always stuck, but it was pretty flawed, and I never really understood why until DrupalCon Portland 2024, last week.

When you build a LEGO set, you have bags of LEGO bricks to group specific pieces and instructions that guide you to building a specific product. This is nothing at all like Drupal. No instructions tell you to download Pathauto for automatic path aliases or Metatag for SEO. During an expo hall break, I talked with Mrina, a DevRel from CKSource, about how users would find their new CKEditor 5 Plugin Pack module. She asked how users would go on Drupal.org and find the project. I honestly struggled. I don't even remember how I find modules. But, then again, I haven't had to really "go find" a module in years. I knew the classics and anything else I just asked around. We have a rudimentary search, and there will be Project Browser. But how do people find things they do not even know they need? How in the world did I way back when? 

That's when the LEGO set metaphor broke. Drupal wasn't a LEGO set with finely crafted instructions and carefully sorted bricks. It was like being gifted some knock-off brand bricks toy and accidentally scattering the pieces all over the floor because the bag was too damned hard to open. And the instructions say GLHF (good luck, have fun.)

Distributions, prebuilt sets of functionality

Then I remembered. Way back when, I didn't find Drupal. I found Commerce Kickstart. I found a Drupal distribution. I found a purpose-built flavor of Drupal with all the modules and configurations needed to launch an e-commerce site. I didn't have to download Drupal and a series of contributed modules. The experts at the Commerce Guys, now Centarro, built Commerce Kickstart with the proper collection of modules. There is also Panopoly, which provided an out-of-the-box robust WYSIWYG page-building experience.

One problem with distributions was how they were packaged and distributed. They were built using Drush Make, a bespoke build manifest. With a distribution, you couldn't update or remove specific modules unless the distribution updated or removed them. Essentially, every update was like updating the entire platform, not just one component (unless you built the distribution yourself and other tricks, but let's face it, only a handful of us ever did.) As someone who contributed to Panopoly and maintained Commerce Kickstart, it was a burdensome process. Super cool. But it is a big burden for even small updates or security releases.

Distributions and their usage waned during the Drupal 8 era. Drush Make was dropped in favor of using Composer, which is great because Drush Make had no dependency resolution. But we lost the beauty and utility of these pre-composed flavors of Drupal. I don't think the Drupal community 100% knew how to handle distributions in the Composer era. My take was that we move onto Composer templates and call it a day. But there was still a missing ingredient: automatic installation of Drupal using a set of default configurations. We have that now, but it still requires a minimalistic profile extension that tells Drupal to install from a specific directory.

Recipes to cook up Drupal solutions

To be honest, I haven't been following the Distributions and Recipes initiative. I've been a happy little developer building what I need with the available tools for managing my config and a simple software-as-a-service starter kit I have that has been personally curated since Drupal 8. Everything began to click together after the Driesnote, where Starshot was demonstrated to show off Recipes and showcase the Drupal CMS.

Recipes combine the beauty of a Composer template (defined dependencies), site installation and configuration, and default content. These are the ingredients for providing specific-built solutions on top of Drupal. That's when I saw Starshot as a clear winner. It's not just about building a low-code platform or bringing the platform back for ambitious site builders. It's about building great products on a robust platform with many features that blow our competitors away. There isn't a cohesive way to demonstrate that; there are too many steps. Starshot is going to reduce those steps.

You can find the Starshot prototype recording on Dries's blog, but I've also embedded it here:

I'm available for one-on-one consulting calls – click here to book a meeting with me 🗓️