Sluggish Drupal 8 Adoption Lags Even D6

Still on D7. Waiting for Rules and a mgirate path for it. :) Also, started working on node.js baed projects.

At this point I see no compelling reason to move to D8. If anything, it still lacks many of the small modules I use to build out sites.

We are a Drupal agency in Athens, Greece (netstudio.gr). We build a lot of e-commerce websites. So, even though we have built some (even big) websites on Drupal 8, it's only now the Drupal commerce got stable that we switch fully to Drupal 8 and we expect to publish many websites in Drupal 8 in 2018.

So, the Drupal 7 adoption really kicked off when Views was ported. Until that point, the shape of the line resembles the shape of the Drupal 8 line now. I guess the question is: what is the equivalent event that'll send Drupal 8 climbing straight up? Of course, it's possible that there isn't one, but I'm going to stay positive :-)

Maybe when there is a fully supported Drupal 7 to Drupal 8 migration path? Hopefully we're only a release or two away from that..

I haven't moved away from Drupal, but I've put off getting into Drupal 8 until just recently because it didn't appear to be production ready. It's a real shame that it took so long because the move to a Symfony-based architecture is quite an impressive feat, and I think the future looks better than ever from a technical perspective. I hope that it can find success as a headless CMS. However, I've stopped contributing to Drupal due to lack of trust in the DA especially after the Larry Garfield case, so we'll see what happens.

Driving away Drupal site builders by requiring Composer expertise was a really bad idea, but the developers making this decision simply don't realize the value non-developers/site builders bring to Drupal. But I don't think it's too late. Drupal 8 is an amazing tool for building rich web sites, and most of the times, you only need to add a handful of modules to build functionalities which required a truck load of modules in Drupal 7. But the technical skills required for Drupal 8 need to be more in line with Drupal 7, to make it more accessible and widen the adaptation.

Downsides of the Drupal 8 focus on "enterprise" priorities were evident from early on, though comments from those of us raising these issues were, shall we say, not particularly welcomed by many figures in the community.

Back in 2013, Nate Haug was one of the first to forecast a decline in Drupal usage with the advent of Drupal 8, https://backdropcms.org/news/dont-panic. His "hypothetical growth chart" showed a significant dropoff in usage following the release of Drupal 8 as small scale sites and their developers were left behind. At the time his prediction was highly unorthodox. As late as 2015, Drupal promoters were confidently forecasting a big upsurge with the new version. (Though, it must be said, Nate's hopeful projections for Backdrop look less prescient from today's vantage point.)

