You are here

Introducing Backdrop CMS, a Drupal fork

I love working with Drupal. I feel fortunate that I found a software and a community where I can work for work, and work for play. It's not everyone who gets to do what they love every day. I get to interact with amazing people from all backgrounds and walks of life, share what I learn, and learn from others. I especially like that this community can often agree to disagree.

Here's where you might disagree with me: Drupal 7 was too hard to learn. Drupal 8 will be harder just by its virtue of being more complex. I want there to be an easier alternative, for example: Backdrop CMS.

The Backstory

Back in the day, Drupal used to be hackable. And by "hackable" I mean that any semi-technical yahoo (that's me, btw) who needed a website could get it up and running, and then poke around in the code to see how it all worked. The code was fairly uncomplicated, though often somewhat messy, and that was fine. At the end of the day, it did what you needed.

Over time, Drupal grew: it gained features, got more flexible, covered more use-cases, and gathered more fans. A community of developers grew up around Drupal, some of us are professional computer engineers, some of us were self taught and learned by reading and writing Drupal code, and some of us just learned enough to get by.

When Drupal 7 was released, things had changed significantly from Drupal 6, and though most of us now agree that learning the new system was worth the time, it was a painful transition for almost everyone. Drupal adoption slowed to a crawl for months after the release, many modules were slow to be ported, and the number of sites running Drupal (at least according to Drupal.org) actually decreased for a while.

It was hard for the professional computer engineers to grasp what the heck Drupal was doing, and it was hard for all the self-taught to learn all the new patterns and changes on top of what was known before. It was hardest of all for those who knew nothing about Drupal before their exposure to Drupal 7. The sum of what needed to be learned had reached new heights.

We realized that somehow in Drupal 7's development, we'd crossed a threshold. Drupal had suddenly become too hard to learn. I experienced this pain first hand as the Director of Training at Chapter Three, I trained hundreds of people on building sites with Drupal, building Drupal themes, and building Drupal modules. I realized that the problem was not lack of documentation (or even a lack of good documentation) the problem was that Drupal was not intuitive enough. I love Drupal, and I want it to succeed, so I devoted myself to making Drupal easier to learn ("learnability") and easier to use ("usability").

It was thought that one of the reasons Drupal was so hard was that it was mixing new concepts from the professional computer-engineering world, with old concepts from the hackable web software world. 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".

Though many people bought into this idea at the beginning of development, nobody really knew exactly where the road would lead. Today, core developers are working hard to remove nearly all the old Drupal code from Drupal 8. The old way of doing things is slowly being replaced with a new way. Info files are being replaced with yaml. Info hooks are being replaced with annotations. Theme functions are being replaced with Twig templates. As of today we only have a 25% code overlap (by line-number differences) between what was in Drupal 7 and what will be in Drupal 8. There will probably be even less by the time it's released.

Now, I'm not saying the new way isn't better. A lot of really brilliant people I greatly respect poured hours of their own time into thinking these problems through, as well as making the actual conversions. What I'm worried about is how this will affect the existing Drupal community.

Today, the majority of the people in our Drupal Community aren't CS engineers. They are self-taught Drupal experts, people less technical than myself, and people who can get by using this awesome software we've developed to help make their lives easier. What is the transition to Drupal 8 going to be like to them? Well, I asked some non-core developers, and I didn't like what I heard.

A lot of professional Drupal developers already have exit strategies. They may even have a day job building or maintaining Drupal 6 and/or Drupal 7 sites, but they go home at night and study Ruby, Node.js, Angular.js, even some are looking into WordPress. They want to be "out" before they have to learn Drupal 8. These are smart, capable people, who I'm sure - if they wanted to - would be able to pick up Drupal 8. So, why are they leaving? Because Drupal 8 has become different enough that learning it feels like learning something new. If they are going to invest in learning something new, why not Ruby, or Node.js, or something else?

Enter Backdrop CMS

What if we could go back in time to when we decided to attract that higher tier of developer, and make a different decision. What if we decided to cater to the existing Drupal community, instead?

Let's look instead at what people found hard about moving to Drupal 7, and make those areas make more sense. Let's leave the rest of the existing Drupal 7 APIs alone (if it ain't broke, don't fix it) and see if we can add the new features people want on top of the architecture they already know (and love!) Let's make it easy to port contrib modules and themes from Drupal 7, and encourage our developer community to focus on delivering new features, rather than re-learn everything they used to know to make an administration page for their module (for example).

Would this kind of direction prevent a Drupal Colony Collapse? As it turns out - it might. Of the people I've spoken to (the ones with exit strategies) they all sound not only interested in a CMS that more closely resembles Drupal 7, but have offered to contribute (even though some of them have never even contributed to Drupal before).

I love the current community: masters, hackers & newbies too

Drupal 8 might be going after a higher tier of developer, but I think we should be focused on the community we have right now. I love that we have self-taught masters of Drupal as core-committers, Drupal trainers, professional Drupal developers, and all the way down the chain. What bothers me, is that so many people are thinking of leaving Drupal - because they fear that Drupal 8 will leave them behind.

I'm worried that the "hackers" may no longer find Drupal approachable, and we may not get many more self-taught Drupal experts moving up the chain. Walking in the door at Drupal 8 is going to be exponentially harder for these people than Drupal 7 was - and we know how much people struggled with that.

I want to catch those groups of people. I want to tell the developers not to leave, tell them that we still have a place for them. I want to catch the hackers, give them a light-weight CMS where they can pop the hood and tinker freely. I want to provide a place where they all can continue to crank out awesome websites that meet their needs, the needs of their clients, and the needs of the causes they believe in.

How can a fork be good for Drupal?

This thing we're doing, it's a big deal. And some people believe it will be bad for Drupal. I, personally, disagree. I still love Drupal, and I think a fork can be a healthy thing for a software project. Here are some of the reasons I think Backdrop CMS can help Drupal and the Drupal community:

  • Almost all ideas for Backdrop improvements can be shared with Drupal
    Though it's unlikely that much of the code developed for Backdrop can be directly applied to Drupal 8, most of the ideas will be 100% transferable. There are already issues in both queues referencing what the other is doing.
  • A stepping-stone for developers who may otherwise consider leaving the Drupal community
    There may be people who are afraid to learn Drupal 8 when it's released, but who aren't afraid to move to Backdrop. If these people use Backdrop for a year or two, and then later feel confident enough to move on to use Drupal 8 in the future, we've kept them in our community.
  • A lightweight product for low-budget sites that may otherwise consider adopting other platforms
    There may be projects that can't afford a Drupal 8 developer, or can't find someone to port contrib modules to Drupal 8 in their time frame or within their budget. Backdrop maybe a suitable alternative for these projects because modules can be ported more quickly from Drupal 7, and developers already familiar with Drupal 7 will be able to use it right away.
  • A safe place to try new things (pull requests, semantic versioning, large team of core committers)
    Since Backdrop is not Drupal, we'll have the the freedom to do things differently. The Drupal community can watch what we do, and see how it goes.
  • We can learn from each other's successes & failures
    Along the same lines as the above, if the new things we try fail miserably, the Drupal community will know not to try them. And if they succeed, they Drupal community may want to give them a try. Likewise, Backdrop has already learned a lot from Drupal, and we'll continue learning.
  • Competition drives progress
    Even since the announcement of Backdrop CMS, Drupal as made huge strides in improving the developer experience. Even if this project fails, I believe that Drupal software will be better off for it.

But, what about the Twig "initiative" for Drupal 8?

Don't worry, the Twig initiative is in good hands. We have a really great team working on Twig and the new Drupal 8 theme layer. Mark Carver has offered to step up and run our weekly Twig meetings, and be the general overseer of all things in the Twig initiative.

Yes, I have decided to step down as the Initiative lead for Twig in Drupal 8, but only because I didn't want there to be any conflicts-of-interest (real or perceived). My motive has always, and will continue to be, the same: I want Drupal to be easier to learn. Twig and the Drupal 8 theme system cleanup helps move Drupal 8 closer towards this goal for front-end developers, and I still believe strongly that it needs to succeed. There is still a lot of work to do, so I will still be participating in meetings, and sprints. I'll be present in the issue queue, and in IRC. I'm fully supportive of all the work that is still going on in this area.

Wait, what?

There are a lot of really great people working on a lot of really great things in Drupal 8. None of that should be understated. I still deeply respect all the people involved in Drupal 8 development, and no one can discount the thousands of hours that went into improvments. I also believe that Drupal 8 will be successful.

Backdrop is just another Drupal-like product. When Backdrop is released, we will have another Open Source product in the CMS landscape. When the time comes that I have a new project that needs a CMS and Backdrop is a viable option, I'll choose the right tool for the job.

I'll still be working with (and contributing to) Drupal until then.

I want to hear from you

Before today I hadn't turned on comments on my personal blog. I'm turning them on now, for this post. Please share your thoughts below, and if you have any questions or concerns, please feel free to voice them here. I'll try my best to respond in a timely manner. (I know that emotions are high right now, but keep in mind that we are all working on something we care about greatly, and please be respectful in your comments.)

Comments

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

Yes, we consulted with the Drupal core team. And Yes, most of them were against the idea of Backdrop.

The focus there is on changing things here and there to improve the developer experience. Mostly this is being done by adding more layers of abstraction to hide the scary and/or confusing stuff from the every-day lives of contrib developers. Though this approach has merit (who wants to worry about dependency injecting their own links?) I feel like it's a slippery slope. Another layer of abstraction can fix anything - except for too many layers of abstraction.

There are some major philosophical differences between what the core team wants for Drupal, and what we feel is necessary for a successful CMS. Is learnability the priority, or is it an elegance in the architecture? For us, it's the former.

IMO an elegant solution is one that is the simplest yet fits all the requirements. An elegant architecture should be the same. It should be as simple as possible to the extent where necessities are met. Drupal is trying to become more flexible, and flexibility requires complexity. So, if something is more complex how can we learn it? As you suggested, we create new layers of software to hide some of the flexibility so the software is approachable. I am not saying that D8 is building its layers of abstraction correctly, or that some things aren't over-engineered (over-engineered != elegant), but the bottom line is that any system should strive for both elegance and learnability. I have not been in the backdrop issue queue for a few days, but it seem that backdrop's answer is not "let's create the appropriately elegant solution", but instead it wants to take away flexibility for the sake of learnability. Am I seeing things in the right light? and if that is the case why do we want a less flexible Drupal?

You're close. We want things to be easier to learn, but we have not yet found a place where we need to sacrifice flexibility in order to achieve that. Almost all the new features Drupal 8 offers can still be accomplished on the old architecture. That's also why we don't feel that all the new changes are necessary, and why we feel that we can still build a viable product without them.

"Who wants to worry about dependency injecting their own links?"

That quote shows a severe lack of understanding of what dependency injection is. I can't think of any correlation between dependency injection and links. In fact, on http://en.wikipedia.org/wiki/Dependency_injection, the word "link" is only mentioned because all wikipedia pages have "External Links".

The only positive I see coming from Backdrop is maybe future iterations of Drupal won't have to be dumbed down for the "hackers".

I was specifically referring to an issue where the l() function (that's how you create a link in Drupal) was converted into a 'proper service'.

No mention of dependency injection. A routing service that provides bi-directional transformation between routes and URLs is a very useful component. So much so, we've had one around since Zend Framework 1, I presume Symfony 1, and better iterations that correctly incorporate dependency injection in both Zend Framework 2 and Symfony 2: http://symfony.com/doc/current/book/routing.html

Dependency injection isn't an option, it's the correct way to develop software. I have no idea what "dependency injecting your own links means", but a routing service that can be used to generate links **SHOULD** have it's dependencies injected. Your other option is to hardcode dependencies, making the service inflexible and difficult to test.

Well, It sounds like Drupal 8 is the right tool for you.

However, there are a lot of people who feel that creating a link should not need to be that complicated. We believe it is not necessary to replace a simple function for spitting out an anchor tag with a routing service for generating links.

For us, I'm planning on working on Backdrop. To each his (or her) own? :)

All this talk of injections and dependencies is probably one of the reasons I would be in favor of the fork.

caveat 1) I am not a developer, nor do I have any formal training in web development.
caveat 2) This is the first I've heard or read of a Drupal fork.

