A Bit of Drupal History: Product or Framework?
In the world of Drupal, the terms “product” and “framework” represent two different approaches to how the platform can be used and who it serves.
A product in the Drupal sense refers to a ready-to-use solution that allows users to build and manage websites with minimal technical knowledge. It’s about offering a polished, user-friendly experience where the focus is on enabling non-developers — such as content editors or small organizations — to easily create and maintain a web presence without needing to understand the underlying code. The goal is to make Drupal useful and approachable out-of-the-box, with intuitive interfaces and pre-configured options.
On the other hand, a framework is more of a toolkit for developers. It provides the building blocks to create highly customized and complex web applications. A framework is designed with flexibility in mind, allowing developers to build everything from basic sites to intricate systems tailored to specific needs. However, this approach often requires a deeper understanding of web development and can be more resource-intensive to implement and manage.
Earlier in Drupal’s history, a common refrain was “Kill the Webmaster”. This slogan positioned Drupal as a product, aiming to create an out-of-the-box experience that would lower the barrier for entry for non-technical users. The idea was to incorporate web development best-practices, making it possible for more people and small organizations to publish their own websites without needing to be experts in web technologies.
Around the point where Drupal 8 development began, a countervailing trend arose seeking to strip Drupal core down to be more of a framework; known as “small core” at the time. There were multiple reasons for this, including core developer burnout, maintaining such a large codebase. This shift was driven partly by the needs of developers and larger organizations to build complex, custom solutions.
While this made Drupal a powerful tool for those with the skills to use it, it also meant that the product-like simplicity envisioned earlier was less prioritized. This evolution left some smaller organizations feeling alienated, as they found it more challenging to use Drupal without technical expertise.
Fast Forward to Today
The Internet has evolved a lot since the introduction of Drupal 8. But then, so has Drupal itself.
Part of the development of Drupal 8 included leveraging the test suite (largely introduced with Drupal 7) to basically rip out and replace a lot of Drupal’s own internals, and make them more object-oriented. This, in turn, was intended to make the upgrade cycle from one major version to the next less painful. It is true that the upgrade process from Drupal 7 to 8 was a very significant lift, but, from Drupal 8 onward, upgrades have been rendered almost trivial!
Today, with the recent release of Drupal 11, the vast majority of that movement away from that Drupal 7 world has occurred within Drupal itself, but a significant number of Drupal sites are still on Drupal 7. In parallel, we’ve seen an explosion in the popularity of comparable projects like Wordpress, which takes that product approach and runs with it.
Now that Drupal core has evolved into the powerful framework it is today, the community is no longer faced with an either-or choice. We can, in fact, have our cake (Drupal core) and eat it (Starshot) too.
Starshot: Blending Framework Rigor with Low-Code Ease
Recently, Consensus colleagues Dan Friedman and Brian Sharpe had the chance to talk at DrupalCamp Ottawa about the promise of Starshot. Starshot represents a shift in the Framework-vs-Product conversation, bringing the best of Drupal’s framework into the product development arena. We see this as an opportunity for Drupal to say to those smaller organizations: “We’re going to build something that works for you, for the skillset that you actually have.” In short, “Kill the Webmaster” has become “Low Code/No Code”.
We think this turn toward simplicity and product focus provides some very exciting opportunities.
Automatic Updates will provide an upgrade process that doesn’t require an entire devops team to keep running. Behind the scenes, the Drupal infrastructure team is integrating software supply chain security into their packaging pipeline. The Drupal Association has sponsored the development of a Composer plugin and Rugged, the server-side component developed primarily by our colleague, Christopher Gervais. As a result, out-of-the-box Starshot (and Drupal 11) will provide users the confidence that the software they have requested is in fact the software they are receiving.
Project Browser will allow users to manage installed modules and themes. Because this involves downloading new code into a running site, it has the potential to be insecure. Here at Consensus, we’re also developing Aegir 5, a self-hosting platform in which it will be relatively simple for the user to temporarily grant access for this task, then re-secure the site, from outside of Drupal itself. Other hosting providers will likely follow suit.
Drupal core will be free to streamline the “framework” even further. Its modular approach allows us to selectively enable only the components we need, like choosing not to use Node when it’s unnecessary. This gives us the flexibility to build custom tools and configurations without relying on every part of the traditional Drupal components, tailoring the CMS precisely to our needs.
Drupal as a Product Development Platform
Most of the previous items are “behind the scenes:” folks responsible for maintaining a site wouldn’t normally interact with most of them on a regular basis. Where things start to get really interesting is in seeing Drupal itself as a product development platform.
Typically, a Drupal site is made up of:
- Drupal Core, providing base functionality;
- Community contributed modules, providing additional functionality; and,
- Themes, granting control over the site’s look and feel.
Install profiles, which do all of the initial setup, get us to the point where we have a site that “does a particular thing” – they have always been the thing that we think of at Consensus when we think of a Drupal site being a particular application. But, there are a set of limitations on install profiles that have, historically, held Drupal back from being a product-oriented platform. For example, crucially, once you have installed a site using a certain profile, you can’t shift to a new one (via profiles alone – you need to involve migrations, or other mechanisms). So, if you offer a service that has Bronze, Silver and Gold packages, you can’t move a given client site from one “level” to the next via install profiles alone. They don’t, by themselves, provide a long-term maintenance or sequential migration strategy for any given web site “product.”
In the course of various development projects at Consensus, we’ve had to come up with strategies for automating import/creation of various classes of data, including demo content, default content, test content, and so on. So we’re excited by Recipes that provide simplified content import, among other “low-code” (YAML only) interventions. This provides possibilities for getting past the limitations of install profiles.
Another interesting inclusion in Starshot is the notion of a single-directory application, that further integrates 3rd party tools (javascript libraries, and so on) into a Drupal application, with minimal developer intervention.
All in all, we see Starshot as a tremendously exciting and fascinating next step in Drupal’s evolution toward a product development platform. We look forward to supporting it, both through our ongoing work with the Drupal Association, and our continued work on Aegir 5.
Let’s Build Your Next Digital Project Together
Drupal has evolved into a powerful platform for developing digital products, with tools like Starshot enhancing its versatility. Whether you need a straightforward website or a more complex application, Drupal’s open-source nature and flexibility make it a great option.
At Consensus Enterprises, we’re passionate about open-source technology and committed to helping you achieve your goals. If you’re looking for a partner who values innovation and practicality, let’s talk about how we can use Drupal to make your vision a reality. Reach out to us today to get started.
The article Starshot: Moving Drupal Towards a Product Platform first appeared on the Consensus Enterprises blog.
We've disabled blog comments to prevent spam, but if you have questions or comments about this post, get in touch!