CiviCRM Community Forums (archive)

Thanks for bringing this news here, this is the first time I've heard about this, but it is a bit unsettling to think that after losing so much ground to WP, the Drupal community is going to be further fractured. This raises a lot of questions about how CiviCRM will integrate with Drupal in the future, and what I'm going to do about the Webform-CiviCRM project.

I don't think this is a good thing, and here's why:

It's plain that the developer of Webforms knows exactly what he's doing. He's a key developer, and Drupal needs his vision and talent to keep being useful. There's a decent debate for instance about if Webforms should be just a core part of Drupal, and I definitely think it should be.

So they need him on side, and if he was against these changes he should have been listened to.

A better alternative would have been for Drupal to maintain two versions: one with the benefits of Backdrop, one with the enterprise level upgrades of D8.

Speaking as the only tech at a small charity, I don't think I'll be in a position any time soon to switch to Backdrop, and who knows if we'd want to?

My hope is that Drupal realise the value of Backdrop and make the changes necessary for Backdrop to be no longer necessary.

@JohnFF, all good points.  Unfortunately I don't think there is any way (or desire) to support a branch of Drupal based on Backdrop's approach within the Drupal project/community.  It's not all bad news though.

@jenlampton's post about why she's contributing to Backdrop is a good read and makes the case for why Backdrop will be good for the Drupal project and community http://jenlampton.com/blog/introducing-backdrop-cms-drupal-fork

The developer related issues @mathieu brings up can be summarized by a post @crell made back in 2012 where he coined/popularized the phrase "getting off the island"...

http://www.garfieldtech.com/blog/off-the-island-2013

The idea was that for Drupal to grow/improve, the project needed to stop using so much Drupal specific code, rely less on special sauces/secret handshakes, and embrace technologies developed by other projects so that someone who wanted a site built with Drupal had a larger pool of talent to pull from than just developers who already knew Drupal. 

The need for a less Drupal specific approach to Drupal is desirable goal by every (except maybe the some top Drupal talent able to charge ridiculous rates), but removing database abstraction and relying a more generalized PHP and MySQL skill set is another way to achieve this goal.

In an earlier version of http://backdropcms.org/, @quicksketch compared a simple D7 module to its D8 equivalent in number of files, lines of code, and performance.  The D8 version was substantially bigger, slower, and more complicated.  Not sure where that info went, but I'll post it when I find it again.

The use of YML is still being discussed https://github.com/backdrop/backdrop-issues/issues/78.  The direction that goes will be very telling about how Backdrop will balance performance vs. human readable configuration files.

While the Drupal community is much larger than the CiviCRM community and can "afford" (if not benefit from) a fork, I think the difference in the needs of enterprise level organizations and smaller organizations that contributed to this fork is something the CiviCRM core team should watch closely to avoid a similar situation in the future. 

Watching the folks trying to debug problems w/ CiviVolunteer's backbone.js code at the sprint in DC made my head hurt.  Not that any increase in complexity is bad... but keeping the barrier to entry to some parts of a project lower and managing the amount of change in each release is important to avoid a fork.

Drupal bet that the number of developers like @mathieu they'd gain with Symfony and "proper namespaces and better OOP support" would make up for the number of long time contributors they'd lose.  It's too soon to tell if a viable fork that takes less work/$$ to migrate to changes the odds on that bet.

CiviCRM already does many things better than Drupal including a much better approach to upgrades.  Drupal "upgrades" often required organizations to invest as much if not more than the cost of the original site with each Drupal release and there was never any true backwards compatibility for contrib modules... though in the past the changes to the API where MUCH easier to make that what D7 -> D8 will require.  This "Drupal upgrade tax" wasn't as much of an issue for large organizations who were often investing in new features at the same time as upgrading, but can be a burden for smaller organization.  The "upgrade" from D7 -> D8 will likely be even more expensive for organizations using any custom modules and theming because of how much has to be rewritten and the skill level now required to work with Drupal 8. 

With Drupal 8, the core team made the decision to rewrite as much as 80% of the core codebase.  The API and module structure changes are so radically different that using something like https://drupal.org/project/coder to programmatically upgrade large parts of a contrib module isn't an option.  So while D8 moves even more of what's required to make Drupal a first class CMS (Views, Date, WYSIWYG, etc) into its core, the amount of time it will take contrib module maintainers to upgrade their projects will likely be significantly longer than it was in D7... if they upgrade at all. 