Clearly in the life of any popular ideology, there is some forking... (look at religion for instance.) I believe it is fair to say that Drupal is just as much an ideology as it is a tool. I would go so far as to say it is more of an ideology than a tool. For users like myself, it has become evident that Drupal is the the adult table at the CMS family gathering. If you need additional development environments such as Zend, Symfony or whatever, to do elegant Drupal, it is immediately talking above my skill level. I love the Drupal philosophy, but I believe an argument can be made that D8 is actually more of a fork than what I am hearing about Backdrop. D8 is a major departure from D7 and has left neophytes like myself who are just barely comprehending the intricacies of D7 behind. If it weren't the "official" Drupal moniker, some would consider it a completely different product.
When any product or service becomes as popular as Drupal has, it has to decide where it's core audience is and it is abundantly clear to me that Drupal is, first and foremost, a developers tool (and a damn fine tool!). If that is where Drupal's heart is, It's only fair to expect that someone is going to take this open source framework and modify it. When you have hundreds to thousands of users who agree on these modification, you will see the birth of a fork. This is a testament to the greatness of the parent product, but also a testament to the fact that no one tool will fit every use.
To be against forking in open source seems counter-cultural to me. If Drupal wants to move on, I will not hold it back, but I also will not be dragged kicking and screaming.

