Beyond the Official Narrative: Building Drupal's (Alternative) Future

By
Preview The Future of Drupal Article
An honest look at the current state of Drupal in 2025: what we saw at DrupalCon Atlanta earlier this year, what’s missing from the official narrative, and why we believe a flexible, API-first approach can truly serve enterprise organizations today.

When we attended DrupalCon Atlanta earlier this year, I witnessed something that's become increasingly familiar: a tension between the "official" future of Drupal and the reality of what many agencies like ours "Octahedroid" and developers are actually building. 

DrupalCon has always been the place where our community converges to share diverse perspectives and chart the future of the platform. Historically, these events have showcased a variety of approaches.

However, looking at the conference schedule this time around, session after session centered around a single narrative: Drupal CMS. 

This initiative, which aims to make Drupal more accessible through a no-code/low-code approach, dominated the main stage presentations and official discussions. While this direction has merits, what struck me was how it's being positioned not as one approach among many, but as the future of Drupal.

The rich diversity of perspectives that once defined these gatherings is being replaced by a single vision that, while more approachable in theory, doesn't address the complex needs many organizations have today.

But this disconnect isn't new. In fact, it feels like we're caught in a time loop.

History Repeats Itself

Back in 2014-2015, as Drupal was transitioning from version 7 to 8, developers faced a steep learning curve. 

The shift to Symfony components and object-oriented programming represented a fundamental change in how we built Drupal sites. Tools to ease this transition were desperately needed, but the official resources were limited.

That's when we created Drupal Console: a command-line tool to help developers generate boilerplate code and navigate the new architecture. Initially, our contribution wasn't embraced by the "inner circle." There was resistance, hesitation, and even direct opposition. Yet, the community found value in it because it solved a genuine problem.

You can read more about this story in our article here.

Today, we're experiencing an eerily similar situation. The push for Drupal CMS comes with an implicit message: "You should be using Drupal as a monolith via the official experience-builder approach, theme your site with SDC, and therefore Twig and PHP".

While React support was mentioned, it was limited to XB editing components directly in the browser. This approach isolates components, preventing them from being part of a cohesive design system.

Meanwhile, agencies like ours are successfully implementing decoupled architectures consuming Design Systems across multiple web properties that deliver exceptional digital experiences for enterprise clients.

I refuse to remain silent when I see the community repeating the same patterns of exclusion that have hindered innovation in the past.

The Myth of One-Size-Fits-All

Let's be clear: if you're building sites for small businesses or organizations with straightforward needs and limited budgets, the Drupal CMS direction makes perfect sense. 

But this vision becomes problematic when it's positioned as the universal solution for all Drupal users.

Enterprise organizations with complex requirements need different tools. They need:

  • Multi-channel content delivery that goes beyond websites.
  • Integration with diverse business systems and data sources.
  • Performance optimization for high-traffic scenarios.
  • Flexible, scalable architectures that support continuous evolution.
  • Sharing the same Design Systems across multiple web properties sometimes, while using different modern front-end frameworks like Gatsby, Next.js, React-Router, and Astro.

These needs aren't addressed by drag-and-drop interfaces. They require custom code, API-first design, and often a decoupled architecture.

The strength of Drupal has always been its adaptability to various use cases. Attempting to position it as a direct competitor to other site builders already established in the market, like Wix or Squarespace, misunderstands what makes Drupal valuable to enterprise users.

What Works for Enterprise Drupal Clients

While the Drupal CMS initiative promises theoretical benefits, our agency deals with concrete client needs every day. 

Here's what we've consistently found:

  • Content structure is a priority for enterprise clients: They need robust content modeling, sophisticated workflows, and reliable APIs. When a multinational corporation needs to manage thousands of content items across dozens of markets, content architecture becomes far more important than visual editing.
  • Front-end flexibility is non-negotiable: Modern digital experiences often require specialized front-end frameworks and approaches. Many of our clients already have teams skilled in React, Vue, or other JavaScript frameworks. Forcing them to abandon these skills and tools for a Drupal-specific theming approach is impractical.
  • Cross-platform consistency matters: Organizations rarely have just one website. They maintain multiple digital properties, often built on different platforms. A decoupled approach allows them to standardize the presentation layer across these properties, implementing a design system and creating a consistent user experience regardless of the back-end systems.
