Why Is It 'Drupal CMS' and Not 'Drupal': An Explainer

On August 15, 2024, Dries Buytaert, Drupal's Project Lead, made a significant announcement that the product developed by the Drupal Starshot Initiative will be officially known as 'Drupal CMS.' The internal name 'Starshot' will likely be retired after the first product launch, marking a pivotal shift in how the Drupal ecosystem is branded and perceived.

Understanding the Strategic Naming Shift and Its Impact on the Drupal Ecosystem

The decision to name the product 'Drupal CMS' was deliberate, grounded in extensive user testing with both newcomers and experienced users. Dries explained that this name consistently resonated the most with all tested groups, including marketers unfamiliar with Drupal, underlining its broad appeal.

"From the beginning, we intended to name it 'Drupal CMS,' which I used in the initial Drupal Starshot announcement. Knowing this name would be around for decades, we wanted to be thorough. So, we did user testing with various groups. Moving forward, we'll offer two distinct products: 'Drupal Core' as the framework and 'Drupal CMS' as the complete product. This shift is big for us, considering Drupal has operated as a single product for the past 24 years. We wanted to get the name right for the next 20 years. This is what development and product management in the open looks like. ;)"

says Dries Buytaert in a discussion on LinkedIn. (The quoted text has been slightly paraphrased for clarity). 

While much of the community welcomed this move, some members expressed doubts about why this name was chosen over alternatives like 'Drupal,' 'Starshot,' or 'Drupal DXP.' These questions partly stemmed from confusion around the release cycle of Drupal Core, traditionally identified by version numbers like Drupal 5, 6, and 7, with Drupal 11 being the latest.

The Evolution of Drupal Release Cycle

Until Drupal 7, the project had a newer version only when it was ready. There was no regular release cycle, nor was it a rolling release project where the core and the modules were continuously updated with occasional snapshot releases to maintain a stable version. Thus, "It will be ready when it is ready." 

Every element and dependency had to be meticulously managed to ensure readiness, leading to what’s often referred to as 'dependency hell.' Semver.org describes this as a situation where version lock or version promiscuity hinders easy, safe project progression.

Adopting Symfony Components: The Transition to Modern Drupal

Everything changed with Drupal 8 when the project began incorporating Symfony components into its core. Before this, Drupal maintained a set of components independently, creating a significant developer overhead. To avoid reinventing the wheel, it made sense to deprecate custom components and rely on Symfony, a modern web application framework that also offered decoupled and reusable components.

There is a notion that the Drupal project rewrote the entire code on top of the Symfony framework, which is wrong. Instead, Drupal started using Symfony components such as Httpkernel, DependencyInjection, EventDispatcher, Router, YAML, twig, and many more as part of its core. This brought Drupal to speed with modern PHP practices and thereby modernized Drupal development. 

Change Resistance 

This posed a challenge for developers accustomed to legacy Drupal, as it forced them out of their comfort zone and required them to learn modern PHP practices. However, this shift also opened Drupal development to a broader pool of PHP developers familiar with other frameworks like Symfony and Laravel, making Drupal less reliant on custom tools and more aligned with Object-Oriented Programming. 

You May Like

Article

Attico International Launches Limited-Time Drupal Audit Offer for Enterprise Sites

Article

Attico International Launches Limited-Time Drupal Audit Offer for Enterprise Sites

Until then, moving your web property from one Drupal version to another was like rebuilding it from scratch. Starting with Drupal 8, we see continuity in code. A website built in Drupal 8 can now be easily upgraded to newer versions with advanced features, reducing the risk of breaking your site. This is largely thanks to the semantic versioning practices followed by both Symfony and Drupal.

Semantic Versioning Explained

Symfony has a major release every two years, which might contain newer dependencies and API changes. It has minor revisions every May and November, with bug fixes and new features, sometimes even new deprecations. They also release a patch version roughly every month, with non-disruptive bug fixes. 

"Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backward compatible API additions/changes increment the minor version, and backward incompatible API changes increment the major version."

In modern terms, this is called semantic versioning. To get a better idea of semantic versioning, visit https://semver.org/. 