Nicholas, thank you! For helping me formulate for myself why I don't want to be part of Drupal 8 :) I guess the formulation would be "elitism" and "correct way to develop software".

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.

Thanks for the great feedback.

I seem to have a hard time expressing the "professional computer-engineering world" vs. the "hackable web software world" in a way that's not offensive to people, and still gets my point across. For starters, the two are not mutually exclusive. There are a lot of great people who started as a web software hacker, and are now professionals.

What I'm worried about is the initial code complexity of D8 being a turn-off to those hacker types. People who pop the code, realize instantly that there's a bigger picture that they don't quite get yet, and are intimidated by it. Yes, there will be those who jump in anyway - but the more complex we make things to start, the smaller the number of people who make it through to the top. I want to continue to be a community full of those people, and I'm worried that D8 threatens that. Would Drupal the Drupal community still have a Catch or an AlexPott if they had to start with Drupal 8? I'm sure it wouldn't have a jenlampton or a quicksketch.

I also share your concerns about modules being ported to one system vs the other. However, I don't think things will end up too different than today. About every other project I work on still requires that I port one module or another to Drupal 7. I'm hoping that by making it quicker & easier to port things from Drupal 7 to Backdrop, the barrier comes down and more gets done. Time will tell.

Though the choices are hard, I do think having more options is generally a better thing. But I'm also in favor of everyone succeeding :)

