Drupal 8/9, not just for the big guys

[jdavis]

I attended DrupalCon in Seattle last month, and one of the interesting things I came away from the conference with, was a sense that Drupal hasn’t completely abandoned smaller organizations and projects in favor of the Enterprise.

There has been a sense since Drupal 8 came out that Drupal was moving towards the Enterprise and that it wasn’t viable for smaller orgs and non-profits, but as we look at where Drupal development has gone and the road ahead, we see a different picture. The flagship feature in the recently released Drupal 8.7 is Layout Builder. A very powerful tool for allowing content creators to build interesting page layouts, and arguably a feature that helps smaller organizations as much or more than it aids Enterprise clients.

During his keynote, Dries also pushed heavily the idea of “Automatic Updates” as the next big initiative for Drupal Core. This feature would be a big deal for smaller organizations who may not have the time or resources to manage security updates or deployments.

Finally, we have the upgrade path. One of the largest pain points with Drupal in the past for smaller organizations was the cost of major version upgrades. Often these were multi-thousand dollar projects that really put a squeeze on budgets and patience. As we get closer to the release of Drupal 9 next summer, we’re finally seeing the promise of Drupal 8 being realized. Given that your site isn’t using any deprecated code, the upgraded from Drupal 8.8 to Drupal 9 should be as easy as any other Drupal 8 update to date. This is huge. And efforts are already underway to ensure the top Drupal 8 contrib modules are ready to go on the day Drupal 9 is released.

I left the conference encouraged that Drupal hasn’t abandoned the smaller end of the market, and in fact has some really strong stories to tell going forward, especially for small business and non-profits.

[allie]

I’ve always believed that a well-constructed)Drupal site is actually better in terms of usability than wordpress and others, but the bottleneck has been finding developers who can do the well-constructed part consistently and affordably. I’m exited about these developments because we may finally be able to use those developers ‘at scale’.

When you can maintain consistency across a collection of sites, you can scale the insight and talent of a small number of experienced developers. This has been a central goal of own company, primarily in the interest of supporting a collective ‘little guys.’ As we support enterprise organizations, we find a common interest between these little-guy-collectives and larger companies that maintain a collection of brand sites.

We started this work in Drupal 6. I think that Advantage Labs did a pretty good job creating a Drupal 6 installation profile that covered a lot of bases. The install profile allowed 90% of many sites’ code to be root-owned and centrally managed, which meant we could deploy updates that kept sites secure without much site owner intervention. But because configuration changes were in the database, they were not versionable. There was still a lot of variations between sites, which could cause upgrade challenges. Our solution to that problem was a human-powered one: we started Lab Hours to help oversee the changes.

Many of the changes we added to our Drupal 6 made it into Drupal 7 core. How validating! We were on the right track! But without views and media handling in core, you still couldn’t build much without adding contrib modules. And then we ran into more technical challenges because of all of the interdependencies between modules. Certain versions of chaos tools would break sites with incompatible versions of modules, and the same kinds of things happened with the entity api, media handling, and other module. It got hard to update things centrally, and it was kind of an annoying use of in-person time to wade through all of this.

Even after you had a working site, it was only a matter of time before a new version of Drupal forced you to consider an expensive upgrade. This was my least favorite part of being a Drupal developer, and it has scared a lot of people away.

The configuration management functionality that appeared in Drupal 8 was a big step forward. It’s now possible to version config changes and deploy them to different environments. Composer can help deal with version compatibility issues, and an increasing body of knowledge about continuous integration and deployment makes it more possible to test and deploy changes. Finally, the improved major upgrade process solves the most critical problem of expensive upgrades.

With all of this in mind, I see a brighter future for Drupal sites than for e.g. Wordpress, which retains many of the longer-term complexity problems after an “easier” initial setup. It remains to be seen whether service providers use these new capabilities to extend Drupal to smaller organizations by way of hosted environments and turnkey solutions – or whether they follow the money and stick with larger clients.