Drupal core, too, follows semantic versioning with a predictable release schedule. For brevity, please read the Release process overview from Drupal.org to learn more about Drupal's release cycles. 

Evolution of Drupal Core

Historically, Drupal had a very capable core and tightly monitored contributed modules to build websites. It was developer-friendly, and with the core and picking up a few contributed modules or writing custom modules, a developer had to make whatever they were assigned. 

Drupal now has a lean core and a much bigger module system in the community space. As before, it can be molded to any shape and size, which is particularly good for enterprise-level websites, but with the investment of quality code and time. Here comes Drupal Starshot. 

Why the Drupal Starshot Initiative? 

Drupal had been challenging for non-developers, and as no-code solutions gained popularity, it began losing ground, particularly outside the enterprise segment. While still favored by large enterprises, Drupal needed to become more accessible to mid-market companies by reducing the steep learning curve, making it more appealing to end users like marketers, content editors, and decision-makers.

In response, Dries announced Project Starshot at DrupalCon Portland, uniting various community-driven projects and strategic initiatives under a single mission. This umbrella initiative brought together initiatives like Experience Builder (XB), Recipes, Automatic Updates, Project Browser, and the newly launched Drupal AI initiative. 

Many more efforts that made Drupal better were maturing, too, such as the Single Directory Components, Events Conditions Actions, Leaflet and the Geofield ecosystem, API Client Initiative, Automated Testing Kit, Accessibility Initiative, Editoria11y for Accessibility Testing from Princeton University, Gander Automated Performance Testing from Tag1 Consulting that became part of the core, Gin admin theme and toolbar: all of this combined created an atmosphere ripe for an initiative as grand as the Starshot to flourish. Some of these modules are now part of the anticipated product.

It’s pertinent to note that various Drupal agencies have been maintaining their own installation profiles, such as Varbase by Vardot, Sobki no-code installation profile by Smile, or distributions like Thunder by Hubert Burda Media, Droopler by Droptica, and Rocketship by Dropsolid. Specialized solutions like GovCMS by the Australian Government, LocalGov Drupal for the UK and Ireland local councils, Commerce Kickstart by Centarro, Convivial CXP for Drupal personalization from Morpht, FarmOS for farm upkeep, Open Social Community Management System, which even provides a Community Experience Platform as SaaS, Guardr for enterprise-level security by mediacurrent, Opigno Learning Management System from Connect-i, and design systems like Emulsify by Four Kitchens also exist. Additionally, there are browser-based drag-and-drop Drupal installations like Try Drupal by 1xINTERNET, Provus by Promet Source, and Layout Builder by DXPR, as well as Drupal Decoupled from Octahedroid, Next-Drupal from Chapter Three, SaaS solutions like Nodehive by Netnode, and PaaS solutions from Acquia, Pantheon, and amazee.io. 

If you check at Drupal.org, you can find 110 actively maintained Drupal distributions/installation profiles/starter kits that are under active development, have a supported stable release, and have security advisory coverage. There is even a distribution focusing on nationwide European Drupal Associations maintained by the Dutch developers. These all point to the future of Drupal in packaging projects as ready-made, functional products that are easy to deploy and offer an out-of-the-box experience.

Considering all these factors, Drupal Starshot is taking shape. It is intended to provide an out-of-the-box Drupal experience 'that enables site builders without Drupal experience to easily create a new Drupal site and extend it with pre-packaged recipes, all using their browsers.'

Difference Between Drupal and the Starshot Initiative

When we say Drupal, we mean Drupal Core. This 24-year-old project allows you to build a content management system or, using its composable nature, a Digital Experience Platform. However, it is not a finished product but a bare CMS or a grand framework you use to build your application. It would help if you were a developer to do so, or you should hire a developer. 

On the other hand, the Starshot Initiative aims to build a product using the core and some pre-defined recipes, using several modules to create specific out-of-the-box experiences. With it, you can have a finished product ready to be deployed. You can test it and change it directly from the browser with drag-and-drop ease. 

Starshot is the initiative's codename, not the product name. The Drupal community has now decided to use the term 'Drupal CMS' for the finished product. Thus, we can retain the Drupal brand name while differentiating Drupal Core, the framework, from Drupal CMS, the product. 