Jen and folks,

I have no CS or engineering training. I studied geography and religion. My first CMS attempts in 2006 were in WordPress where "hacking" connotes something that is good.

After my first WordPress upgrade which overwrote all my code customizations and finding the tone on the help boards often nasty, I found Drupal.

At Drupal I learned the religion of "don't hack." At Drupal.org I followed many issues, especially in core development, where there were philosophical issues discussed. Though I had no CS training I found myself able to understand the conversations. I liked it so much that people took a passioned philosophical approach.

As I started doing Drupal professionally as a site-builder around 2008, I found I had an advantage over a lot of coders. Often coders, typically those who had not been partaking in the philosophical discussions and were not interested in them, were coding way too much when they were building real sites for real clients.

I really understood that the less custom code there was in a site, the more stable and cheaper it would be to maintain it for the client that I was trying to deliver value to. Sometimes that meant convincing a client to change their requirements in order to fit what existing, stable, well-coded Drupal modules could do.

I've learned to code, and to love code, but I'm still not good at it. My strength is being able to evaluate other code. I don't usually do that by looking at the code itself, but by following the discussions in the relevant queues.

I don't know where I'll fall out on how I feel about BackDrop. I have known for a long time that Nate Haug is in a very small elite of absolutely fantastic module maintainers. With Nate being involved, I'll be paying attention.

But I guess the reason I'm writing this is to share that there are people who are not CS folks or engineers who have appreciated Drupal's passion for code elegance and who appreciate the determination of the community to keep pace with the world by being willing to throw out a lot with each major upgrade in order to get at something that is truly better. At this point at least I have to believe that "better" would trickle down to my clients (small businesses and small non-profits).

But I'll be keeping my eyes and my mind open as I follow closely the evolution of Backdrop.

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.

We can certainly do a better job of cleaning up interfaces and making things easier to use (& understand). There has already been a lot of great work that has gone into Drupal 8. We'd like to continue that effort with Backdrop as well. Hopefully some of the time we're not spending re-architecting can go into some of these other areas of Drupal that also need some serious attention.

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.

All of Drupal 8's themes are responsive out-of-the-box. None of them make great base themes yet, but as part of the Twig/Theme system clean up we will be trying to change that. Backdrop should aim to achieve those same goals.

The jump from Drupal 6 to Drupal 7 was a big one, I complained loudly back then that we were leaving too many people behind, and that too many of the changes we made were not benefiting the majority of Drupal users (see my Engineering for the 80% talk for more on that).

The jump from Drupal 7 to Drupal 8 is not the same. It will be harder by orders of magnitude, and that's exactly what I'm worried about. Who are these changes for? If they don't directly benefit the end-users or the contrib developers then we are not engineering for the 80% (and imo, we should be)

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 disagree that "forking has never been the answer". I mean, it worked out pretty well for WordPress. ;)

If the things we're worried about could be solved by adding a few more issues on Drupal.org and working through them, we wouldn't be here today. When the differences become differences in philosophy and focus, and groups of people are trying to steer the project in different directions, that's when a fork becomes necessary.

