Introducing Backdrop CMS, a Drupal fork

As one of the self-taught, I have to agree with everything you've said here. Well written post...I just hope that some in the community whose feathers have been ruffled will build a bridge and get over it!

I share the same concerns about learning D8, I got into Drupal 7 two years ago when I took my first job out of uni and have recently had my first module published. I've not delved much into OO PHP but I know I will have to, I suppose it's just the 'new thing is scary' thought that appears with anything new (not just CMS').

I plan to stick and learn D8, but backdrop really interests me at the moment so I'm following it and seeing where it goes.

Thanks for a great read Jen!

Lots of food for thought. I'm certainly not against initiatives like Backdrop or small-core or Drupal-Lite...
I'm just wondering did you consult with the Drupal core team? Were they against Backdrop? Did they decline to work with you? Or did you and quicksketch go it alone without asking whether collaboration might be possible?

The other point I feel worth raising with any new Drupal core, be it D8 or Backdrop is described here: http://flink.com.au/ramblings/backdrop-proves-case-for-top-shelf-modules

All the best with your brave move!

Rik de Boer

I have not had a chance to try D8 yet, but I had been looking forward to learning it, porting modules, increasing my knowledge and becoming a better developer. Now Backdrop presents a decision I had not been considering and do not relish. At some point in the future we'll all have to decide to port to D8 or Backdrop, or to start in D7, D8 or Backdrop. Only when each of us (consultants, shops, in-house devs) gets to that point will we know how this all starts to turn out.

At my current position as an in-house Drupal developer, that decision will probably be mine. The content and design teams mostly know Drupal as "the cms" and they don't really care which cms it is as long as it does what's needed. I'll get to do what's fun for me. In fact, I'll be encouraged to take on new challenges and invest in my professional development.

Part of that decision will come down to what's best for my career. Like many of us I'm sure, I had no idea that Drupal would become a career, but now it supports my family, kid's education, mortgage payments, vacations and lots of fun stuff I want to keep being able to afford.

I'm leaning D8 and taking a wait-and-see position. But there are some points in this post that don't quite ring true for me.

Devs and site-builders have always had to learn and relearn with each major version. I didn't expect D8 to be any different, and Backdrop will also have a learning curve.

Since starting with D5, lots of new technologies have become more integral to having a Drupal site: jQuery, Scss, endless 3rd-party apps, more OOP. Not to mention hosting and configuration management. No matter what platform, learning new things will always be the case if you want to keep up.

Some of the exit strategies listed aren't exactly that easy either, but I'm sure they would also be fun and challenging.

The idea of the "professional computer-engineering world" vs. the "hackable web software world" is a false dichotomy in the case of web apps. I don't have a CS degree, and I'm no CHX, Crell or Quicksketch, but like those of us who came in from the hackable software world, we're not exactly dummies either. We've learned it, and we use it to make enterprise-level apps and earn just as much as anyone with the same hours on the engine.

Although it seems implied in the Backdrop manifesto, I don't think that the majority of the Drupal community has risen to the level of its own incompetence with D8, and it would be wrong to assume newcomers would be any less capable. Nor do I believe that about Backdrop developers.

It's so early in the Backdrop story and the D8 story. Much too early to judge. I'm going to keep working, learning and watching. May everybody succeed.

I'm glad to read that I wasn't the only one who felt stupid when trying (& failing) to get Drupal to do stuff! I think ease of use is such a key importance for software. Developers who overlook this may cut their own wrists. Engineers don't often get it, but sales people realize it when their clients say things like, "We like what your software does, but it's too hard / time intensive / unsupportable for us to take that risk.", etc.

I've been using Drupal since around version 4.6 and it has come a long way, but the jump from version 6 to 7 was hard to make. The trouble I always had was helping people understand how to use and build with Drupal. Drupal 7 made it more complex as most people struggled to understand entities, features and theme changes.

The talk of Drupal 8 actually made me start learning more about WordPress which has been good for me (to stretch my thinking), but I still rely on Drupal 7 for larger projects (colleges, businesses, non-profits, etc). This is why I am so excited about Backdrop. It feels like we can finally have a better foundation for end users and site builders.

I do think it would be great to start with a new, responsive theme base. I envision using PureCSS.io as a starting point or Foundation 4. For designers and themers, it would be great if we could have a WordPress-level foundation to help others understand and adopt it. I am certainly open to helping out where I can.

My initial concern is rather then a concentrated focus on making one system great (Drupal), we would now have multiple mediocre systems. If it's truly the case that developers are exiting Drupal due to v8 initiatives, then I guess I see the need, but it seems that there is always a backlash when new changes are introduced to systems. The right objective has always been to work through those new changes, and as a community strive to make the system better. Forking it has never been the answer.

I could be wrong... just some thoughts

I really like the ideas behind Backdrop, largely because it embodies what I had hoped would happen with Drupal 8. Instead it feels like D8 went the exact opposite direction. I come from a design background and feel very comfortable building sites, and theming. I am also fairly comfortable hacking through things, but have come to grips with the fact that coding just isn't my thing anymore. I got started with Drupal 6 in beta and the move to D7 was rough, and D8 scares the heck out of me. Mostly because I fear I will be reduced to just site building. I also fear that the sites I have built in Drupal 7 will not have upgrade paths. My clients are small businesses, hiring someone to migrate them and start over isn't in most of their budgets. I fear some will have to go to Wordpress, which I despise, because I love what Drupal can do.

I really like what I am reading about Backdrop, but knowing how slowly the modules tend to trickle in on new core versions, I am a bit fearful for its ability to reach mass.

Very well said.

When I first came to Drupal I would have loved D8. However after 4 years of working with it. I can see a lot of virtue in simplicity. Sure not everything is consistent, and sometimes we all curse current Drupal.

D8 smells like a enterprisy Java app, they are not known for there ease of leaning or agility.

I'll help out where I can. Can't see an irc cannel yet?

Oh, and I would have called it snowdrop.

Backdrop will have to develop ways to ease the migration of contrib modules.
If API changes are a must, at least create a conversion module which will do it (semi) automatically.
This will ease migration and will make it much easier for backdrop to succeed.

"Drupal 8 might be going after a higher tier of developer, but I, for one, love the community I'm a part of right now."

I think it's important to be careful with these types of statements since it seems to suggest those who are working on Drupal 8 do not love the community now. It's doubtful folks would contribute at the level they are if they didn't care about the community.

"What bothers me, is that so many people are thinking of leaving Drupal - because they fear that Drupal 8 will leave them behind."

If that bothers you, why perpetuate the thinking that Drupal 8 will leave them behind? Do you not believe developers can learn these approaches? Or, do you not trust the community to step up and offer the training and documentation needed to help others get there?

I know those are tough questions but reasonable, given what is said here.

Hi Jen.

First of all, thank you for taking the time to eloquently communicate your ideas and motivations, and for your many years of passion around Drupal's learnability and work to improve it.

However, I'm troubled by your use of the phrase "higher tier" 3 times in your post. I think it misrepresents the goals and decisions in Drupal 8. For example, neither in Dries's post a year and a half ago, nor in his post last week, nor in any other post of his that I'm aware of, does he distinguish along tiers of developers. I appreciate your follow up clarification, but disagree with that dichotomy as well.

Instead what I think you'll find in those posts is the perspective that Drupal has become more complex (with every version, not just 8), because the web continues to mature. 10 years ago, web services, multilingual sites, e-commerce, configuration management, responsive design, etc., etc., weren't a priority for Drupal. If you look at what it takes to do those things in Drupal 6 or Drupal 7, you'll find that by the time you learn the coding approaches of both core and the dozens of contrib modules you need, that you've had to put in a lot of time to get up to speed. You didn't need a fancy education, or a super high IQ, but you needed time, and in some cases, the help of peers in your local Drupal users group and throughout the community. And I think the same will be true for Drupal 8.

Quoting Dries from his earlier post:

As it has evolved into an increasingly powerful system, Drupal has gotten increasingly complex and is not as easy to start developing with as it once was. Many developers are nervous about continuing that trend. Managing complexity is a challenge faced by many software projects, and one approach is to use standardized patterns and components.

That's what Drupal 8 is about. It's not about higher tier vs. lower tier, formally educated vs. not, professional vs. not. At no point in time has Drupal been the easiest CMS to get started with: its appeal has always been its flexibility to be a good fit for a broad range of websites, the amazing breadth of what you can build with no custom coding at all, and the ability to add in custom code where you need to while still fully leveraging and interoperating with all the code in core and contrib. So the question Drupal has had to face is how to continue to evolve those strengths, given the evolving needs of the web, while still being learnable, understandable, and maintainable. Object orientation and incorporating modern standards, components, and patterns is a way to achieve that rather than the abandonment of those goals. If you've never before done any coding at all, then learning Drupal 8 will be harder than learning Drupal 4.6 was. But once you've done that learning, you'll be able to accomplish more, both within Drupal, and by learning modern standards, components, and patterns, also be ready to take a crack at hacking on any other modern PHP or non-PHP project.

Now, I do agree that there are some things in the current state of Drupal 8 that make for a terrible developer experience, and an especially terrible first impression to someone who just wants to hack together something simple. But Drupal 8 is still in alpha: lots of people are working on improving that.

Jen, thank you for writing up your thoughts and motivations with Backdrop. It is this kind of explanation that's helpful in understanding why it exists and what the goals are.

That said, I don't find your reasons for why a fork is good for Drupal to be very compelling. I can understand feeling frustrated with complexity and I'm certain you know well the frustration of teaching Drupal 7, but a fork seems negative and is non-collaborative. "Sharing ideas and improvements" and "learn from successes & failures" are true, but they're true for any project, regardless of it being a fork of Drupal. That cross-pollination just has different levels of intensity based on compatibility, which leads me to seeing that those two points are predicated on the idea that Backdrop is a "stepping stone" for people who might leave Drupal. Yes, if people leave Drupal they will inevitably compare new code and procedures with old, including with how Drupal works and how they were involved. However, you and the other forkers are *creating* a departure point instead of attempting to further work towards improving Drupal 8. To expand your metaphor, a stepping stone is a stone that lets you make some of the progress away from your current position, not to come back to it.

Additionally I feel that you're doing a disservice in trying to suggest that Backdrop is part of the Drupal community in a way that helps. "Community" is a loaded term with lots of meanings, but in many regards Backdrop is attempting to create a new community with a different home, a different API, and different goals. There is overlap of people between the communities, and obviously similarity in the code, but I don't see how Backdrop could be considered a part of or collaborative with the Drupal community in any way.

I just saw the sfdug message about backdrop. This sounds like an awesome idea. I was at drupalcon pdx and was turned off by the amount of focus I saw going into 8 when I thought that 7 still needed time to develop. I applaud you for what you're doing, learning drupal should be a series of small steps, not having to put what you've previously learned aside so you can do things the "new" way. I hack and learn my way through every project I do, and that's what I love about drupal and the community. Thank you so much for all your hard work.

Thank you for this Jen, you've expressed it well. Drupal is great: complex, powerful yet fun... the rush/race to release is bad but. People haven't had enough time learn, or use, D7 - they're not going to just abandon the not-inconsiderable investment in time and resources made over the last 12-18 months to learn the new paradigms of D8... and by the time that happens, do it all over again for D9...

The problem is branding: in creating "Backdrop", you're diluting "Drupal". Drupal versions naturally persist well beyond the release of their replacements; I can't see a reason to stop working on D7. Why not simply port Twig (and whatever else is worth keeping and can be unbolted) to D7, and keep that version active in parallel?

Thank you for sharing your thinking. Here is my Drupal story and I cannot imagine that it is unique:

I got into Drupal when D7 was released. I spent about a year working with it, built several sites, made a few simple custom modules, and went to local Drupal conferences. I bought some books on module development but around that time details about D8 were emerging. When I realized that anything I learned about making modules for D7 would not apply to D8 I stopped and took a look at Symphony. Well, it seemed that Symphony is the most complex / largest learning curve PHP framework available. I like programming, but I'm coming to Drupal because I want to help people build websites. The programming learning curve for D8 may not be worth it for me.

I kind of imagined that the user experience for D8 was going to be better / easier than D7 ... so if you never needed to look under the hood it might be fine. Is that correct? Of course, the pool of available developers for D8 will probably be smaller than the current one for D7, so if you need customizations you might be screwed.

In terms of a fork, wouldn't maintaining compatibility with D7 contrib modules practically guarantee wild success for Backdrop? Then adding "update core from the admin UI" and back porting some of the user interface stuff from D8 would make it even more awesome?

Well, lots of people in the community will be following Backdrop's progress. Good luck and best wishes.

Forking Drupal is a shortsighted approach to a long term problem.

While I get the point it would be nice if there was something more intutive than the current builds of D8, there's a reason it's as complex as it is. Systems eventually reach a point of complexity in proportion to their usefulness. Backdrop will have the same problems one day if it is successful, or will be a waste of time if it's not.

Surely there's a better solution here?

"Let's make it easy to port contrib modules and themes from Drupal 7" -- If there's coder upgrade support for D7 to backdrop then that'd be a no brainer. If it's learning backdrop, a platform that will be hosted external to D.o, then porting modules to that and to D8 to hedge bets, I'm porting to D8. I may not be happy w/ having to learn all new stuff but thus is life. I wish you all the best but if it's not D7 compatible or nearly D7 compat OOTB there's really very little reason to migrate from D7 to Backdrop. As it were, there is going to be very little reason to migrate D7 to D8 for many years outside of the FUD stirred up by most "security" releases, many of which are easy to compensate for if the issue is documented.

I look forward to following how Backdrop does and if/how the community supports the effort. If nothing else it provides a good evening of discussion at local user groups. We had a lively discussion last night at the SacDug meeting. If Backdrop hopes to "compete" with WordPress there will need to be a lot of "designers" and non-coders on board, so I do think this fork has a chance, but it will really need to streamline the process for us partial coders. Best of luck and will see you at BADCamp.

I am a big fan of Drupal, and have built 50 or so sites with Drupal 6 or Drupal 7. I am not yet very familiar with the changes that Drupal 8 will introduce, but the key for me is performance.

On a regular Wamp setup on Windows (not fine-tuned, just a straight install), a clean Drupal 6 install loads in a few seconds. Drupal 7 is at best twice as slow (that is true on production sites too). Drupal 8 alpha 3 take one or several minutes to finish loading. Now, I know the wamp setup is not optimized at all, but these comparisons are made on the same machine with the same setup.

If Backdrop addresses performance, I am all for it!

Jen, thanks for sharing your motivations.

I was recently talking with some folks about how Drupal 7 (and Drupal 8 more so) are not cost effective for the long tail of projects. That is projects with a lower budget (thousands of dollars rather than tens of thousands of dollars). When I started with Drupal this was a segment that was easily hit. Doing the same types of things now takes more work. When you're working on Backdrop it would be great if there were ways to ease the burden and make things easier to do.

When I look at Drupal 8 the big things I see sticking out is targeting the more traditional enterprise programming culture. This how I label it rather than some levels of programming. That almost says you need to become like this culture of programming to become better at programming. This is not the case. Better developer experience includes being able to do more with less work and less complication.

I'd argue the old enterprise ways are slowly in decline. The enterprise companies like HP, Oracle, and IBM are all making product shifts because of it. Take a look at the code of OpenStack, the open source cloud project the enterprises are jumping on, and you'll see a codebase that doesn't look all that old school enterprisie. Times are a changing.

I do know a number of people with Drupal exit strategies going forward. You are spot on when you say that some people are doing that. I know some who are already out. I've recently discussed strategies with some others who are looking to talk about it. Have you reached out to some of these folks to find out what would keep them around but using backdrop? Just to get an idea where they are at.

If there were one piece of advice I'd give you is to help people succeed. Don't build software to build software. Build solutions that help people succeed at the end of the day. The long long line of people who use the software but don't contribute to the development. It's both satisfying and useful to do that.

I wish you and the rest of the backdrop folks the best of luck.

Thanks for the congenial explanation of the motivations and goals for BackDrop. However, I view a couple of minor things differently, and don't follow some of the motivations. I feel that I can speak to some of this, as I fit into the group of (long-term) self-taught: I've self-learned and forgotten most of around 10 programming languages, and started learning Drupal when D7 came out (and have struggled with it more than any programming language).

1. If I am going to invest my time in learning something, I want it to be worthwhile (which is part of why I chose Drupal over something simpler). I bet most self-learners have the same motivation. So:
1. concepts from the professional computer-engineering world: I want to learn the best concepts, not 'hackable' concepts.
2. 'high tier of developer': I want to learn from code by written and organized by fully-knowledgeable developers (not 'hackers' like me). An early learning curve is usually made up for by well-organized and followable code.
3. Symfony framework: I want to learn the best, rather than the easiest-to-learn, framework. (Analagous to the choice to learn Drupal). A side plus: we don't have to document it, something we as a community are weak at.
4. Object-oriented code: I self-learned OO over a decade ago for C++ and later used it in Perl. It's not that difficult to learn — far easier than D7. With my valuable time, I'd prefer learning professionally-written and organized OO PHP code than 'hacker' procedural PHP.
2. remove nearly all the old Drupal code from Drupal 8 vs. fixing areas of Drupal 7: Removing most code is made to sound bad, but it seems that if you want to fix the non-intuitive spaghetti nature of Drupal, a major rewrite sounds preferable to a piece-by-piece approach. I don't follow how a modification of D7 could be a 'lightweight product for low-budget sites'. The major rewrite sounds preferable here.
3. the problem is documentation vs. not intuitive enough: certainly agree on 'non-intuitive', but not documentation. A lot of things would have been so easy to learn if only there were guides to common and best-practice usage.
4. Already discussed widely: since we already don't have enough core committers, I don't follow how a fork wouldn't hurt this.

In sum, I myself don't follow the logic of such a fork appealing to self-learners: a lot of the things D8 is doing are things I'd want to spend my valuable time on. It seems more like the fork would appeal to the self-learners who have already gone through the pain of learning D7 and want to keep that working knowledge, and don't want to learn the new code, framework and OO code. I also wouldn't expect a piece-by-piece approach to improve comprehensibility, simplicity or budget-development better than a major rewrite.
I hope I have expressed myself in as congenial of a way as you have. Thanks!

I've listened to the podcast, downloaded the fork, and contributed to the Indiegogo campaign. The reasoning behind the fork is pretty sound and really resonates with me. The road to make this successful is going to be long and difficult. It will require thousands of volunteers, and as of today, I am committing myself to help with this. Godspeed, to all of us!

I started building Drupal sites late in the game with Drupal 6.19. In fact only one single site did I build with D6. D7 came out and I've built a few dozen or so more sites since. I've never had the need to build a custom module, and have no desire to. My point here is that I have been very happy and successful "site building" with Drupal without ever really getting into the guts of core. I've played with D8 and I don't think the move from D7 to D8 will be a huge for "site builders" and front-end themer types, etc (I'm also a Sys Admin running Aegir on multiple cloud platforms, so I know my way around CLI). If anything I think D8 is a quantum leap forward for site builders and think, with D8, the average Joe freelancer/site builder will be able to point, click, and drush our way to some really great sites for small or large organizations, and still be able to support them.

Personally I'm going to stick with Drupal moving on to D8, I'm not really interested in the Backdrop CMS. I'm just really having mixed feelings here that SO MANY of the Drupalers I admire and respect are breaking off to pursue Backdrop CMS.... :/ I'm sure my post has helped no one, but it felt better at least for me to talk about it :) That's my 2 cents!

--Tony @drupleg

Kudos, Jen.

I create Drupal sites and modules, but that's not my job. My goal is to help university faculty use learning research results in their courses. Drupal is a means to that end. It lets me create formative feedback systems, course design visualization tools, SWIM (show-what-I-mean) editors, pseudents (pseuo students), and other Good Things.

I chose D6 to start this project, in part because I could program D6. Notice that I'm the one doing the programming. There is no professional software engineer available.

Suppose I had been making that decision now, not a few years ago. D8 would violate one of the constraints of my project: no software engineers. D8 would not be programmable - for me, right now. I would have to learn professional s/w engineering practices. While I was doing that, I would not be making progress on my project.

The reality in my world: Drupal is less important than my project. I'll use whatever tech gets the job done. Yes, I'm a techno ho.

What would I use instead? Maybe WordPress. It has gained some Drupally features since v3, such as field-like things. Maybe one of the Pythonic CMSen. Python is Good. But I would have to check, to make sure they were more D7ish than D8ish.

Bottom line: hooray for Backdrop! Hooray for Jen! Jen! Jen! JEN! JEN!

Kieran

'At the start of Drupal 8 development, a decision was made. Drupal would shift all its concepts and design patterns towards professional computer-engineers, and in doing so attract a "higher tier of developer".'

I have felt exactly this for months and months-- but never saw it crystallized and referred to as a 'decision' until now. At least I know I'm not being paranoid.

I have been a part of the open source world since the late 1990's and watched many projects fork as the diverging needs of its users become impossible to address in one code base. I hope that everyone in the Drupal community will come to realize and appreciate that the forking of Drupal is a natural part of its evolution.

Whether Backdrop ends of being a useful fork for a meaningful number of users remains to be seen, but I do believe that fork-time has come. Indeed, I have thought for some time that D8 really should have been a fork of Drupal since it makes so many enormous changes and really does increase significantly the emphasis on the needs of larger organizations (e.g., enterprise). Nonetheless, the forking of Drupal is a good thing, I believe.

Given what Jen and Nate have written about the purpose of Backdrop, I look forward to seeing a roadmap for its future. As a competent site builder and mostly incompetent developer, I hope that Backdrop emphasizes the following:

+ Configuration management. I spend far too much time managing the updating of code from dev to test to production and dealing with the huge PITA caused by the storage of configuration in the database.
+ Outdated documentation. There is a lot of documentation for Drupal. Most of it is outdated and sometimes misleadingly so. Writing a lot of documentation once is really not all that useful. Writing less documentation and keeping it current is much more useful.
+ Too many contrib modules that do the same thing (or try to), that are outdated and are not maintained, and that are poorly documented, if at all. The Backdrop community should set a higher standard for contrib modules (and themes) so that ordinary users do not spend so much time trying to figure out how to use contrib modules and how to deal with buggy contrib modules. Establishing some level of QA for contrib and end-of-lifing modules that are not maintained would be a huge service to users.
+ Too many different base themes with no meaningful contribution of subthemes. For any new user of Drupal, figuring out which base theme to use is a nightmarish burden. Finding subthemes that implement each base theme (beyond the starterkit base theme provided by the theme's contributor) makes choosing even more difficult.
+ The authoring experience needs to be simplifiable without requiring the installation of multiple contrib modules. In most cases, content authors need far fewer options than are presented by the standard Drupal node creation page.
+ Maintaining upgradeability or even migratability to the D8 path is really not that important and probably is unrealistic. Just make it as easy as possible to get the data out of the DB.
+ Performance. We all know Drupal is a resource hog. I don't understand all of the reasons that contribute to the poor performance of Drupal on a basic Linux instance. Hopefully, Backdrop can address some of these issues.

Thanks for your efforts and for opening your blog to comments.

I have always admired yours and Nate's championship of developers such as myself who keep managing to stumble through Drupal. There really is a constant fear—and I am certainly not alone in this—that I will fall off the back of the Drupal bus and get left in a ditch with a bunch of obsolete knowledge. I barely hung on with the transition from 6 to 7 and I'm embarrassed to say that I still don't fully understand 7.

I've come across many hard-core developers whose responses to my struggling have undertones of "Guess you better suck it up and work harder," or "If you can't take the heat, get out of the kitchen." It's true technologies for the web are getting harder and more complex, but Drupal was always the guide who had my back and didn't require that I know absolutely everything, just a smidgen of a handful of things. This left me time to work on artwork and design while leaning on the code of the community. Now I'm having to learn SASS, Compass, Symfony, Yaml, Twig... It's becoming increasingly difficult to be a solo freelance website developer.

What interests me most is that you mention Backdrop being more of a stepping stone. This is exactly what I need: a friendly passerby that will stop and pick me up out of the ditch and drive me to the next Drupal bus stop, whether it be stop #8, or further down the road to stop #9.

I am just in the group you are talking about, being fed up with Drupal mammoth approach to stepping down on server claiming more and more and at the same time being more complicated to site builders and site users (clients) and YES, I admit I am looking at Ruby with a smile! (on the other hand I do like learning and I will learn it anyway. Just a question that AFTER I do learn it, will I stay on Drupal? Is it worth to me as it used to be?)

Yes, forking is good, it is what the freedom is all about, freedom to fork and to choose.

I've sent personal mail to Nate supporting his decision and I do support yours as it is not the same when small me leaves the boat and core people like yourself do the same. I never feel easy about one man shifting away and others in top Drupal tier should ask themselves what is going on. MANY top developers are not content and except everyone being polite and politically correct, let's be honest and ask yourselves what the heck is happening?!

On the question of BackdropCMS, there are two things I strongly hope for:

1. Build on performance (speed, memory) like Pressflow for Drupal 6, be the real Pressflow 7 (maybe merge there?)

2. Please stay 100% Drupal 7 compatible, both in core and modules. Let's not make new Joomla case (forking outside). The best route would be to change the core for speedup, maybe better semantic, maybe HTML5 but not at expense of compatibility as that would severely damage both projects.

Frankly speaking, I don't understand this buzz and flutter.
Everyone sounds like D7 is going to vanish, and it is dead as soon as D8 hits the scene?!?! Why not simply maintain and contribute to D7 like before? If D8 is so different, it will need time to catch-up in regards of modules anyway. I see absolutely no reason why those two versions should have problems in coexistence?! Regarding backdrop: Why a "fork" for people that want to stay with D7? If there was a need for a fork and changes, why now and not earlier? Now it sounds to me like a "replacement for a vanishing D7", which is not my impression at all.

I'm a self-taught hack that got in at the end of Drupal 5, finally got comfortable with 6 and am just now feeling proficient with 7. I definitely appreciate the sentiment for improving upon D7 without a massive departure in coding, as I really don't have time to re-learn. It's a hobby for me on my personal site and a necessity for maintaining a test lab database system at work, so I'd certainly be exploring other options if I find D8 to be a bit much for me.
I'm sure this was a difficult decision to arrive at and see the argument from both sides, but I think there would be quite a bit of demand for this fork and hope it won't be detrimental to D8.

I am - to a degree - what one would call a "professional developer" and I liked Drupal for its simplicity. If you want something mind-****ingly complex, you can safely buy into typo3. From my point of view, with what they are doing, they risk to create a bad mimic of typo3. I believe Drupal is moving too fast. The ideas of the people are way to focussed on what more and better they can do in the core. Sometimes it is better these "high flyers" move on to create a whole new product and let the old one just evolve.

I have seen this world of "frameworks" ... 400 lines to write a hello world application. It is NOT the holy grails. Have a look at the hell of ruby on rails. Try to take e.g. Redmine (which Acq. happily embraced). You got a 10:1 chance to fail the installation running into a deadlock of version dependancies on any Linux distribution. This is the mother of all frameworks! Why is that? Because the core evolves faster than the distributions and modules and applications. With many D6 setups still out in the worlds D8 will be too early.

Other example GNOME is being counted out because KDE is more solid on the core. GNOME got forked into Mate. Is that good for GNOME? You may keep telling this to yourself if you so wish.

To do a revolution and call it just another major version is leaving many old friend behind.

I will likely turn to Wordpress and keep in touch with Backdrop, but the Drupal 8 will most likely no be my platform of choice anymore.

A pitty!

When I hear: get rid of the old menu structure. I always believe this was the most admirable feature in Drupal. With D8 people do not develop forward, they join the masses of people who did not understand what they were messing when they overcomplexed the world with even more XML.

I farce.

Sad,
Adrian

Thank you Jen for articulating a lot of what has cooled my enthusiasm for Drupal in the last few years (I just noticed my d.o profile is nearly a decade old yikes). I don't really follow what's happening much with the Drupal community any more, but just now stumbled onto this Backdrop news.

I'm not a full time Drupal dev and not a professional, but over the years I've built/maintained/rebuilt a complex Drupal site with lots of custom modules including a whole bunch that extend CCK and Organic Groups that will need something drastic done to it before D6 support runs out. Frankly the prospect of porting it to D7 is looking daunting and decidedly unfun, and redoing it using a Python framework is looking more and more viable as an "exit strategy". The site has gone through 5 major Drupal version upgrades since 4.4, but D7 is just too much churn. D8 will be even more again later. It's not just the changes to core either, it's also the contrib ecosystem churn necessitating migration to a new set of modules each time.

Last time I looked about a year ago D8 was sounding like an exciting prospect to me (CMI yay, REST yay), but now it just seems like an overengineered stack of Java-like abstractions on top of abstractions. It no longer seems as though it's worth going through D7 to get there. The "hackability" of D5 & D6 was its appeal and that was good enough for me to grudgingly use PHP. I'm not worried about OO at all - just the style of OO that D8 is heading towards as opposed to the more direct pragmatic styles of Ruby or Python.

I completely understand where you're coming from and I wish you guys all the best with Backdrop. Although I probably won't coming along for the ride, I really hope you succeed in building a sustainable project.

I when I look under the hood at the code running Drupal 7, my head swims-- moreso when I look at that number of function executions happening to generate even the simplest output. I have listened to presentations about Drupal 8 and I have been impressed. That said, I have used CodeIgniter and it has a really high level of system expectations. In the 1990s, when I swapped from Perl to PHP, it was because a Hello World script could be as little as <?php echo "Hello World"; ?>.
I have worked out how Drupal 7 works and I am really comfortable with it now. Likely, I will stay with it well after the release of Drupal 8. What I would wish for: a CMS that makes simplicity of code and a small processing footprint as its two biggest considerations. Drupal is not that; Drupal 8 will totally be high maintenance.
When a group invents a CMS that is scalable and flexible, Drupal's days will be numbered. I'd love to take on that challenge, but I don't know if the world needs yet another CMS product.

Wow, quite a discussion. Jen sent me a link to this after I asked her if I should wait for D8 to release before starting a couple of projects. (Her and I are both working on Thanksgiving Day.) This long thread makes my decision easy, build on D7 now.

I'm a newbie to Drupal and developing marketplace platforms to solve problems in various industries. I'm an entrepreneur so these projects are for me, not a client. I only need enough functionality to test ideas and hopefully find market traction. D7 seems to be fine for that but it needs substantial UX / UI improvement.

I watched Dries' keynote at Drupalcon Sydney. He wants to develop software that will power Amazon and Apple. Wonderful, but I don't want that stuff. We've seen the pain that kind of software can cause. (Healthcare.gov? The failed systems at the FBI and FAA?)

I've been on the sidelines of software application development since the 1960's with IBM's System 360 project, the first real business computer, and punch cards. While I love coding I prefer working with coders to develop software to solve biz problems or give competitive advantage. This is called dev/ops now. (I tried to talk Jobs into building me a computer for job costing for construction companies in 1977.)

I helped develop the original desktop software for a couple dozen industries.

My wife is in dev/ops for a 6,000 employee national employee benefits brokerage. She helps with internal app dev, employee training, and more. We talk daily about their issues.

So from this perspective and 4 platform marketplace sites to build I read the above thread.

The fork is the correct path to take. Backdrop should target SMB, small and medium business, and let the D8 folks go after the Fortune 1,000. These are different markets with different needs and IT abilities. The code should be elegant enough to maintain and work well. The UI needs to be friendly to the target market and features meet their needs (UX). Nothing else matters in biz. Wildly different upgrades are unwelcome. They are new software and require more due diligence and add stress.

The discussion here shouldn't be about 1st or 2nd tier developers and what is best for module devs. It should only be about meeting the requirements for a market. If you are hitting a market well and there is lots of paying work the modules will get built much faster than designing software to make it easier to update modules.

There is a lot of awkwardness in D7 that should be fixed such as the blocks / panels / views thing. These are nice functionally and I love the power but the whole concept needs to be reworked. This is what Backdrop can do and it may inform Drupal. Backdrop is the main branch of Drupal. D8 seems to be a fork.

Thanks everyone for your wonderful work and as I get more into Drupal I'll contribute.

Jim Preston
SV Startup Lab
Santa Clara, CA

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

I certainly agree there are a lot of things that should be finished out in Drupal 7. Take for instance AJAXifying forms. Why are forms not using AJAX by default when it's already built in and the entire web is moving in that direction? Just upgrading the forms with AJAX would improve the user experience by mountains.

But why regress Drupal 7 from where it already is? Especially the abstracted database layer. While this may not see important now, what happens in 18 months when MySQL has a major vulnerability and Oracle refuses to fix it?

I think moving Drupal 7 forward is the way to go, not regressing it to something that will quickly become outdated.

I've got a small handful of Drupal sites that I do all the work on. I consider myself a newbie to Drupal. I've been learning on an as needed basis per each sites need. Personally I'm very excited for Drupal 8 but appreciate the option to fall back on Backdrop if I struggle with D8.

I know php, however my programming background is a couple C++ classes in college. Everything past there is self taught. Maybe its that background that has me excited about D8's transition to OOP. I really like creating neatly packaged objects (classes). It allows me to separate concerns and focus better. I feel I end up with a more flexible and powerful result from OOP.

The procedural hop from function to function nature of Drupal has made it difficult to learn module development and understand core. I feel like I have to find the end of a thread of yarn and then follow it through a cobweb of functions. I imagine some would say OOP is worse. But again maybe because OOP is where I started it, I find it easier to understand.

Another example would be Drupal's crazy arrays of arrays of objects with arrays etc! Until I started using phpstorm and xdebug trying to dig in and find where and how data needed to be accessed was a nightmare of dsm() and print_r. But even still I much prefer the standardization to accessing variables, methods etc that comes with OOP.

The most frustrating part of Drupal currently for me (as someone new, trying to learn web programming and Drupal at the same time) is what I refer to as "module hell". I've spent hours,days,weeks downloading modules testing them, trying to string multiple modules together to get where my customer wants. I get 90% of the way there and then comes the "Can you just add this.." request. Unfortunately the modules I've selected suddenly fall short. I find myself trying to explain technical jargon to the customer who's eye's glaze over. They say "this new request is absolutely necessary". I run to my computer screaming, then tear my hair out trying to hack my way into a module that's code seems a random collection of functions with no idea how they tie together. That last 10% becomes a 24/7 hacking marathon. At the end of each of these "bouts of fun" I find myself doing google searches for "best php framework". I find my self thinking "if I had just built the site from scratch or off a more base level framework...". Yes it would be harder, it would take longer. But when the dreaded "Can you just add this" requests come in I would be dealing with something I understood well and could simply go in and make the necessary changes.

For me the jury is still out on that last issue, I'm not sure either Drupal 8 or Backdrop will really address that for me. I lean towards D8 because it seems they're going to great lengths to use current standards and best practices. Or maybe I'm better off just learning Symfony, especially since D8 is using some of its components.

Anyway that's my 50 cents (post is too long and rambling for it to be just 2 cents), I wish both parties the best and plan to keep an eye on both.

Interesting, I'd not heard of this.

I consider myself to be a real-world site builder, in that I'm a trained graphic designer who picked up html, javascript and PHP in the late 90s, then learned a (very) little C/C++/Java along the way. I can handle a little OO, but I certainly don't live and breathe it.

I found Drupal 6 (my entry point) to be an immense pain in many ways. Some stuff was just really really hard to do, and fragile to maintain. Drupal 7 - once I got past the resistance to change - was certainly a considerable improvement.

Recently I decided to bite the bullet and develop a real small business site on Drupal 8. Gulp.

So far, apart from the bits that are still changing or just plain broken, I've been pleasantly surprised - once things mature, I think it's going to be FASTER for me to get a small, responsive D8 site up and running than a similar D7 site:

CMI is shaping up to be far far better than the Features/Strongarm kludges needed to manage configuration and (especially) deployment in D7. yml configuration files are very human-readable and hackable.

The twig theme engine is clean, does a far better job of separating presentation from logic, and prevents the sort of ridiculous insecure template php kludges that new users or Wordpress escapees seem to love.

Out of the box, Bartik is responsive and subthemes pretty well. Picture module in core is a huge win, as is the html5 shiv and modernizr support. I have not found it difficult to swap out jQuery to retain some IE8 support.

CKeditor in core with real Drupal forms in plugins is just great.

I'm writing a little custom module code to temporarily work around the lack of a few key contrib modules for now (Pathauto, Redirect), and have not found doing so to be an overly epic journey.

Sure, it's new. Sure, a lot of sites will stay in D7 for a long long time, especially if the long term support proposal works out. But once contrib starts catching up, I really won't hesitate to build SMB sites in Drupal 8.

I'm excited by the cultural promise inherent in this suggestion to fork Drupal.

But for the idea to catch on, it can't be just a crew slaving over the new release, outa sight, outa mind.

Backdrop has to be gaining mindshare, and acquiring an identity. To become something, it's important to have like-minded folks coming together on the idea.

Did it already fizzle? Are the leaders sequestered in a private maelstrom of code & policy issues?

I'd love to see a vibrant & lively Backdropcms website pulling those of a susceptible sentiment into mutual orbit.

Is that going to happen? :)

I don't have a problem learning Drupal 8, my issue is that conversion will be impossible with my sites from 7 to 8. One site in particular uses about 20 modules. There is no way all of these are going to be ported to 8, just as many of the great modules died with Drupal 6. I am so used to these modules, so dependent on these modules, that I can't move to 8. For most of us, our decision of what tool to used is based on functionality. Without modules and themes, Drupal 8 out of the box is almost useless. Even if I could find updates of all my modules to Drupal 8 versions, I can't imagine there could be a smooth conversion. I would have to manually update a lot of the content. To me, Drupal 8 is for new users or new websites. I can't upgrade any of my existing ones to 8.

Thanks for voicing what I have been thinking for years. Kinda cool that you are in Oakland where I was born and raised. I came Drupal a decade ago from Typo3 ezpublish and Midgard. I was a bit divergent in that I warned the comminity against over engineering (drupal loosingtraction by being too much like Typo 3) and the lack of the use of PHP5 going forward. I was summarily branded, black balled .. what have you. I tried to alleviate someof the shortcomings I saw by forking Drupal to make it php5 compatible. Again branded as being a 'forker' ;)

