Posted on September 20, 2013 // Short URL

Backdrop: A Drupal Fork

For this episode, Addison Berry is joined by Nate Haug and Jen Lampton to talk about their new project, Backdrop, which is a fork of Drupal. This is a shocking move in the community, and has generated a lot of questions and concerns. We talk about the motivation behind the fork, who's working on it, and ask about the negative impact this can have on the community. We asked on Twitter and Facebook for what questions folks had, and we got a ton of responses. Addi asks these questions to Nate and Jen, directly from the voices in the community. Join us as we try to clarify what is going on with Backdrop, and the implications it has.

The questions we managed to get to are:

  • I'd really like to know about their UX strategy to reach the sitebuilder - Bojhan (Twitter)
  • Do you plan to release a commercial version? - Nadir Palacios (Facebook)
  • Do you have a roadmap, what type of dev will it best suit, how do you differentiate against other CMS, are you planing a camp? - pdjohnson (Twitter)
  • Any details on timelines would be great. Also the whole contrib module issue - Paul_Rowell (Twitter)
  • At some point in the future module developers will need to pick @backdropcms or @drupal. Doesn't this profoundly hurt both? kcolwell (Twitter)
  • Will current D7 or future D8 modules and themes work with #backdrop? - ModulesUnraveled (Twitter)
  • What is the compelling reason for customers to choose Backdrop over established platforms like WordPress, Joomla, EE, & Drupal? - gdemet (Twitter)
  • For nonprofits on tight budgets, D7 is already expensive. I worry D8 will be worse. Might @backdropcms help this? - hanabel (Twitter)
  • Do you feel D8 prioritizes enterprise dev to the point where BackDrop's needed to fill smaller niche? - hanabel (Twitter)
  • Backdrop rolls back 1.5 years of core commits, removing many many patches representing improvements to a whole host of systems. All the community work on efforts on issues related to things totally unrelated to CMI and Symfony was tossed out. Work on mobile, work on accessibility, work on lots of little fixes, all gone. With a small core team, how do you fix that? Does Backdrop just toss away all those improvements and the community that made them? It just seems like a lot of wasted work. - MarcDrummond (Twitter)
  • How would you respond to criticisms that say #backdrop is a bad idea like this - ModulesUnraveled (Twitter)

[As a note, we will also have a podcast with Drupal 8 contributors to get another perspective on this story, so please understand that this conversation is not complete with just this podcast.]



Backdrop needs to die

For sake of both sides, Backdrop needs to die a quick death. This is silly and doesn't help either side. Reply

Joaquin Bravo C...

Just by existing

Backdrop, just by existing, is forcing a lot of talk on Developer Experience, easy of use, complexity, performance and the core values and principles of Drupal. I think having that justifies its existance. So backdrop is making drupal better. =). Reply

Anonymous Coward

Abandonment of the serfs and plebs

One thing that is a huge part of all of this hand wring about Drupal 8 and/or support for a fork is the acknowledged and planned abandonment of the serfs and plebs who literally helped make Drupal what it is today (e.g., all the non-comp sci volunteers who made core/contrib, as well as developers/site-owners of non-enterprise sites). The masses got Drupal to where it was based on "contributing" lots of free hours evangelizing/coding, and now Drupal (and to a large degree, Acquia) are saying thanks for all the fish and moving on with their ball to green pastures. It's their right, but it's also going to have an effect. Good or bad the choice is clear - follow Drupal into the enterprise or else find somewhere else to go (backdrop or otherwise). Reply

Gábor Hojtsy

Acquia contributions

As for what Acquia contributed to Drupal 8, we had a team of developers and designers work on in-place editing, WYSIWYG, much easier editor configuration, UI editable layouting (did not make it), mobile friendly toolbar,device preview, accessibility, front end performance, etc. We also sponsored the Views in core team, and work on the new user friendlier node form, an easier to use blocks UI etc. If we focused our efforts on things, those were actually mostly beneficial for site builders. The device preview we are proposing is actually being largely debated because it would only be useful for the layman, who cannot buy all those devices... At least this is what I have seen working on Drupal 8 stuff at Acquia for the past year and a half. Reply