I share your concerns about diving focus (I feel it personally with my desire to work on both Twig patches and Backdrop pull requests). Each person has only so much time. But I also know that there are core developers who have stepped down from working on Drupal 8. If they can be happy working on Backdrop instead, they are more than welcome. I expect the same will be true of contrib developers.

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.

I share your concerns about modules being ported from Drupal 7 to Backdrop. But I'm even more worried about those modules being ported from Drupal 7 to Drupal 8, because it "scares the heck out of" a lot of people. That's exactly why we are working on Backdrop. The goal is not to change too much from Drupal 7 so that the process of porting should be relatively straightforward. If all you had to do was change an info file to a yaml file, and change some variables to configurations - you might even feel empowered to port those modules yourself!

*that might be a bit of an understatement - but you get the point

Jen,

you mention "scares the heck out of a lot of people". I honestly think that is unnecessary "scare" tactic from your side - it certainly scares you and some other people but you need to show data about how many people are actually worried about that otherwise it is used just as a negative anti-Drupal 8 marketing/tactic.

It's hard to count all the people it's scaring for a lot of different reasons. Some of them are leaving (some have left already). Some are afraid to admit how much it scares them because they are "Drupal Experts" and feel their jobs may be at stake if they were to say it publicly. Let's turn it around, can you show data on how many people aren't scared by Drupal 8?

Also, I was replying directly to Scott, who mentioned that it "scared the heck out of him" - so this isn't a scare tactic coming from me. It's coming directly from the community.

No, I am scared. I have been scared if there would be a place for me with Drupal 8 since Portland.

Well, I'm one of these scared people out there. Three years ago I switched from HTML + JavaScript websites to CMS websites and finally found Drupal - via the usual milestones called WordPress and Joomla!. I started with Drupal 7 and learned and learned and I'm still learning. But now I can do a lot of things via my own modules and I'm starting to "understand" some of the structural ideas behind Drupal 7. But still there are so many things to learn. And now - just when the fog seems to be lifting - the Drupal gods are going to change the now familiar landmarks which I started to glimpse in better detail.
I'm not scared of coding. The obstacle is to understand the structure itself and how things interact. I'm in awe of the persons who really know their way around Drupal 7 and know all of the whys and hows.
I'm not stupid, though: I'm a freelancing physicist and I make ends meet by developing hard- and software. Building websites is part of the portfolio I'm offering to other freelancers and small businesses. Each hour I have to invest in reorienting my inner bearings to the new Drupal 8 landscape is scaring I'm still having quite a lot to understand about Drupal 7. The areas I'm currently struggling with are:
Cookies; a non-email-based user type; the menu system; and - may be quite simple, but I still don't understand the full details - what steps Drupal takes to fetch a node and how I can intercept and modify each these steps.
So and now the powers that are change the code structure of Drupal. That's really scary. Sometimes I yearn for less elegant code and much more remarks in the source files. But things will head in a different direction: still more abstraction layers and overhead and less simplicity and also less remarks in between.
Guess, how I found this blog: I entered the keys "Drupal 7 competitors alternatives" into Google. I'm so scared that I'm looking for an open source CMS that is as flexible as Drupal, with a friendly community (the community is a one of the big plusses of Drupal) and that is well documented. And here I am and sacred as hell.

I would love it if you would be willing to take a look at Backdrop, let us know what you like and dislike, and help us create a product that's better for you and people like you. Welcome, Georg :)

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.

Thanks for the support. We do have an IRC channel, you can join us in #backdrop.

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.

This is a great idea, and something that has already been happening in the Drupal landscape (remember coder module?) We should aim for the same type of thing for Backdrop.

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

Thanks for spotting that. I have edited the article to say that I think we should focus on the current community. I know the Drupal 8 dev team loves this community too, and I don't want that to be taken the wrong way.

It's not that I believe that current Drupal developers *can't* learn these approaches. I believe they *won't*. I also believe the are not necessary - so it's hard to fault them for not wanting to learn.

Also, to reiterate what I said in my original post: The problem is not a lack of training and documentation, the problem is that the system itself needs to make more sense.

You're right: Eventually I will master even Drupal 8. But when? I build websites to earn some money. I invent hardware and optics and do a lot of things to make ends meet and every week or month I struggle with beautiful coding abstractions leaves dents in my bank account. I simply can't afford a new "learning cliff" which Drupal 8 seems to pose. It even seems to be not a cliff but something like a jump into the orbit. If you are working in a team and you have the opportunity to learn from each other, it could be even fun to learn Drupal 8. If you struggle to keep yourself off the dole it is a different situation. I will definitely left behind for I simply can't afford to spend months to learn a new concept.

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.