The was a much talk about how my Nostradamus moments would never become real. Yet here we are. Backdrop is a necessity and I will support it as much as I can. I will also continue on a path that I started back in the d5.5 days by working on my own fork again. Because OOP in PHP is good and easy to learn and use, it is the future of web development. But OOP does no have to be a monolithic one size fits all kind of thing or a single paradigm from a single source or even multiple sources claiming to be a single one.. So I will prove my point yet again with real world coding. I will not be starting any community but going the lone-wolf route and making my code and ideas available to all on git hub without pre-judgement. Just take the code and do it! do it your way if you happen to get a viable and thriving community going then go with it! If it make you some cash along the way I am happy for you!

If you and others are going to invest in such a big effort and time, why not invest the same without forking and spreading the community?
Here is some suggestions:
1. Develop a module or something else that convert from D7 to D8 and from D8 to D7.
2. Create an initiative/task-force with volunteer to port anything one can imagine (this can be fun if we create contest with prizes, trips, conference, etc...)
3. Create a proposal including data backing up the "anti-D8 sentiment" or "D8fobia" and push the Drupal core team to be sensitive to it, maybe they will do suggestion 1 and 2.
4. Create a "Pre-D8" group inside Drupal community to brain-storm the D7 to D8 and D8 to D7, I am sure we can come with dozen of idea the does not require dividing the community.