3 needs for enterprise Drupal clients detailed above

These realities drove us to develop tools like GraphQL Compose and Drupal Decoupled, solutions that address specific pain points ignored by the official roadmap. 

These contributions were created from actual client requirements and continue to evolve based on real-world feedback.

That’s why we believe that impactful innovation happens at the edges of an ecosystem, not in top-down planning meetings. This has been true throughout Drupal's history and remains true today.

Building Our Own Path Forward

We're not waiting for permission to innovate. 

At Octahedroid, we've always been guided by a simple yet powerful belief: there is always a better way. 

This philosophy has shaped us into what we fondly call a band of misfits, not because we don't belong, but because our diverse experiences allow us to see the digital landscape differently.

We're the ones who ask uncomfortable questions, who challenge assumptions, and who find innovative solutions precisely because we're not constrained by conventional approaches or the pressure to adopt the latest technology just for the sake of novelty.

While the official narrative focuses on Drupal CMS, we're continuing to invest in decoupled architectures and API-first approaches because that's what works for our clients.

This isn't about competing with the Drupal CMS initiative: it's about ensuring the ecosystem remains diverse enough to serve everyone's needs. Different approaches can and should coexist within the Drupal community.

Agencies like ours have been building and contributing solutions for years, even when those contributions don't align with the preferences of those controlling the official roadmap.

Our contributions have added significant value to the ecosystem. We didn't wait for official recognition before creating them, and we won't wait for it now as we continue to innovate.

A Different Vision for Drupal's Future

The heart of open source has always been built upon the belief that better solutions emerge when diverse perspectives converge. 

This is what drew many of us to Drupal in the first place. Not a single prescribed way of building, but a framework that empowers creators to solve problems their own way.

Our vision for Drupal's future honors this open-source vision. We see a community where diverse approaches are celebrated rather than marginalized, where the official narrative acknowledges that different clients require different solutions, and where APIs and structured content are given the same priority as visual editing tools.

This isn't just about technical architecture: it's about preserving the core values of open source. When a community begins to dictate a single "correct" approach, it betrays the very principles that make open source powerful: freedom, flexibility, and the wisdom of diverse solutions.

The beauty of open-source software is that no one needs permission to innovate. 

We're building for this future regardless of whether it receives official recognition. Because ultimately, what matters most is what delivers real value to clients and users.

If you share this practical perspective, I invite you to join us. Let's collaborate to ensure Drupal remains a platform where innovation can flourish in all its forms.

The future of open-source nor Drupal shouldn't be defined by a single narrative. It should remain as diverse and adaptable as the global community that builds it.

Team member Jesus Manuel Olivas

About the author

Jesus Manuel Olivas, Co-founder and CEO
Building solutions with GraphQL, Cloud Native, Automation, CMS integrations, NoCode/LowCode, and Edge Computing. With +10 years of experience contributing to Drupal to expand its capabilities and make them accessible to all users.

Share with others

Related posts

Preview The Future of Drupal Article

Beyond the Official Narrative: Building Drupal's (Alternative) Future

By Jesus Manuel Olivas, June 3, 2025

An honest look at the current state of Drupal in 2025: what we saw at DrupalCon Atlanta earlier this year, what’s missing from the official narrative, and why we believe a flexible, API-first approach can truly serve enterprise organizations today.

How to Move from Drupal 7 to Decoupled Preview

How to Move from Drupal 7 to a Decoupled Architecture?

By Jesus Manuel Olivas, May 20, 2025

With Drupal 7 now at End-Of-Life, many organizations planning their D7 exit are rethinking their overall web architecture, given the complexities involved in moving to today’s Drupal. This guide explores decoupled architecture as a powerful alternative, breaking down its business value and strategic advantages.