maintenance and stabiliity

Brad:

These are good questions. In terms of the stability/reliability of the Backdrop community being around to support and maintain it, I have a few random thoughts. 

1) I am reassured by the fact that BackdropCMS is almost 4 years old and does have a track record of regular reliable releases. The community remains small in comparison to Drupal but contains some pretty passionate, smart, and committed folks. As someone relatively engaged in the BackdropCMS community, I am pretty confident that it will be around at least a few years into the future and I'm not sure how much more I can expect.

2) The fact that BackdropCMS is so closely tied to Drupal at this point leaves me confident that even if the core team of Backdrop contributors disappeared, there are plenty of Drupal smart folks who could step up and help with ongoing maintenance issues and/or serve as resources to keep the project alive. At least for the next 1-2 years, I think it safe to say that security fixes for Drupal 7 will be easily portable to BackdropCMS. 

3) I am impressed by the number of Drupal 7 modules that have been ported to Backdrop and that more are being ported all the time. It is less clear how well the Backdrop community will do at maintaining those modules over time. However, the fact that Backdrop has made it much easier to transfer maintainership of modules gives me some level of confidence that important modules will continue to get the support of the community (which is not necessarily the case with Drupal contrib modules). 

4) I think that the size and structure of the Backdrop community has made it easier for new folks to get involved in contrib. I've officially taken over as co-maintainer of a BackdropCMS module that was ported from D7 by someone else and am grappling with some of the questions that you raise. What are the advantages of trying to keep contrib modules in alignment with their D7 counterparts? What can we gain from watching and participating in the D7 issue queue? What are the disadvantages of taking a D7 module port in a new direction? I'm thinking about these issues and hope to write more about them in the near future.  

5) I continue to run into folks who were big fans of Drupal, but are increasingly frustrated with Drupal 8. There is a big potential market for BackdropCMS as Drupal 7 gets closer to EOL (end of life). I'm not sure how many of these people/sites will make the jump to BackdropCMS, but I think there will be enough to keep the community alive. 

I think it's ridiculous that anyone puts Drupal on a pedestal as the hallmark of maintenance. Drupal 7 has languished for well over a year in the maintenance department, both in core and contrib. No one wants to deal with it; they only want to play with the shiny new things in D8. You can see MANY modules where the maintainers have basically said they aren't doing anything for D7, and D7 site installs still out number D8 installs by a wide margin.

Brad, I'm hoping we will be around for a long time, and I see no reason why not. We havent had significant issues with maintenance so far FAICT. I share spaultim's thoughts on this. 

Until the EOL of D7 was officially pushed back to 2021, we were looking at either upgrading the 1000+ D7 sites we maintain for the University of Colorado to Backdrop or signing an LTS agreement with a vendor.  With a little more breathing room, we continue to evaluate Drupal 8/9 as well as alternatives including; WordPress, Grav CMS, Tome (with D8/9), Wagtail and Neos.

When evaluating Backdrop, we were looking at it both the CMS product and the ability of the community of volunteers that maintain the product. We wanted to really understand how the sausage was made. We took a break from Drupal and had several developers work on Backdrop modules and sites for ~6 weeks to try to answer the question...

Was Backdrop a healthy project/community that we could build sites on and contribute back for the next 5-6 years without owning every feature our users would expect from a modern site building experience or risking hacks?

The TL;DR answer is YES.

Before digging into the details, it will probably be helpful to know that as an organization we "maintain" several D7 popular projects like Site Verify, Google CSE and Secure Permissions. As an individual, I used to maintain far more modules back when the ratio of contributors was much higher.  

Several of the projects the University of Colorado maintains on Drupal.org have been taken over after security issues were reported in a project we were using. While we did some initial work porting the projects we maintain to D8, we stopped investing time in D8 after running into issues that prevented us from running it in a similar way/cost to how we offer D7. While we've offered to add additional co-maintainers for the D8 branches, no one has actually followed through to take those over.

I went to DrupalCon Nashville hoping someone would change my view about moving forward with D8. My view wasn't changed. I am now more convinced than ever that trying to run Drupal as a Service (DaaS) with a low Total Cost of Ownership (TCO) using Drupal 8/9 just isn't possible. You can run hundreds of Drupal 8/9 sites in containers on a service like Pantheon or even run it as a service using Acquia's Site Factory, but the costs will be much higher than what we've been able to accomplish with D7.

Personally, I've seen the Drupal community shift from a time when most people using Drupal were technical enough to contribute and just needed to be guided in that direction to today where the DA and DrupalCon focus more on increasing the number of non-technical enterprise marketing types using Drupal than on the health and issues of the contributor/maker community. As the number of clueless users complaining about bugs in a sandbox or alpha release of a project increased, it really killed any motivation to openly share what I was developing.  

So one answer to "what about maintenance" is that the maintenance of D7 or D8 at the contrib level is already questionable.  The same goes for WordPress.  While the core CMS of both of these projects are stable, the contrib space of Drupal is suffering from a contraction in the number of people and organizations involved and WordPress seems to thrive on anarchy.  While there is much more activity in WordPress (there are hundreds of thousands of plugins and themes), the quality of code is questionable, security and accessibility are often afterthoughts and the licensing models are all over the map.  A plugin update is as likely to make a feature "premium" as it is to fix bugs or add features.

Other projects like Grav or Wagtail have active communities of contributors producing quality projects, but they embrace site builders getting into HTML, CSS and even PHP/Python. This isn't wrong, but it's not going to work for our use case.