I just don't like the idea of splitting the community, Drupal is Drupal and is Drupal because the way things are done on Drupal,
and if we like Drupal we should stick together.

Think about how many more things cold we do, how strong would be, if Linux did not had so many forks, some of the distro only have a different logo. We have diversity like Windows, iOS, Unix, Linux and I believe that is a good balance, but Linux is out of control and the amount of time one expend deciding witch one to use is too much.

Hi Jennifer,
Very nice post. Drupal is really great. Really great summary of changes. One important point to mention is the addition of layouts as a concept of itself, separated from the theming thanks to Panels in core.

I like the idea of forking D7. I must have spent 150+ hours learining Drupal 7. I'm guessing D8 will bring another 150+ hours of learning.... Maybe less since I will have lots of D7 experience by then. Learning Drupal does have it's rewards. Lots of demand at every level amd D8 should add to that since it is adding lots of complexity.

There needs to be something between WordPress which I like and hate. i like it's user simplicity and hate it counter intuitiveness from the development standpoint.

I'd guess it might be 2 to 4 years before the Backdrop community begins to form.

I'm interested now. I do not see any modules. Maybe they are on GitHub? For the things I like to build, I only need a handful of modules.

I really like the idea of you wanting to build Backdrop to run a cheap virtual hosting. D7 runs good on cheap vhosting.... until you add a couple modules... then it slows.