As so often happens, the once heretical has become commonplace. Unlike four or five years ago, now no one faces backlash in the Drupal "community" for remarking on the obvious: that catering to enterprise users will leave many out of the picture ("Have We Reached Peak Drupal?", https://www.previousnext.com.au/blog/have-we-reached-peak-drupal). The difference is existential. When a dynamic is only nascent, it's easy to dismiss or attack those who point it out. Once it occurs, it's too late to deny.

Or, unfortunately, to prevent.

Drupal 8 is a product made by big companies to big companies, and only then are using it. Two years and we do not have a migrate path, we do not have a stable backup module, we do not have many many small modules that we used with drupal 7, now it is almost impossible use it without composer, and it is gettings worst.

Upgrading a Drupal site from 5 to 6, 6 to 7 was relatively easy. This is far from the case with Drupal 8. If site owners wants to stick with Drupal and move to Drupal 8, they need to invest a lot more, which requires more time.

Of course, they can upgrade to Backdrop CMS, which is better than Drupal 7.

From my point of views Drupal 8 isn't ready for productive use as so many standard features are missing or not completed. I am referring to things like datetime range fields and it's integration in views for example. If you start to migrate an Drupal 7 site to Drupal 8 or a new Drupal 8 site from scratch you would always check first, whether or not the modules you might need are already ported, but by no means you would expect simple features like this be incomplete. An other thing is Composer integration. While it is understandable that this is better than a home brewn solution it ads much complexity specially for those, who used to use Drush to maintain there sites.

At DrupalCon Denver we were told about the Symphony and Composer changes, but not to worry, only Core Devs would need to use those tools. That hasn't panned out. Developing small D6/7 sites was practical and easy. D8 is so much more complex, that I think a lot of those small, easy to deploy sites, that can really prop up a graph, have moved elsewhere. While Composer may be great for Devs, it is a royal pain for site builders. I hate it.

I agree that the gradual shift towards composer (it's by no means been a universally planned and agreed thing, more of a slow evolution) has been a bit of a barrier to DIYers (though it's not as big of a jump as some people see it to be, as long as you do the sensible thing and store all code in Git).

I do agree that site builders are more valuable than most of the community realizes.

A huge part of this is simply a tradeoff that organizations unwittingly make between quality vs. price. You can get a cheap WordPress site built in the low 5 figures. But what they don't realize is that the back-end will be near unusable, and you'll won't be able to easily change things in the future. To get the same site built in Drupal will be 1.5–3x the price, but it will be well thought out and the site will be able to more easily evolve over time as the needs of the organization changes. There's nothing fundamental in the technologies that causes this, it's just that the cheap-n-quick agencies primarily use WP, and the agencies that focus on quality are more likely to use Drupal. Currently price is the bigger factor that organizations are taking into consideration when choosing an agency, mostly because long-term quality is so hard to see.

But part of it is just that the landscape of the web has changed in the past 10yrs. In all parts of the web, people are much less DIY, and more likely to just use a SASS solution rather than build something from scratch, or hire someone else to build something from scratch. People don't blog anymore, they post to social media.

(Disclosure: I'm a Drupal 8 core committer and I work for Acquia. This comment reflects my personal opinion, not necessarily that of other committers or my employer.)

Thanks for putting together your chart. It's neat to see the timelines normalized to years since release. Thanks also for retrieving and including the data that goes back to Drupal 6's release in 2008. Drupal's usage stats page only displays data back to 2012, so it's nice to see the 2008-2012 data in your chart.

Just eyeballing your chart, it looks to me like Drupal 7's usage went from about 50K to 600K between 6 months and 2 years from its release (mid 2011 to early 2013), during which time Drupal 6 usage declined from about 325K to 250K (3.5 years to 5 years since Drupal 6's release in early 2008).

So as a rough approximation, perhaps about 15% of Drupal 7's growth in its first 2 years was from site upgrades from Drupal 6 and about 85% was from new sites adopting Drupal. So while I agree that releasing a stable 7->8 migration path is definitely important, I don't think that that alone addresses the disparity in the rate of new site adoption.

Frankly, I agree with @dalin that differences in the broader website market in 2016/2017 vs. 2011/2012 are potentially the biggest factor: SaaS solutions from WordPress, SquareSpace, and Wix, have captured a lot more of the small site market during this time, as well as many people opting out of small sites entirely and focusing their online presence exclusively on social media platforms.

I think this change in market conditions gives us an excellent opportunity to reflect on the questions of what is it that we want Drupal to be and who do we want it to serve? My own opinion is that I think it's fine for sites that get their needs met from WordPress, SquareSpace, Wix, etc. to use those tools. That might include the vast majority of websites on the internet. But I think there are a lot of organizations, like schools, libraries, museums, and businesses and non-profits of all sizes, that need more than what those tools offer, and for which Drupal could make a real difference in them accomplishing their mission. What I think will really help these organizations the most is distributions tailored to the kind of website they need. I'm extremely excited by the Drupal 8 distributions coming out for YMCAs, volunteer communities, and others, and I would dearly love to see that flourish into thousands of great distributions, collectively serving millions of websites, over the next few years.

In my opinion, Drupal 8 is a much improved platform to build and maintain distributions on than Drupal 7 was for two reasons:
- There's much more provided by core, including configuration management, views, wysiwyg, content and configuration translation, and soon: workflows, layouts, and media. This will hopefully significantly ease the maintenance burden on distribution builders who previously had to assemble these capabilities from dozens of contrib modules and keep them updated and compatible with each other.
- From here on out, upgrading modules from one major core version to the next will be far easier than they were from 6 -> 7 and 7 -> 8. I think this paves the way for true sustainability of distributions.

While I appreciate the concern about priorities like the above being too "enterprisey", I hope that if it proves successful in enabling great distributions, then that will benefit sites of all sizes.

In addition to and regardless of the above, I do hope that we also figure out how to make Composer and some of the other difficult things about Drupal 8 easier and more accessible for everyone.

As others mentioned, drupal 8 just doesnt seem that stable to invest months of development time into it, only to find out it is missing key modules. Sure, we can code it ourselves, or hire someone to do it, but at what cost? Simply using d7 makes more financial sense. I have zero interest in composer. (I am a full time site builder and usually employee 1 to 2 programmers, a front end design person).

I've recently dropped Drupal for Craft CMS or Statamic for my freelance work, depending on the client's requirements. We still use Drupal at the agency where I work. Craft and Statamic are quicker, have less clunky interfaces, and most importantly, they have feature complete Media implementations out of the box.

Drupal 8 is a hot mess birthed from an arrogant clique who thought that various "unimportant stake holders" could be dismissed because they would either follow suit or vacate. People in today's world (especially those in IT) sure love mandates, and with Drupal, this came in the form of forcing Git, Composer, Drupal Console, Drush, and other stuff down peoples' throats. You can't even test out a module anymore in many situations without having those things, which is absolute idiocy. So is it really surprising that Drupal 8 adoption is a joke!?

Did they do all this because these things improved the overall user experience? Nope.
Did they show signs of caring about that when mulling over these mandates? Nope.

Even my grandmother of 80 years would've understood this: You don't turn your back on the people that put Drupal on the map. I guess the spear tip is hitting granite...still.

Hey Dries, instead of trying to be another Elon Musk wannabe that prances around a big stage in front of people at a big event talking about futurology topics, why not just stick with the fundamentals of the very system that allowed you to enjoy your current conflict of interest? A win-win for both the Drupal community as well as your company that you use Drupal to profit from.

When I first came across Drupal, towards the end of Drupal 5's lifecycle, it was in a reasonably close competition in terms of popularity with Wordpress. Over the years Drupal has steered an increasingly niche course and taken a number of what I'd term strategic mis-steps that have brought the project to where it is today. I would term that current position as being overly narrowly focussed, developer-centric (as opposed to being market-centric), and of decreasing utility to many. As a site builder rather than a developer (see dalin's comment above) I would characterise some of these mis-steps as being typical of software projects that are driven not by the user base or the perceived needs of the market, but by the core developers. Maybe those making the key strategic decisions thought they were doing the right thing, although I'm struggling to see the rationale from my perspective. My primary focus is on enabling clients to get the best from CiviCRM, and that currently does not include using Drupal 8. I can't currently see me recommending Drupal 8 to a client for some years yet, if ever. If Drupal 7 is ever killed off, I'll most probably move to using and recommending Backdrop CMS.

Having chosen D8 for my main project a few months ago, it has been a ruff journey. I like Twig a bit, I can live with Symfony. I like the renewed Drupal backend. But I find that Composer is unreliable and demanding. Also if you follow the rather confused documentation you end up mixing Composer workflows with Drush commands and Drupal console. I claim that mixing these broke my site completely more than once during development. So I now only use Composer. It has helped but updating core and modules still feels rather scary. Compare that to updating D7 with Drush, which I always have found to be very reliable, a bit like running apt dist-upgrade. I felt comfortable doing that. Not so much doing anything with composer. I realize of course that D8 is more complex, being 10x the size of a D7 install. But that complexity has a steeper price than the reward if you ask me. Maybe we should have a D8 light? But I guess there is no way back. I like what I have built using D8 and it does feel good now in development. But I am not looking forward to administering updates in production with D8:s composer.
I have a feeling that the slow migration of modules, that is still holdning D8 usage back, has more than a little to do with the rather uncomfortable environment D8 presents to a dev.

Most every D7 site we build relies on Rules in some way. We're building lots of e-commerce these days, even for organizations that don't really sell to the public (like private member sites). Commerce just recently became stable for D8. But, without Rules there is nothing to tie it all together.

We've built some CMS sites that don't require much in the way of custom workflows in D8, but I would say 95% of our projects are, and will remain, D7. Our customers are small, they are not going to pay us to spend time to move to D8 only to have the same basic site they had before.

We're a technical shop. We had a handful of non technical partners we used to work with on Drupal projects. Unfortunately none of them got on the D8 bandwagon and have abandoned Drupal in favor of WordPress. That has cost us business for sure.

I think it's pretty simple to me why D8 doesn't have as fast an adoption as previous versions: the necessary components that make many modern websites relatively easy to build just don't have contributed modules with stable D8 releases. There's currently no easy way to import content from a spreadsheet (which 80% of the Feeds/Migrate survey said they used) because Feeds isn't ready. In order to import content with the Migrate module, you need to know how to use the command line, which is a huge barrier for non-advanced users. Calendar, Rules, Simplenews, etc. don't have stable releases. If you want to build a site with a calendar and newsletters (without paying for another service), you have to choose D7.

And it was incredibly frustrating. Contrib modules which we depend on like Feeds are not even close to ready. Way before starting the project, I did a module inventoy and looked to see if contrib modules we depended on had been ported yet, but even if they have many of them are missing critical functionality. If I had known the contributed module landscape was so far off, I would not have started the project until 2018.

After all that, and launching the site New Relic is now telling me that the PHP execution time is 400-500 ms more than we were seeing on D7. Hopefully upgrading to PHP 7 will get some of that execution time back, but that would have been true for D7 as well.

The complexity of the D7 sites that have grown up over the years is much more than anything we saw in D5 or D6. If the same level of sophistication had existed in D6, then the upgrade would have been much more difficult to move to D7. We're now seeing highly complex D7 systems that require upgrades... and the cost just doesn't justify things yet.

Drupal does not have as a goal anymore to be usable by a single developer. I think this is a huge mistake for 2 reasons:
1) Apparently, Drupal is losing a lot of developers. The low Drupal 8 adoption rate may well be more to losing developers than waiting to switch from Drupal 6/7.
2) Less obviously, but importantly: there is less motivation to improve Drupal technical and documentation quality. Developing a moderately-complex site shouldn't be that difficult; Drupal's goal should be to make developing moderately-complex sites doable by a single developer, and enterprise sites possible by teams.