@quicksketch and the other developers involved w/ Backdrop aren't forking Drupal because they hate Drupal.  They are forking because they love it.  They are afraid that many developers will come to the same conclusion they did... that too much effort/expense is required to move sites from D7 -> D8 for too little return in performance/usability/contributions from "off the island" and that Drupal is becoming a solution that prioritizes the needs to enterprise over smaller organizations.

One of most controversial changes Backdrop is making is rolling back is the database abstraction layer added to D7.  This was added primarily to support databases other that MySQL like Oracle, Mongo, and Microsoft SQL.  Removing that along with some of the other changes the Backdrop team is considering will prevent D6 or D7 modules from running on Backdrop "out of the box", but the amount of work required to port a module from  D6 or D7 to Backdrop will be significantly less that moving from D7 to D8.  You can read more about that here...

https://github.com/backdrop/backdrop-issues/issues/65

Hopefully after reading more about Backdrop that you'll see that these aren't changes Drupal's core team is going to even consider supporting, but the hope is that good ideas developed for Backdrop are also adopted by Drupal.  Backdrop will continue to be very influenced by Drupal for the foreseeable future, but as the fork continues to diverge the direction Backdrop takes will be influenced more by its community than Drupal.  If Backdrop successfully "lowers its barrier to entry, increases performance, and positions itself closer to the market of WordPress", the Drupal and Backdrop communities will likely continue to diverge as well.

While Dries has tried to balance his (and his investors) priorities for Acquia with the priorities of the Drupal community, many people believe that these were ultimately too far apart for a single approach to work well for both and something like Backdrop was inevitable. 

It's too soon to tell if Backdrop's approach will actually result in a solution that would appeal to many organizations using CiviCRM, but the developers involved are very accomplished and everything they've written so far about where they're headed has appealed to the non-profits I work with.  I am following Backdrop pretty closely and I'm already planning to invest some time in getting CiviCRM to work with it when it gets closer to a 1.0 release.  The Backdrop team is going to push to get a 1.0 release out before D8 is released so that users and developers can compare their "upgrade" options.   

If you are interested in collaborating on adding Backdrop to CiviCRM, let me know.

There is more, cf. https://github.com/backdrop/backdrop-issues/issues/65
Backdrop will at least change all drupal_ function names, remove some D7 modules from core and add some more.

@xavier... nothing from D6 or D7 will work with Backdrop "out of the box".  The issue of renaming the core hooks that @nicolas pointed out is one update that would have to happen, but probably the easiest to make.  Updates to any query using Drupal's database abstraction, changes required for the Backdrop variation of Views, and moving from .info to .yml or JSON are more complicated changes... but still a small fraction of what's required to rewrite a module for D8. 

Backdrop is also moving the location of modules out of sites/all/modules https://github.com/backdrop/backdrop-issues/issues/11  Because of the work I did to get CiviCRM to run from /profile/[PROFILENAME]/modules, I know that CiviCRM isn't going to play well with that change.

Backdrop isn't going to include/exclude CiviCRM, but the current Drupal integration modules aren't going to work unless they are ported to Backdrop.  My main motivation starting this thread was that most of the CiviCRM/Drupal sites we've been building lately use https://drupal.org/project/webform_civicrm.  If that module isn't going to be updated to D8, I don't think any of these organizations will update until there is an alternative to webform_civicrm for D8.  Since @quicksketch was the driving force behind Webform, that seems unlikely unless Acquia starts throwing bodies at updating it... which is possible.

It's too soon to tell how any of this is going to play out, but I wanted to at least make people aware of Backdrop and start connecting with developers interested in taking a stab at https://github.com/civicrm/civicrm-backdrop

Just spotted that Backdrop CMS has now been released and appears to be pitching itself - in part at least - at small to medium non-profits (i.e.fertile ground for CiviCRM). Wondering what the view is on this in terms of Backdrop being a potential partner CMS for CiviCRM?

Would it be helpful if I created a new branch of the civicrm-drupal repo for backdrop?
I'm happy to do so but probably would only make sense if someone is serious about developing it and would be submitting PRs for it.