One might doubt whether the current Drupal 11, which is essentially Drupal Core, isn't a CMS. From a developer perspective, Drupal 11 itself can be a CMS, but with bare minimum functionality. 

In legacy Drupal, an editor wasn't included with the core. CKEditor became part of the core only in 2015, starting with the release of Drupal 8. Before that, an IDE had to be programmatically deployed because the base install only provided an HTML interface. Thankfully, that is not the case with modern Drupal. It is more functional than legacy Drupal in the first installation itself. 

At the same time, with Drupal 11, some of the most used components in the core have been moved out and are now maintained as contributed modules in the community space, thus ensuring easier Drupal core maintenance than before.  

To summarize, Drupal core is a very capable system as vanilla Drupal. But it is not just ready to be deployed. 

Of course, the Umami installation profile is now included with vanilla Drupal to demonstrate what you can do with Drupal Core. However, you cannot use Umami for all use cases. It is just for experience, not for production. 

On the other hand, 

Drupal CMS is Drupal core plus a set of sensible configurations. By including or removing a recipe, you can add or alter the functionality of a Drupal website.

explains Vimal Joseph, director of MarTech, Zyxware Technologies. 

Why Not Call It Just 'Drupal'?

To put things in perspective, I have to bring to your attention a recent call by Ivan Stegic, CEO of Ten7. Ten7 is a digital agency that works with Drupal. Ivan had a business logic in advocating for a brand strategy that promoted Drupal sans version number. Earlier, we reported his call: 'Just Say Drupal.' 

According to him, the Drupal version on which an agency was basing its solution mattered only to a developer and not the end user. When new versions emerge, not all the modules will be updated or migrated to be used with the added dependencies. So, a service provider will be the best entity to take a call based on the best interests of end-users when deciding whether to upgrade or wait. 

For full-service digital agencies that simultaneously provide marketing and technology as a combined service, branding Drupal as Drupal and not as Drupal 9, 10, or 11 will be beneficial. It avoids unnecessary concerns or anxieties for end users, and agencies would be in a better place to market their solutions. 

While there are differing opinions on the use of version numbers, it’s important to consider the historical significance they carry in Drupal’s evolution. Retaining the version number for the core could provide clarity and continuity, especially as Drupal continues to follow semantic versioning for its updates.  

On the other hand, Drupal CMS can (theoretically) exist without a version number, serving as the default installation at any given time. It can be likened to a snapshot release of a rolling release Gnu/Linux distro—ideal for testing and as a gateway to more advanced experiences. In production environments, it offers a simpler, more user-friendly option while still providing the flexibility for advanced customization as needed.

"Drupal CMS is more of a CMS than Vanilla Drupal because it includes additional out-of-the-box features like enhanced site-building tools, ready-made installer configurations (for example, E-commerce Recipe, Government and Public Sector Recipe, News and Media Recipe, Non-Profit and NGO Recipe) and built-in integrations that make it more user-friendly and accessible, especially for non-developers. 

Vanilla Drupal, by contrast, is a more flexible framework that requires custom development to achieve similar results.

replied Dallas Ramsden to a comment on Dries Buytaert's LinkedIn post announcing the 'Drupal CMS' name. 

Naming download links on the Drupal.org website as 'Drupal' and 'Drupal CMS' might initially cause some confusion, but this can be clarified by establishing 'Drupal' as the framework and 'Drupal CMS' as the product. 

Why Don't We Proudly Call It 'Drupal DXP'?

The role of Drupal CMS is content management, and it would do just that in a manner that each industry wants, using the appropriate recipes for that given industry with preset functionalities. Most things related to content management would be industry-agnostic, and only a certain amount of customization would be possible without developer help. 

DXP suggests a broader, more complex platform that could attract enterprise customers looking for a complete digital experience solution. However, this might be considered premature if the product still needs to evolve fully into that space.

DXPs are higher up in space. Digital agencies now provide digital experiences rather than a content management solution. A Digital Experience Platform (DXP) is not entirely based on a single project. It uses multiple projects and products to build a fail-fast, gain-fast solution for the entity that needs it. We need a composable martech stack—a plethora of software solutions weaved together to achieve that. 