I am really glad I found this. I left Drupal a few years ago for Wordpress and I'll tell you I often feel bad about it. I started with Drupal 6 and banged my head against the wall learning it. I got pretty good with it technically and thematically. I got to 7 and started to feel, that everything took forever to do- maybe worn out :). I often felt that there were things in it that could of been improved but when 8 was in discussion, I was ready for that exit strategy. My main 'gripe' was the manual system update. Every time there was an update, I cringed. I hope that maybe Backdrop can help with that issue may be in the future. Today, I downloaded Backdrop and like what I am seeing. I know its D7 but even the styling gets my attention. It's sparking that renewed interest. I totally get the MVC patterns and I am in partial agreement for the course of D8 but to me I dig the mission you guys are trying to achieve.

I'm strongly supportive of the Backdrop initiative. My experience as a consultant stretching back to the 1970's argues that the "best" software is that which is addressed to the market in which you are placed. The solution will evolve over time. That's both inevitable and desirable. How it evolves will depend on the current and expected users, and what they feel they will need. Drupal 8 is clearly aimed at the Big Boys&Girls. The abandonment of Drupal Gardens is indicative of the direction in which Drupal is moving. That may lead to a greater and more exciting and more powerful Drupal, but it's not likely to lead to a better fit for smaller organizations. My connection is now strictly as a volunteer (I'm well past retirement age). All of my sites are minor and address audiences that are modest in size. Backdrop seems a much better fit to the needs of my sites than does Drupal 8. Given the markets the solutions are intended to address, my bet is that Backdrop will continue to be a better fit. Thanks for your efforts, ... and let me know if I can help with the evolution of Backgrop

Jen, thank you *so much* for this post. I am an old Drupalero. Been in Drupal for about a decade and generally loved it. D8 is too much for me. I think maybe its too much for the really smart people: so much overhead and abstraction. There's a reason D8 took so long to come out of the oven.

I understand the value of abstraction, but at some point it's too much. I don't think the D8 back end code I've seen is "elegant", but then I don't do OO. I remeber at a DrupalCon (Barcelona?) where ChX was warning that he was an old procedural guy and didn't like OO. I don't either. Maybe D8 is the way forward for the "highly skilled Professionals", but there's a lot of us who've contributed who don't fit into that category (and don't want to).

D8 is losing a whole mass of Drupal contributors who could pop the hood and tinker and fix (and occasionally break!) Drupal. I'm definitely looking at Backdrop and considering it for new clients who want long term support and can't afford the regular major upgrades from the highly skilled professionals. D8 is too much for me! I might be able to learn it, but I don't think I want to invest the time. Keep up the great work for the community!