Neos is an interesting project.  It started as an initiative to update the UI/UX of the Typo3 CMS, but because the changes to achieve the goals of the UI/UX update would have required all Typo3 sites migrate instead of update, Neos was spun out into a new project that shares some common framework dependencies (Flow) with Typo3.  Crazy, I know! Neos is largely an unknown for us. There are meetups and a conference, but they are all in Europe. It is an option we will continue to evaluate.

From what we've seen, focus and transparency are keys to Backdrop's success and in stark contrast to Drupal.  Not only is it easy to understand the goals of the Backdrop project, but we've witnessed how potential changes are evaluated against those goals openly with every release.  While it is still possible to build basic marketing sites with Drupal 8/9, you are also trying to keep up with core changes required for "ambitious digital experiences" which impacts the maintenance and stability of any non-ambitious site you build on it.

If I was asked about the maintenance and stability of Backdrop, my answer is that it is already MUCH better than Drupal 7, Drupal 8 or WordPress if you factor in contributed modules and plugins. 

The Backdrop community reminds me a bit of Drupal in the 4.7/5.0 days, but with better tooling, process and years of best practice to draw on. Most of the people using Backdrop to build sites are also contributing back to it in some way. The community is still short staffed in many areas and relies on Drupal for much of its security coverage and initial module project code, but in the 6 months we've been looking at and working with Backdrop we've only become more convinced that it is a better alternative that Drupal 8/9 or WordPress for many people using D7.  

Just my 2 cents here.

I've been a Drupal 6/7 user/administrator for some time now. My personal site is built with Drupal 7 and I really like the direction that Backdrop has taken. It's a much better Drupal 7 (although I haven't really deployed a production Backdrop installation, just played with it a few times...). Actually, this reminds me of MariaDB, which was/is a fork of MySQL. In the beginning, MariaDB was an enhanced MySQL replacement. After a few years, it has become a product that stands on its own, with many unique features and optimizations that don't exist in MySQL (of course the latter today has also some unique features not found in MariaDB). And I've seen numerous Linux distros dumping MySQL for MariaDB. My point is that I see the same pattern with Backdrop. And I think it's a good thing.

What kind of worries me is maybe the small number of developers working on the project. Or am I wrong here?

@brad.bulger I worked up https://github.com/kreynen/backdrop_drupal_status_check as a proof of concept. The idea is that users who are just curious about Backdrop could quickly find a badge similar to Travis.ci's pass/fail testing badge that would indicate whether or not a Backdrop maintainer had reviewed changes in a new release of a Drupal project the Backdrop project had forked from.  Some projects were forked/ported 2+ years ago and aren't actively maintained while projects stripped the Drupal version back down to the essential features.  Currently, it's time-consuming to figure out how much of the functionality someone uses in D7 is available in Backdrop.

I was working with @klonos on this, but he went on vacation and I had other fires to deal with. 

Maybe I have an unhealthy view of all things tech but in my opinion, things are changing way too quickly and way too frequently for anything to enjoy a long life for very long. This is bad for society in full but what this means for any CMS is that it's likely going to undergo major changes after a few years, possibly die, or else, it's eventually going to be under a lock-and-key SaaS model where you'll be prevented from editing things like PHP files, accessing databases, etc. Security and privacy issues aside, and in my opinion, this is the biggest problem in today's tech world: it's on a restrictive trend of being used to take things away from people.

Again, I could just have an unhealthy view of things, and if I do, I apologize. I don't mean to be a downer here... It's just that I've seen this sort of thing happen too many times to not believe it. Every vendor I work with at my day job is trying their hardest to steer towards SaaS models, and in their defense, I can't really blame them because I'm sure it's more advantageous and or financially viable to sustain. However, it sure sucks for people like me who love to download and develop on their own without restrictions. In all honestly, I think this is the path that Drupal is taking and I do believe it will lead to its downfall, especially if you take into consideration everything that Acquia seems to be doing. And I completely agree with oadaeh. Drupal 8 is a complete nightmare, especially when compared to what it was like to use Drupal 7. I can't wrap my head around scenarios where a given team of people would lobby for what it's become unless they work within parameters that go way beyond standard non-forceful maintainability situations. But even then, what's worse? Accommodating the demands of the few insane teams with insane requirements that merit the use of those forced tool sets like Composer et al or marginalizing the majority of people that made the Drupal community what it used to be? Maybe this is where the enterprise reputation comes from? Maybe accommodating those bigger players, bigger teams, etc. means more return on someone's investment? I have no clue...

All I know is that people usually avoid products or services that forces them to do things using specific ways that require training just to get started. It's like forcing someone to be a Mandarin interpreter just because they know how to speak English. I think Drupal 8 did that to many people and I'm of the impression that any system that makes things harder to do will eventually buckle under its own weight. I'm also betting that it leads to Drupal's demise unless they pull a hat trick and fix the nonsense revolving around Composer at least. I know they had some people working on a solution to it but I'm not sure where they are with it today.

I doubt anyone knows what the future holds but I know I'm not digging it right now and I hope things change, which is why I'm leaning towards moving to Backdrop for my next project as it's not some sort of restricted SaaS system and it seems to be showing signs of increased adoption as more and more people are looking for a non-Drupal escape route.

(Side note: I work at a state university that uses Drupal 7 for the entire campus. Rumor has it we might be getting away from Drupal after the main team behind the implementation has seen what Drupal 8 has introduced. Kind of makes me sad.)