Drupal has officially forked... led by developer of Webform module

[kreynen]

It doesn't take much to fork the code of an open source project.  With a few clicks, anyone can clone a repository on GitHub and start making changes.  Normally the plan is to merge the changes back into the original project, but sometimes the goal is stay forked.  Staying forked requires a good reason for the fork, a lot of planning, a few key developers from the original project to drive the new project and a critical mass of users that follow along. 

Forking the community is more than just making changes to the code and that happen w/ Drupal this week when @quicksketch publicly announced http://backdropcms.org/

There is a lot of information about why he started this fork, but the main motivation appears to be to roll back some of the changes made in Drupal 8 that have made creating a simple module much more complicated and contributing to the project much more difficult. 

Backdrop is intended to be a home for developers and users who might otherwise consider adopting other platforms. The goal of the project is to provide shiny new features built on an iteration of the existing Drupal 7 APIs: before Symfony, PSR-0, and the "Drupal Kernel".

It's no secret that Acquia has been driving changes to make Drupal appeal to enterprise-level customers.  It's too soon to tell if Backdrop will become viable alternative to Drupal 8, but @quicksketch has made it clear that he will not be updating Webform to D8 "any time soon".  Since webform_civicrm has become an increasingly popular feature when integrating CiviCRM w/ Drupal, it seems like this would be a critical missing feature for many organizations that might consider upgrading to D8.  @Dave Reid (what doesn't he contribute to? https://drupal.org/user/53892) recently asked to be removed from the list of D8 maintainers and is currently actively working w/ @quicksketch on Backdrop.   Since @Dave Reid has been the driving force behind the improvements to Drupal's media handling and that is a critical feature for community media groups, it's possible those organizations will want to move to Backdrop before they'd rebuild their site in D8.

I had already decided that it makes more sense to rewrite most of the CiviCRM related Drupal modules I've written as native CiviCRM extensions than rewrite them as Drupal 8 modules.  If Backdrop extends the life of a more D7 like CMS, even better.

I really like long time Drupal contributor @rfay's take on the fork...

http://pingv.com/blog/backdrop-forking-drupal#comment-1039032146

One thing I said when the major Drupal 8 changes were being decided on: "I believe that going this way is actually a fork of Drupal. The architecture change is radical enough to convince people it's a fork." So it may be fair to call Drupal 8 the fork, and Backdrop the mainline.

Regardless of how this plays out, it's definitely something any organization running CiviCRM paired w/ Drupal should be watching.  This should also be interesting to watch from the perspective of a member of the CiviCRM community and CiviCRM's project leads. 

 

[Coleman Watts]

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.

[totten]

All the more reason for Drupal users to adopt a CRM like CiviCRM, which is designed to run under multiple CMSs...

[JohnFF]

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.

[mathieu]

Thanks kreynen for the great summary. Although I have to admit I'm still a bit confused. At first I thought "this is something that will compete with WordPress", but it doesn't seem to be the case?

Looking at the commit logs, they removed core modules such as forum, openid, ip_blocking, statistics and tracker. They state that they want to add Views, CMI and WYSIWYG. This is far from being equivalent to WordPress. Although for Drupal 8, some say that for the first time, Drupal will ship with a "minimum viable product", e.g. Drupal core ships with the minimum to satisfy "standard expectations" from users.

I like modules such as Webform and Views (to some extent) because they are user-centric: you can just install it, do a quick training with the user, and let them roam free, they will figure it out, and the visual output will be reasonably themed by default. The "entityform" module seems more dev-friendly (if you like "entities"), but less user-friendly.

As a developer, I like the idea of Symfony2. It brings proper namespaces and better OOP support. The syntax for yaml files isn't very different either, and at least it's something more standard, used by other communities outside Drupal:

* The new module .info.yml files: https://drupal.org/node/1935708
* The new menu routing system: https://drupal.org/node/1800686

Although, I think the debate that needs to happen is whether we want a user-centric CMS, or developer-centric. D7 was probably meant to be more user-centric, but because of the really long release cycles, they couldn't get much user feedback, and can only do very limited iterative improvements in minor versions. I personally really appreciate that CiviCRM is more user-centric, while still having pretty good tools for extensions/API, 6 months release cycle (faster user/dev feedback), and even a 4.2 "long term support" branch (avoids pressuring users to constantly upgrade if they are happy with the features they have).

[kreynen]

@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.

[xavier]

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

My understanding is that if a module works for D7, it will work for backdrop, isn't it? So backdrop is already added to civi or is there something more to do?

X+

[nicolas]

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.

[Coleman Watts]

Watching the folks trying to debug problems w/ CiviVolunteer's backbone.js code at the sprint in DC made my head hurt.

We chose BB because it seems to be gaining a lot of adoption among js devs and a good way to get off our own island. That said, it does seem to have a steep learning curve (glad to know it wasn't just me). I wonder if there are other clientside frameworks we should have considered that are more popular/easier to learn?

[kreynen]

@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

[Coleman Watts]

Ooh. Aah.

[Upperholme]

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?

[Hershel]

Backdrop being a potential partner CMS for CiviCRM?

In my opinion, CiviCRM should definitely support Backdrop CMS. Certainly, we need to wait and see if the project indeed continues to advance and has users etc. But the intended audience certainly strongly overlaps the userbase of CiviCRM.

[Coleman Watts]

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.

[petednz]

Unlikely but in case this gives anyone ideas that might save work

http://tag1consulting.com/blog/how-maintain-contrib-modules-drupal-and-backdrop-same-time-part-3

presuming one would read parts 1 and 2 first ;-)