Hi Alex, thanks for taking the time to write this detailed comment. I really appreciate you weighing in on the conversation here.

I agree with everything you said about Drupal becoming more and more complex, and I agree that is a very hard problem to solve while keeping the code complexity to a minimum.

You are also correct that the only way to become a Drupal expert is to put in the time. Right now, we have a community full of people who have already invested lots of their time to become experts in Drupal 7. These people are facing the prospect of needing to invest a lot more of their time to keep up with the next version of Drupal. We know how much people complained about the changes from Drupal 6 to Drupal 7, and instead of listening to their concerns and trying to ease that pain for them, we're asking them to hunker down and do it again - but this time on a scale that's never been seen before in Drupal development.

Here's an interview with Dries Buytaert from Computerworld. See specifically the section titled "Re-architecting for world domination" on on page 3 where he talkes about the two types of Drupal developers.

Drupal 8 is, unfortunately, targeting a different kind of developer. We were also surprised to learn that there was a specific decision made to target this group in the Drupal 8 development cycle, but have confirmed that is the case by talking to several core committers. Admittedly, we had no idea what that decision would mean for my "hacker" developer type when it was initially made, but it's one that certainly won't be un-made now.

I also want to stress that I'm not saying that what Drupal 8 is doing is wrong, or even that it's not better than what Drupal 7 was doing. My point is only that there are costs associated with making changes this big.

I also don't personally feel these changes were necessary. Drupal 7 was very successful by most standards, and even more so is WordPress. Neither of these systems needed OOP, standardized patterns, or components to get there.

This is purely a difference of opinion - and unfortunately one that can't be solved in the Drupal.org issue queue. :(

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.

Hi Ben, thanks for your comment. I'm sorry you feel the way you do, but I can understand your viewpoint.

The reason I think idea sharing between Drupal and Backdrop might be more beneficial than idea sharing between Drupal and say, WordPress, is because our concepts are more similar, and we did, afterall, start from the same place. Here's an example of how we are still working together:

In Backdrop land, we started copying Drupal 8's usage of .yml files instead of .info files for modules, but we discovered that that approach had implications on the amount of memory used (see our issue for more details). Shortly afterwards, in Drupal land, a similar issue was opened (see the Drupal issue fore more details) because of Backdrop's findings.

We may have to disagree on the meaning of the term "community". I see a lot of the same people in the issue queues for both projects, so - to me - we are still one community. Only time will tell whether things stay that 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?

Things like CMI can't exist as Drupal 7 contrib modules because the require fundamental changes in how Drupal works. (Plus, we have one of those already, it's the features module).

We did consider at length a "don't upgrade" movement to keep sites on Drupal 7, but that wasn't going to meet all of our goals. We can't get new features into core in Drupal 7, and we wouldn't be able to improve many of the pain-points people experience with Drupal 7 today. More generally speaking, we wouldn't be moving forward.

We want to be able to still move forward, but in a different direction than Drupal 8. Basically, the exact definition of a fork.

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.

Great points. We did consider maintaining Drupal 7 compatibility, but the killer feature in Drupal 8 is CMI and I'm not sure releasing any Drupal competitor without a solution comparable to CMI would have guaranteed success. We've settled with keeping the focus on easy ports, rather than compatibility - but we'll see how that turns out!

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?

It's true that complicated problems often have complicated solutions. However, there is often more than one solution to any given problem. It's important to weigh the costs and the benefits of each solution, and measure each proposal against the priorities of the project.

Drupal 8 is shooting for an elegant OO architecture - and many of the reasons things are as complex as they are in Drupal 8 is because the solution they choose aligned with that goal.

If Backdrop's goals are to change as little as possible from how things worked in Drupal 7, we'll almost certainly arrive at different solutions for the same problems - undoubtedly simpler ones.

When the goals of different groups don't align, it's hard to agree on solutions.

If my goals are different than those of the majority of core developers, it's pointless to keep trying to get them to choose my solutions. Perhaps it's time I worked on a project that had my goals in mind... Hence, the fork.

"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'm sure a lot of people agree with you. Drupal 8 has brand, and a lot of great people working on it, and I'm sure it will be successful. We'd love to get something like coder module that could help you port your modules to backdrop, but even without it we're hoping we can still create incentives for maintainers to port their modules to backdrop. Making it easier to port to backdrop is one. Releasing a stable 1.0.0 version of Backdrop before Drupal 8 is out is another. Adding new features often is a third. Over time people will have more and more reasons to choose one over the other.

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!

