This blog post is a response to some of the things previously mentioned about Backdrop in this otherwise accurate Lullabot article: Alternatives to Upgrading from Drupal 7 to Drupal 9
I was glad to see Backdrop mentioned as an option for people that are facing the dilemma of what to do with Drupal 7 reaching its end of support in November 2022, but at the same time I was specifically "upset" by this bit:
The downside of Backdrop CMS is that it has only a tiny fraction of the community contributions that Drupal 8 and Drupal 9 have, so it is likely to progress more slowly in bug fixes, security fixes, and added functionality. Only time will tell if the Backdrop CMS community remains committed to the project. The other consideration is that there won’t be any automatic way to migrate from Backdrop CMS to Drupal 9 later. Migrating to Backdrop CMS is not a delay to buy time for a later move to Drupal 9, it’s a decision to opt out of the traditional Drupal paradigm.
update: since then, the article author has updated the wording, to remove any inaccuracies mentioned re Backdrop. Nevertheless, since I did take the time to respond to the original version, I thought that there'd be value in rehashing the comment I posted on that article as a blog post here...
Although Backdrop is a very small community compared to the larger Drupal community, I find it unfair to say that we are progressing at a slower rate, especially for security fixes. The Backdrop security team works closely with the Drupal Security team on issues for both core and contrib. Security fixes for Drupal 7 and Backdrop are coordinated and released at the same time (a big thank you there to our Drupal brethren ❤️ ). Please read more about this in the "Collaboration with the Drupal Security Team" section on https://backdropcms.org/security
I also find it unfair to say that we are slow to fix bugs or implement new features. If you wanna talk numbers, then you can have a look at our issue queue in GitHub. You will see that there is a total of about 4.5k issues raised over the last 5 years, with 2.5k of them closed (so 55% closed, at a rate of 11%/year). The respective numbers for Drupal core are 97k total issues, with 70k closed, over a period of 15 years (so 80% closed, at a rate of ~5.5%/year).
I see that there's an average of ~325 participants in the Drupal core issue queue over time. While we don't collect such stats for our community, I'd say that there's a dozen of super-active community members in the Backdrop core issue queue, plus another one or two dozen of frequent contributors, with the total members registered in the GitHub repo being 110 (total registered users in backdropcms.org being 3750). I'd say that this is a very efficient team, and a faster rate at closing issues than what happens in the Drupal queue (although rough numbers, I believe that my math is right). Perhaps being a smaller community means that there is less "traction" and things progress faster.
Regarding new features
As for new features specifically, we have a 4-month release cycle, instead of the 6-month cycle Drupal has. This fact in itself does not say anything specific, but the number of feature requests in our issue queue are 663 open vs 313 closed. Just to give you an idea, have a look at our history of minor releases. Note that that list shows only the key new features; there are heaps of smaller, less noteworthy new features in every minor release, and we also include dozens of usability and UI improvements with each bug fix release.
It's also worth mentioning that we prioritize user experience (UX) issues. Whereas new features are added only in minor releases (every 4 months), UX improvements are being added at a much faster rate, with each bug fix release. Over time, we have found that all these accumulated improvements make working with Backdrop much faster and less frustrating, with less clicking around to get things done.
Regarding upgrades and migrations
Lastly, when it comes to the automatic migration from Backdrop to Drupal 8 or 9 mentioned in the article, that doesn't happen with Drupal 7 either. There is no upgrade path from Drupal 7 to Drupal 8 or 9 - you have to basically rebuild and migrate. When upgrading from Drupal 7 to Backdrop, your content is retained in the database, and your settings are automatically converted to configuration files. Both Drupal 8/9 and Backdrop require you to do some work on your D7 theme to convert it, but with Backdrop that task feels more like "tweaking" your existing theme, as it does not require rewriting your templates in a completely new language (Twig). So overall, there's less work to do to move to Backdrop.
If you were to decide to move from Backdrop to Drupal 8 or Drupal 9 later, the process is nearly identical to starting from Drupal 7. Your content can also be migrated. You can even use the same content migration scripts you use for Drupal 7, because the database structure for your content is identical. Since there is no migration path for Drupal 7 configuration, you'll be rebuilding all the views by hand either way.
Regarding the "dead-end" road
Let me close by saying that Backdrop is here to stay. Our community is growing, and we have long-term plans for the software. The Backdrop 2.0 release is scheduled for 2025, and we will continue adding new features and improving the 1.x branch for the next 5 years.
We see ourselves as the voice of the ~700k sites still on Drupal 7 😁 ...the owners of these sites have had 5+ years to move to D8, and now D9, but that does not seem to be what they want to do (see https://www.drupal.org/project/usage/drupal).
Drupal 7 a is fantastic software, with a proven track record of success, and a strong history of providing comprehensive solutions to a variety of markets. On the Drupal core usage stats page you can see that since its release back in January 2011, the number of sites built with Drupal increased from ~380k to 1.2 million! Sadly, that number has dropped to 1.1 million since the release of Drupal 8.
I guess that what I'm trying to say is that maybe moving to D8 or D9 is "a decision to opt out of the traditional Drupal paradigm"?