Thus, naming the end product of Starshot Initiative 'Drupal DXP' would be an overstatement and inaccurate. Drupal cannot be a DXP without other elements, such as Maotic, Unomi, etc., which have an independent ecosystem of developers and end-users.

Of course, some digital agencies, such as Acquia and, lately, DropSolid, are offering open-source DXPs and using Drupal as their base. How about empowering a budding digital agency with the same prowess? The current Drupal Core can be the first piece of the puzzle, and you can pick your preferred applications from a free and open-source technology stack right now. 

Calling the first product from the current Starshot Initiative 'Drupal CMS' has other benefits. The community can consider offering other ready-to-use products on top of Drupal Core, naming them appropriately. 

Why not use 'Starshot' as the brand name?

Avoiding Brand Dilution and Marketing Overhead

Sticking with the project name "Starshot" would be novel but could cause brand dilution. Drupal is a robust and well-established brand, and introducing a new name might require substantial marketing efforts to establish its identity and relevance. 

Clarity and Familiarity

Drupal CMS is a term already familiar to a large audience, particularly within the existing Drupal community and among organizations that have adopted Drupal in the past. It clearly identifies the product as a Content Management System, which is what Drupal has been traditionally known for. Clarity and familiarity will help you navigate a long way in marketing. 

Marketing and Brand Strategy

The decision to go with Drupal CMS likely reflects a desire to capitalize on Drupal's established reputation while signaling an evolution of its capabilities. The name keeps the Drupal brand intact while highlighting its core strength as a CMS. Starshot, as a name, would represent an ambitious, forward-thinking project but could lead to confusion regarding its relationship with Drupal's existing products and initiatives. 

Community and Developer Considerations

The Drupal community is deeply connected to the "Drupal" brand, and the decision to name it Drupal CMS might have been made to maintain continuity and avoid disrupting the existing community dynamics. Introducing a new name like Starshot could create fragmentation within the community, as it may be seen as a separate entity rather than an evolution of Drupal.

When Backdrop was ported from Drupal 7 following the detachment from the development paradigm up to then, this confusion existed, and it caused Drupal to lose some of its old users to the new hack that offered forward compatibility for Drupal 7 users. Now, Backdrop is a CMS in its own might, competing with Drupal in the midmarket segment, education, and NGO space.

What Sets Starshot Apart?

Starshot is not intended to be a competing product or a separate entity from Drupal Core; instead, it is part of a broader strategy to offer specialized, ready-to-use products built on the foundation of Drupal Core. This clarity is likely a key reason behind the decision to name the final product 'Drupal CMS.'

Long-Term Vision and Evolution

Naming it Drupal CMS could be seen as a strategic decision to gradually evolve the platform while maintaining a consistent identity. This approach allows for future branding opportunities, such as releasing subsequent versions under different names (e.g., Drupal LMS) once the platform's capabilities have expanded and matured. 

As David Kitchen puts it, 

"This is a great differentiator between Drupal as a framework and Drupal CMS as a product built with the framework.

It allows other products built with the framework, like Drupal Commerce, to stand alone. It also hopefully opens more opportunities for new Drupal-based solutions, such as Drupal PIM or Drupal CRM."

The choice not to use Starshot might indicate that the initiative is seen as a step within the broader Drupal project rather than an entirely separate product line.

Keyword Optimization

Using Drupal CMS as the name might also have practical implications, such as search engine optimization (SEO), where the term "Drupal CMS" already has strong visibility and traction. A new name like Starshot might face challenges in gaining quick recognition and might require extensive rebranding efforts.

Conclusion

The decision to name the first release 'Drupal CMS' rather than 'Drupal DXP,' 'Drupal,' or 'Starshot' is a strategic move to maintain brand continuity while clearly signaling Drupal’s evolution. By preserving its core identity, this decision paves the way for future innovations within the Drupal ecosystem. 

We are excited to see how the Starshot Initiative will drive large-scale changes and look forward to the new opportunities it will create for developers, users, and the broader community. Stay tuned to The DropTimes for more updates, and follow us on LinkedIn to stay informed.