Please keep in mind that Drupal 8 is not done yet so doing comparisons of the alpha version may not be a fair assessment of Drupal 8 performance yet. That said, yes, one of our primary objectives with Backdrop is on keeping things fast.

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.

We have been talking to some of the people who have exit strategies. We are trying to address their concerns, but of course we can't talk to everyone because we don't know who they all are. It would be really helpful if you could reach out to the people you know and send them our way. We'd love to hear their stories too.

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!

Thanks for your comment Mark. It sounds like Drupal 8 is exactly the tool you've been waiting for :) You are not alone, and many people will agree with all the things you just stated. There are some of us, however, who disagree. For us, there is now Backdrop. These two differing opinions are what is driving the creation of two different projects, each with it's own goals in mind.

I would like to address the issue about not having very many core committers. Drupal doesn't have enough core committers. Currently: there are 6: Dries, Gabor, Angie, David, Catch, and Alex. You don't see how a fork wouldn't hurt that, I don't see how it would -- unless one of those 6 people quits Drupal and starts working on Backdrop, agrees to our principals, and becomes a committer here instead.

It's up to Drupal to decide to add more committers. The way I think Backdrop may be able to help that situation is by demonstrating how things could be managed with an army of our own.

D8 is professional, enterprise level code - too true. Its the result of the entire evolutionary cycle of previous releases, great leadership and really sharp contributors. If that is the kind of work that you want to do (and is what I currently do), then D8 is exciting. I'm looking forward to working with it.

I've been hoping for some type of Drupal LTS-type version, though... and D7 is a perfect candidate. I see Backdrop as being an LTS branch - its built on D7, improves it, and maintains it. Drupal 7 is a fantastic system, and a great encapsulation of what Drupal is. Its very cool to see this fork and follow this branch as well. Drupal itself can't continue developing D7 in this way, but Backdrop can.

I look forward to working with both. D8 will probably be for larger sites with larger teams. Perhaps not always, but again, we want the right tool for the job. If Backdrop has the chance and the support to achieve its goals, then it will be an amazing complementary system.

Either way, we all win. We get a simpler system that can compete with WP, and we get a powerful, professional system that can compete with anything.

Thanks Ron, that's how I'd like to think about it too. Long Term Support (LTS) for Drupal 7 is not very realistic because we wouldn't be able to add new features. And we like new features. Backdrop is basically that, long term support, plus new features, and also the ability to change APIs - if necessary.

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

Thanks for your comment Tony. I agree with you that from the site-builder experience Drupal 8 won't look much different than Drupal 7, and in a lot of ways things will get a lot better for you. :)

However, as a non-developer you will also be dependant on a lot of the contrib module developers: In order for you to build a site using, workflow module, for example, you'll need that workflow module to be updated to Drupal 8. The more changes there are between Drupal 7 and Drupal 8, the longer it takes the contrib developer community to get their modules updated.

My concern is mostly for these people (admittedly, I am one of them). But I also know that there are a lot of site builders who depend on the contrib developers, and site users who depend on them both. If we get a bottleneck at the contrib level, everything slows down.

"If we get a bottleneck at the contrib level, everything slows down."

backdrop by it's very definition is going to create a 'bottleneck at the contrib level' by requiring all modules to be ported twice, or only ported to one or the other system. by definition this is only going to hurt drupal. how do you reconcile this w your supposed desire to have backdrop & drupal peacefully co-exist?