Anonymous Coward

Well, if you make the whole

Well, if you make the whole roadmap I guess you might as well contribute. Most of what you cited benefits enterprise efforts plenty. Dries has stated that he is focusing specifically on enterprise so I don't know what there is to either argue about or get defensive about. It's just the way it is. Reply


Having to learn APIs, OOP,

Having to learn APIs, OOP, leverage classes and the like for a tighter and consistent experience does not make it some barrier that 'drops serfs and plebs'. It's up to people to choose if they want to learn, adapt and change. It's not too complicated. Reply


Drupal needed to be refactored

Drupal needed to be refactored for D8. It was about time to modernize the underbelly. If you actually think about it, Drupal 9 is going to allow us to polish, clean-up and move at a smaller, more iterative pace. Heck, we are even discussion that D8 can have minor improvements and not just bug/security fixes. We rebuilt the car's engine, now it's time to do the paint and upholstery. Maybe since we have already done most of the heavy lifting in D8 to remove some of the DXWTFs, we can focus on not breaking everyone's site between major versions and waiting three years to do it- one of the major goals of Backdrop. I think that Backdrop people are jumping a little too early and will be kicking themselves by around mid-release of D8. Reply

Anonymous Coward

As just a lowly site builder

As just a lowly site builder ready to abandon Drupal 8 I am so happy to hear about this fork. I love Drupal but see D8 becoming outside my reach. Another thing that has bothered me has been what appears as a growing elitist attitude towards self-taught developers among some in the community. I hate to see Drupal split in two but glad to see an chance for people like me to continue creating site with a Drupal like system. Reply


You are not going to notice a difference

As a lowly site builder, you are not going to notice a difference between what you need to know in D8 and backdrop. Yes, it will be different from 7 and different from eachother, but they are still a robust CMSs/CMFs. It's the developer experience that is going to be different. Reply

Zach Chandler

Hey now

There is no such thing as a "lowly" sitebuilder. Sitebuilders are awesome, and you should own that! Reply


Drupal 8 is built by power

Drupal 8 is built by power users for power users. I get it. Those who make the greatest contributions deserve the greatest voice in the software. However, the result is a solution best suited for big shops who service fortune 500 caliber clients. Alternately, those who work with small businesses might have a hard time justifying the added expense of developing with niche frameworks and maintaining a devoted hosting environment fast enough to run it. Reply

Gábor Hojtsy

power users, really?

I'm not sure where that "for power users" comes from. Yes, there are several improvements for power users. Here I just presented a session today for an hour on how Drupal 8 makes it easier for everyone to build multilingual sites for example. It is chock full of things like "better built-in software editing UI", "now you can translate your site name", ".po imports will not time outs on low resource systems", etc. Check it out at Total power users will hire a firm to do their translations on a 3rd party system and integrate that with a workflow tool. That is not what we did in Drupal 8 for multilingual. This is just one of a huge set of changes obviously, there are a host of other examples from inline editing, WYSWYG, views in core, etc. Reply


To be Clear

Gábor, I'm talking about frameworks because the non 'power user' I'm referring to is engaging Drupal on a development/theming level. Sorry if that was unclear. Installing WYSIWYG and Views in core is great, but it only makes their job 5% easier. Meanwhile asking them to install and master Symfony and Twig makes it 50% harder, at least to begin with. ------ A lot of them are coding designers like me. It's tricky enough to keep up with PHP, JS, CSS, SASS, Command Line, Drush, and the myriad of other APIs needed to create simple modules and themes when Drupal isn't your core competency. Now I have to learn object oriented programming too?------ The high cost of entry is one of the reasons why Wordpress is slaughtering Drupal on my side of the market. Dries knows it. That's why the ship of state is pointing the other way. From my point of view I can stay put and drown, chase Drupal 8 as it flees and drown, wait for Backdrop and probably drown, or swim toward Wordpress. Reply

