Thoughts on Drupal's new Starshot Initiative

This past weekend I attended my 20th DrupalCon (holy 💩!). This year, Dries announced a new “Starshot” initiative during the requisite “Driesnote” keynote. It’s a play off of JFK’s “moonshot” speech, and communicates 1) the difficulty, and 2) urgency involved. It’s an acknowledgement of the perception that Drupal is archaic and/or legacy software, and that this perception needs to change. This is really exciting, and if you haven’t watched it yet, do it now.

Image

What Starshot encompasses

Talking with various core committers over the week, it’s important to note that much of this is still to-be-determined. But we do know several things:

1. Consumers of Drupal will be pointed to a new “Drupal CMS”. This will include Drupal core plus many popular contrib modules. Modules like Pathauto and Metatag will likely be included, but in addition this may also include UI related modules/themes like Field Group, Gin, and Type Tray (which is one of my fav modules).
2. Drupal CMS will heavily utilize the new Recipes API (recently committed to core) which will act as the “glue” for Drupal CMS. Recipes has the ability to add configuration, dependencies, and default content. Functionality for selecting recipes will be included in the installation process, in addition to Project Browser.
3. The most significant piece of the puzzle (in my opinion) is the new page building initiative, now named “Experience Builder” (a name that I’ve grown to love). Here’s what I know:
   1. Drupal’s substandard (when out of the box) page building capabilities have finally been identified as a primary issue holding back Drupal adoption
   2. This will replace Layout Builder, and there should be ways to migrate your data to this. Potentially the same for migrating from Paragraphs.
   3. The frontend will be built on jQuery UI. Just kidding, they’re planning on using React 😆.
   4. Acquia is provisioning a (very) large team to work on this (Thank you Acquia!)
   5. Tons of UI, and UX testing have already taken place. Competitors' solutions have been analyzed and evaluated. The goal is to not just be equal with our competitors, but to soundly surpass them.
   6. Experience Builder will heavily utilize Single Directory Components (SDC), and will provide a user-friendly UI to map fields to props and slots.
   7. It’ll have a UI to combine existing components to make new reusable components (this is something that Gutenberg does well)
   8. The goal is to release a MVP contrib module in a year or so (this seems ambitious to me).
   9. I’m not sure (at this point) if the goal is to get Experience Builder into core or not. It may forever live in contrib and be a part of Drupal CMS.
4. Drupal core will still exist as is. Many agencies and larger sites are still expected to use this as a starting point.
5. I’m still not clear (and I’m not sure anyone is yet) on if there’s special backwards compatibility (BC) guidelines for contrib modules included in Drupal CMS.
6. I’m not sure who gets to decide on what goes into Drupal CMS, although I believe Dries touched on this during his keynote as an opportunity for more community leaders to step up.
7. There’s a lot of pieces still needed to fall into place, and core leadership is still figuring out many details.

The overarching goal of Starshot is to make Drupal radically easier to use out of the box. Drupal CMS will include the modules needed to have a fully functioning Drupal site, as well as the ability to easily create one-off marketing pages. Even better, it’ll have the ability to pull down additional features (with default content) via Project Browser and Recipes.

Image

Circling around for the mid-market

Since version 8, Drupal has largely abandoned smaller and medium sized websites in favor of focusing on the enterprise sector. While this focus isn’t going anywhere, Starshot will result in both a significant decrease in development and maintenance costs, while providing a dramatically better experience for content authors and site builders. This will provide an easier starting point, which has the potential to win over the smaller sites that Drupal has been losing to WordPress.

Even more exciting is that SDC, combined with the ability to map fields to props/slots, provides massive potential to reinvigorate the Drupal theme ecosystem. Previously Drupal’s themes were not aware of the site architecture. But with SDC, it doesn’t matter if you use Paragraphs, Layout Builder, or use the new Experience Builder… you can map whatever architecture you like into components. This has even greater potential to lower the total cost of ownership for Drupal sites!

If you’re with an agency that caters to enterprise-level clients (like me), you might wonder if any of this is for you. My thought process is that 1) Experience Builder will be used by sites all across the spectrum, and 2) Drupal can no longer afford to give away the mid-market sites, because that’s where the funnel of new developers and advocates learn their trade. Drupal needs a continuous influx of new blood to remain nimble and cost effective. We’ve already seen decreases in the attendance of DrupalCons and many DrupalCamps, and I believe that’s a direct result of Drupal not targeting these small-to-mid sized projects.

Faster innovation

It’s no secret that Drupal core development can sometimes be slow and frustrating. This is because of the multiple review steps and gates needed to get into core. By having commonly used modules in Drupal CMS, and not core, they can innovate more quickly because the project maintainers can commit code themselves.

At a DrupalCon afterparty, I talked with Michael Hess (Drupal security team lead) about security implications of this, and he said (I’m paraphrasing here) that it doesn’t change the security model, as all projects included within Starshot will still be under the umbrella of the Drupal Security Team.

That being said, when code is committed to core, it goes through a very thorough review process by very experienced developers. The same might not be true for every single project included in Drupal CMS. 

The same can be said for web accessibility. Drupal core requires WCAG 2.1 AA conformance, so when code is committed to core that adds or changes a user interface, there are accessibility reviews to ensure that it meets this. Once again, the same might not be true for every single project included in Drupal CMS.

At this point, I don’t think it’s decided yet whether modules included in Drupal CMS will receive additional scrutiny, but I think it’d be nice if we found a way to do this without slowing down innovation. This is something we as a community will need to figure out.

‘Bout time

This initiative is long overdue, in my opinion. I’ve heard the argument that enterprise users don’t need the same usability or tools that small to mid-market users need, and I think that’s complete bullshit. There’s absolutely nothing preventing Drupal keeping its strengths (content architecture, security, accessibility, permissions, multilingual, etc), while having great UX for site-builders and content editors.

Without a doubt, Starshot will be the largest change to Drupal since the foundational rewrite to modern object-oriented PHP that occurred with Drupal 8.

- Me (right now)

I’m ecstatic that the powers that be (Dries, product managers, and other core committers) have the courage (and to be clear, launching this initiative does take courage) to recognize where the project is, where it needs to be, and create a plan to change it!

Now we need to execute... (let's get to work)!