There are still plenty of D6 modules that haven't been ported to Drupal 7. Part of my job as a Drupal developer is to port modules, as needed, to the version of Drupal my clients are using. Right now, I don't yet have the skills necessary to port modules from Drupal 7 to Drupal 8 (and I've been using Drupal 8 longer than more than 99% of the Drupal community). There will be a bottleneck whether Backdrop exists or not.

We don't yet know the end-point for Backdrop, though we have some good ideas about where we'd like it to go: not very far from D7. Here is the possible range of outcomes:

Best case scenario: the changes necessary to run a Drupal 7 module on Backdrop would be simple enough that they can be worked into an existing Drupal 7 module with if statements in the current D7 code.
Worse case scenario: the scope changes between Drupal 7 and Backdrop will be comparable to the scope changes between Drupal 6 and Drupal 7.

I disagree with your opinion that any of these possible outcomes is "only going to hurt" Drupal. If the only way forward is through a bottleneck, that also hurts the whole Drupal ecosystem for a while: end users don't get their features, site builders don't get their building blocks, contrib developers become even more overworked, and web shops pour in countless hours to get up the new learning curve.

There's a portion of projects we work on that don't require Drupal 8. If that part of our ecosystem can continue to grow and bring in new business to fund the work we do on Drupal 8, that will benefit the projects that will require (or prefer) Drupal 8 over Backdrop.

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.

Thanks Howard. We are currently focused on improving: The authoring experience, Configuration management, Performance, Upgradability (backdrop->backdrop) and Documentation. Those things should be fairly easy to manage since the code will be squarely in our realm.

Contributed modules and themes will be harder to manage since the code will be provided and maintained by others. We do have some ideas on how to distinguish official supported projects from the equivalent of 'sandbox' projects, and ways to demote projects from the former to the later due to inactivity or other factors. We have not yet tackled ways to automate QA on contrib, and we may choose to use to some form of user-based rating system instead.

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.

Thanks for your support. To address your questions:

1. Yes, we are already focused on performance, have found some slow parts in Drupal 7 and are working on solutions. We plan to push this further.

2. Originally we decided not to remain API compatible with Drupal 7, since committing to the same APIs in D7 means committing to a system that is already too confusing, and possibly already too slow. However, we are hearing from the community that this compatibility is really important to a lot of people, so we may re-think that decision.

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.

D7 certainly isn't going anywhere. But it's also not changing: what Drupal 7 is today, it will be forever. If you want new features (CMI, for example) you need to move forward. Backdrop offers a new way forward.

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.

I'm also not sure that the world needs yet another CMS product. However, my feelings about the world needing a more Drupal-7-like alternative than what Drupal 8 is rapidly becoming, are getting more and more solidified with time.

Hopefully we can achieve the goal of making/keeping a Hello World module relatively simple and intuitive to create - as well as decrease the current processing footprint Drupal 7 leaves behind.

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?

The reason we aren't using Twig in Backdrop 1.0 (but I'll still fight the good fight to get it into 2.0) is because we've seen what happens when we're allowed to change too much in one release cycle (se: Drupal 8). We'll be changing "enough" in Backdrop by adding CMI, Views, WYSIWYG, responsiveness, design improvements, general theme system cleanup, and all the bugfixes from D7 and D8. In order for upgrades to be easy, we have to draw the line somewhere.

What's "broke" is the run-away train of changes. That's what we're aiming to fix by not including Twig.... yet!

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.

It's not "database abstraction" that I'm against, it's the Drupal-specific system known as DBTNG. We can have all the abstraction we need using PHP's PDO. We don't need DBTNG for abstraction (though that is a common misconception).

Unfortunately for me, we are going to be keeping DBTNG in Backdrop. Removing it would require too much change for existing Drupal 7 modules. We will probably be moving it someplace else, and we'll stop using it in Backdrop core, but it's not going away entirely.

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.

Of course Drupal 8 will have improved features over Drupal 7. We've been working on it for long enough! However, Backdrop will have most of the things you mention in your post too (Twig excluded). Backdrop already has CMI, it will have a responsive Bartik theme, it will have CKeditor in core.

If you had to choose between a version of Drupal 7 that had all the features you love about Drupal 8, without the increased complexity, and new systems for you to learn, would you still choose Drupal 8 for SMB? How about when it comes to upgrading an existing Drupal 7 site?

I think I still would, for new SMB sites. It's early days yet, but I suspect I am going to love all the new OO and plugin code, not least because it potentially allows very clean inheritance and overriding of more core functionality. That's something I have often found difficult and unsatisfactory in D6 and D7.

For upgrading Drupal 7 sites, well, given the LTS proposals, that probably isn't going to happen until at least 2015 for any of my client sites, and by then I want to have enough D8 experience to handle it, if that turns out to be the best solution.

So I'm keeping an open mind, and will certainly look at Backdrop if/when it gains momentum, but right now my feeling is that I should be learning D8 anyway - otherwise how can I make any kind of informed recommendation to my clients?

I think that's a healthy point of view. I'm also keeping an eye on Drupal 8 and I'm sure I'll be using it for some projects too. The reason I'm so passionate about Backdrop is because the existing community needs to have options.

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? :)

Hi Ted, Backdrop CMS is working on a website (launch date scheduled for early April). I don't think the project has "already fizzled". There has been a lot of initial excitement about the project, followed by a lot of time and energy spent in issue queues, working on the code. We even have google hangouts (they are public, you can join us any Thursday at 1pm PT). I think until people have something to actually see and touch, it's hard to be compelling alternative.

We're about a year ahead of the curve in terms of when the large community might start shopping around. We'll start on some PR here shortly, and see what everyone thinks!

Add new comment