Georg Huber

You're not only clear - you have a point!

Your above comment reflects exactly what I am thinking. Most "high-roller" coders in the big Drupal shops ignore that we lowly developers very often have to write a module to fulfill the whishes of our clients. And all the red tape to get the results is getting out of hand. I'm looking into WordPress and MODx. This year I will have to set up three medium-sized sites, one for an organization with 4000 "real-world" members and I wonder if I still can take the risk of using Drupal. And the funny thing is: I do like Drupal 7 and I do like the community. What I don't like is getting told that I need to take a run to even get starting. Reply

Anthony Pero

As a designer, I came to

As a designer, I came to Drupal 5 in order to get rid of the 30 different tools I needed to use to enable the Web 2.0 features all of my clients needed. I'm not a programmer. I love that I don't need to be in order to built fantastic sites that actually help my clients run their businesses. My concern with Drupal 8 has always been moving away from PHPTemplate. Its all I've known, so to speak. I'm really not keen on learning a new system of theming. I don't have a lot of time to devote to it. Ok, I don't have ANY time to devote to it. From a site building standpoint, I've played around with D8, and it seems pretty darn awesome, but I tried to build a theme... and I barely got started and all of a sudden two hours had passed. Suck. So, I probably won't move to D8, and I'll be staying with D7 for a bunch of years. I'm just too busy to learn a new system, and I don't have enough of a foundation in programming or other templating systems to easily learn a new system. If Backdrop is successful, hopefully this will ease some of my concerns about moving forward with Drupal. Reply

Ivan Jaros

I understand the "unknown"

I understand the "unknown" that Drupal 8 brings and I feel like many other developers that learned to develop websites on Drupal do - like I have to re-learn everything I know form scratch. But on the other hand I am happy with many things Drupal 8 brings and that by learning the OOP-way and catching up with the latest trends in programming, I'm improving my skills. In my opinion the Backgrop guys should just devote their time to prolong the Drupal 7 maintenance. So instead of two(?) year maintenance support after D8, D7 would be maintained for a few years longer. That way, projects running pre-D8 would have enough time to prepare for D8 migration or just stay with D7 for many years. Also in this case, D7 could get new features instead of just bug-fixes. That way everybody would be happy and the community would remain united. Not to mention that all modules would still work, which is what a lot of this fuss is all about. Reply

Angela Gann

The Irony of Serfs

It is really funny to me that the primary reason for creating the fork is to not leave the serfs (ie, noob programmers ) behind. For years there has been discussion about the drupal learning curve being a cliff. My experience with learning Drupal was that it was like learning a new language with its own syntax on top of PHP. I do work for a company and there is discussion about whether Drupal is the right tool because finding hardcore module devs is very difficult. Part of the goal for using Symphony2 was to make Drupal more accessible to PHP developers who come into Drupal and ask why can't they just do things the way they're used to without jumping through Drupal's hoops. This may turn out to ultimately be a good thing for the community or not. Time will tell. I would ask that the situation with OpenOffice and LibreOffice be considered and the confusion that it caused, as well as merging the code bases back together. There are way too many poorly coded sites out there. A lot of them are built with procedural code. Getting folks to learn best practices out of the box is better for the web as a whole. For instance...would you teach a developer to use align = center in html, or would you teach them css to start? Today...the answer is to learn CSS and HTML at the same time. In this case, I think teaching OO practices is the way to go. The DB abstraction layer was also there to help support multiple databases. Does this mean that Backdrop won't support many DBs? I understand the concerns, I just don't think splitting the community is the answer as both individually will be weaker. Reply



This is something I'd heartily support if it wasn't for Twig. Why are we fixing something that's not broke? Reply