I'm a Drupal newcomer. I waited until D8 was a couple of years old before I dived in, so that the modules I believed I would need would be ready. But having been battling to learn Drupal from scratch and build my site for a couple of months, I keep running into modules that had matured on D7 but have not been ported to D8, or still have only early development versions. I'm talking about things like Taxonomy Manager. And many modules at the alpha or beta stage don't seem to have had any development for the last few months, and look like they may never make it to a stable release. I'm at the point of considering D7, despite being a newcomer, or moving onto something else.

Another thing I have noticed is a dearth of user-to-user support for Drupal these days. For example lots of questions remain unanswered on the post-installation forum at drupal.org. Then there's the documentation....

I work for a government contractor. Supporting the website is a small assigned duty with few hours budgeted for any work. I am primarily a Java developer. I think that I would have to come up with a compelling reason to migrate, like Drupal 7 support was ending. Support ending for Drupal 6 was the motivation for me to migrate to Drupal 7. The hardest part of that migration was that the site's theme was derived from a theme that was not supported in Drupal 7. I had to find another theme and customize it. I didn't design the original theme and I didn't know PHP. It was a significant hack effort to get it to work.

Beyond that, there are modules which have not been ported to Drupal 8 yet. I lack the skill set to create my own module.

I am rebuilding my D8 site in Backdrop. In 2018 my DA money will go to Oakland. Composer prevented me from updating modules twice this year, once in March at Drupalcon, more recently because of Drush going to v9 going to 8.4 was impossible. I’ve had enough.

I'm a Drupal newcomer. I waited until D8 was a couple of years old before I dived in, so that the modules I believed I would need would be ready. But having been battling to learn Drupal from scratch and build my site for a couple of months, I keep running into modules that had matured on D7 but have not been ported to D8, or still have only early development versions. I'm talking about things like Taxonomy Manager. And many modules at the alpha or beta stage don't seem to have had any development for the last few months, and look like they may never make it to a stable release. I'm at the point of considering D7, despite being a newcomer, or moving onto something else.

Another thing I have noticed is a dearth of user-to-user support for Drupal these days. For example lots of questions remain unanswered on the post-installation forum at drupal.org. Then there's the documentation....

This is just a testament to the success of D7. Why change when what you have now is working so well?