There's a little controversy in the Drupal world, a fork by Nathan Haug, aka QuickSketch. Last week he tweeted:
#Backdrop needs to exist to preserve the #Drupal community and market. Why it exists and where it’s going at http://backdropcms.org/ — Nathan Haug ( @quicksketch )
I was dragged kicking and screaming into Drupal by my employees -- I thought the architecture sucked, the templating system was stupid compared to Smarty, TemplateToolkit or DTL, it was a bloated memory and performance hog, configuration management was a disaster, simple REST/web services are ridiculously missing, and the lack of any sort of object oriented structure was a real impediment to understanding the code. Yet Drupal got the job done, handled everything we threw at it, quicker than anything else, and I became a convert. Our shop has done all Drupal for the last 5 years.
Drupal 8 pretty much resolves all of these complaints. I'm really excited to see it come about. As long as the community stays behind Drupal 8, I think we'll see a platform poised for even greater success.
As I see it, Backdrop is about preserving the bad parts of Drupal for people who don't want to learn actual programming skills. Users and administrators are never going to notice the difference. Sounds like they're bringing Twig over, so themers won't know the difference either. They're preserving the archaic architecture that makes Drupal so hard to learn for developers, the deployment nightmares for dev-ops, and the resource-intensive loader to keep bogging down performance for everyone. Great plan. Good luck with that!
9/27 Update:
Looks like this post got picked up and discussed with Nate and Jen on the Drupalize.Me Podcast. They had a very diplomatic response (I started with Drupal 5, by the way!), pointed out that I have some of the basic assessments wrong about what's going into Backdrop, that a big focus of their work is on performance where they are already seeing some gains, and that I will probably be happier in Drupal 8, which is fine.
I think Daniel Kudwein (aka Sun) has the best take on this controversy, basically pointing out that it's a communication breakdown.
I also hear lots of people saying "Forks are a good thing", trying to celebrate this and get all kum-bah-yah about the matter, let's all stay friends. Wrong. The ability to fork is a good thing. An actual fork might be a necessary thing, but it's rarely a good thing. Often successful forks make the original project irrelevant, rarely they split off and both versions get established, but pretty much never do forks manage to continue collaborating and helping the other.
Backdrop is not going to be compatible with Drupal 8 -- it's clearly going a different direction. Sooner or later there will be so little in common between the projects there will be nothing to talk about. For us, by far the biggest problem with Drupal is upgrade pain -- the single biggest reason we're losing customers these days is sticker shock at what it takes to upgrade from D5 or D6 to D7. Both D8 and Backdrop are trying to address this problem, in fundamentally different ways. I think D8 is hitching its horse to a platform and architecture that largely solves this problem, while Backdrop is preserving the architecture that promises to lead to more upgrade pain down the road.
But the biggest reason Backdrop sucks is that it means Drupal is losing some very talented developers and long-term contributors.
For more on forks, you can read a post I wrote back in 2006...
Industry
Great writeup, it pretty much
Great writeup, it pretty much reflects my views as well. One caveat, I don't believe twig is being ported over, but they're thinking of writing something similar.
Whats worse is that it won't be compatible with Drupal at all, so they're pretty much making a new CMS based on bad industry practices. These were ingenious hacks when PHP 3 was out, but that was over 10 years ago. The idea of turning the clock back is bad.
The FUD that backdrop spreads is toxic to the greater Drupal community and helps re-enforce why external people don't like drupal in the first place. My hope is that instead of people flocking to backdrop, they will learn new programming constructs and become better programmers.
The truth is there have been
The truth is there have been at least a dozen or more Drupal 'forks' promising all sorts of things but ultimately failing - sans Pressflow, who's performance changes were adopted to a point in Drupal 7.
This is being marketed as a 'new CMS' when it's quite obvious it is Drupal 7 with a different name - in which case, why not just work on D7 core? Otherwise, fragmenting the community and changing the moniker is going to throw confusion into the mix. How can they hope to gain traction with a handful of devs constantly backporting changes for compatibility (from a module standpoint) while improving it to be 'on par with D8' which could never be true at all?
Ultimately, the echoed sentiment is that yes, this is a push-back from a group of people who do not want to use OOP and design patterns to build solutions. Most people who hung with Drupal from 1-6 largely were hobby coder / hackers, and the shift into OOP and structured coding has had somewhat of a Darwin effect on the developer base, survival of the fittest.
In any case, getting a solid base down with Drupal 8 is going to give it the longevity Drupal needs without carrying it from point to point with procedural kludge.
Ultimately, the echoed
That's incorrect. Backdrop developers have made clear that they are very much not anti-OOP, and in fact Backdrop will likely have more object-oriented code that Drupal 7 (which already uses object-oriented code and principles itself in a number of key subsystems, by the way).
For example, quoting quicksketch in https://github.com/backdrop/backdrop-issues/issues/44 :
"One thing I don't want to introduce is a fear or aversion to OO code. OO makes a lot of sense in many situations, and I think it's inevitable that we'll use a lot of it in Backdrop 1.0 (i.e. the plugins architecture and Views implementation). We're not anti-OO, we're anti-complexity."
Thanks for pointing out that
Thanks for pointing out that discussion. It makes me sad about the fork -- these are great goals, but I still think forking was misguided.
The core work of moving to a real OO framework is a very big win that I think far better achieves these goals, compared to the old Drupal core.
I think there's a lot of merit in the "small core" principle that does seem to have been largely abandoned. Simply yanking out modules that aren't in use on all sites to me seems like enough -- I see they've dropped Forum, Poll, RDF, and several others -- we all would be better off if they made a "small core" branch of Drupal 8 with just the essentials, rather than forking into something entirely new and incompatible -- it's probably far better for those modules to go back to contrib anyway.
Drupal 8 pretty much resolves
I 've actually expanded on this argument today over at http://pingv.com/blog/drupal-8-as-an-intuitive-platform. In short, Drupal 8 is going to be a far more intuitive and approachable platform than Drupal 7 ever was. Drupal 7 is just a muddy mess of procedural spaghetti code...
Totally agree with you.
Totally agree with you. Forking Drupal is a bad idea and come on backdroppers, embracing Symfony components is the smartest move.
Nevertheless, it is not a matter of whether backdrop will stop to exist but just when it will vanish.
cui bono?
"Most people who hung with Drupal from 1-6 largely were hobby coder / hackers, and the shift into OOP and structured coding has had somewhat of a Darwin effect on the developer base, survival of the fittest."
Clearly the changes are good for the developers and owners of the tiny by important minority of Drupal sites where there is enough funding for professional developers. The majority of Drupal sites out there were made by hobbyists (or professionals in the way small WP 'web designers' are professional) who picked Drupal over Wordpress, and who find maintenance a headache (see the d.o. support forums to confirm this). This mass of users. who are the key to Drupal's wide adoption, but who will never make Drupal shops rich, are still being recruited by Drupal Gardens. I fear when their D8 sites 'blow up' they will be even further out of the depth than they were with D6. I hope I am wrong.
Drupal has already followed the money and taken the enterprise route. In a way the Backdrop fork is too late. The one thing that remains is to more frank in presenting Drupal as an OS enterprise solution which great at what it does, but is not a good choice for small site builders.
The majority of Drupal sites
> The majority of Drupal sites out there were made by hobbyists (or professionals in the way small WP 'web designers' are professional) who picked Drupal over Wordpress, and who find maintenance a headache ... I fear when their D8 sites 'blow up' they will be even further out of the depth than they were with D6.
>
> ... The one thing that remains is to more frank in presenting Drupal as an OS enterprise solution which great at what it does, but is not a good choice for small site builders.
I would argue the complete opposite. Drupal has been quite complex for a very long time, leading to a huge number of craptastic sites that don't work well, give Drupal a bad reputation, make site owners flee to other platforms. And this is largely because even really good programmers unfamiliar with Drupal re-implement things Drupal already does but they don't know about it, or these "hobbyists" can't come close to getting right.
A huge amount of our work is rescuing projects that other developers were unable to complete, had screwed up so badly they walked away.
Like any other major release, it's going to take quite a while for the contrib ecosystem to catch up, and it is so drastically different this time that site builders are going to need to learn a lot of new tricks. But when I see stories like this one, advocating putting SQL in the theme, it makes me shudder -- that's the crappy stuff we see all over inherited sites, and I think Twig can do a lot to discourage that.
You are right, this fork is too late -- the vast majority of the amateurs have already fled to WordPress. That's a good thing -- let Word Press own the low end of the market, because then they get the crap reputation. Drupal is already a much better solution, and with Drupal 8, it's going to be far more approachable to new developers than it ever has been before.
The Majority of Drupal Sites
I'm continuing to be puzzled by the idea that small, non-enterprise sites and those who create them will not be well served by Drupal 8 because the "hobbyists" and individual professionals (as opposed to shops serving enterprise) won't be able to hack code as easily as in previous versions.
Small sites and individual web professionals don't need custom code to build complex, dynamic websites using Drupal 7. From what I hear, Drupal 8 will make it even easier to build such sites without coding.
So I would ask such hobbyists and individual professionals worried about Drupal 8: what is the service you provide your clients? Is the ultimate goal to create a great website or is it to write code?
Consider also: how likely is it for a Drupal 8 (or 7) site without any custom code to "blow up" in the way you fear? (I've done three site rescues in my career: none of them would have been necessary if the developer had refrained from custom coding and used core/contrib modules instead. In all cases, the solution was to rip out the custom code and properly implement standard modules.)
Not accurate
Sorry, but you're flat-out wrong here. Have you EVER worked on a Drupal site, no matter how big or small, where you NEVER had to write ANY custom code? Never modified a theme's template.php file?
I have worked on many Drupal sites and frankly, this kind of use case simply doesn't exist.
And there's no excuse for poor coding, but what happens when these low-level programmers that you're leaving in the dust need help? Where do they go? The forums? IRC? Hire another experienced Drupaler?
yes
I largely agree with this. I also make a living mainly from looking after Drupal sites which have pretty much gone wrong, albeit as freelance support. It is partly the clients' fault for picking the cheap / offshoring / confident-sounding Drupal 'experts' over the well-known but prohibitively expensive Drupal shops.
So with Drupal 8 it could go two ways: the client base pf the type who lack the funding to make and maintain a Drupal site well will flee to a more suitable platform (in which case the 'professionalisation' of D8 will do them a favour). Or the changes to D8 will mean they get burned even more badly by the developers who know Drupal less well than they pretend or believe, and who get business but bid unrealistically low.
But I feel sorry for the owners of 'craptastic' sites (this week a client told me his Drupal site was like a bad marriage), and if Drupal core does not help out the people who have invested and feel locked in to a bad Drupal site, and who could not afford a Wordpress migration (for example), maybe Backdrop will.
So with Drupal 8 it could go
Hmm. Again, I disagree... There's always going to be the low end of the "developer" pool, and lots of ways to get a terrible site built. I think one of the challenges Drupal has always had was how different it was than most of the professional software world. Which means even really good developers who are unfamiliar with Drupal are likely to have very bad results their first few times around.
With Drupal 8, I think we're going to see a lot more competition at the high end, it will make for an easier entry into the Drupal world for other quality shops and developers. So I'm a little concerned about D8 introducing more competition, which could eventually start driving prices down for end customers, and perhaps start eating into my rates. That's very good for Drupal adoption.
Backdrop, to me, seems like will only be a good solution for current Drupal developers who are resistant to change. And yet it still involves some pretty major change, so again I don't see this as viable. If they're sticking with the old patterns, they're keeping their huge technical barriers to entry for new developers. I really think D8 is going to be a lot easier to pick up for people not already indoctrinated in Drupalisms.
Now there's a different issue: migration (and upgrades). And while Backdrop has a very laudable stated goal of making the site much more forward-compatible, much less painful major upgrades, it's questionable how well they can pull that goal off -- one of the technical reasons for moving Drupal to the Symfony framework was to provide more stable, less intrusive upgrades going forward. So in other words, I think D8 has a much better chance of fulfilling Backdrop's goals than Backdrop does.
Fully qualified developers are using Drupal?
I've always felt that I would move on from Drupal once I was ready... Thought Drupal was for and suited to that crowd. Very curious as to why people that fully know what they are doing are hoping to change that (what has made Drupal as successful as it is (?)) and not just use something else?
Question: do your employees that "dragged kicking and screaming into Drupal" share your enthusiasm for the changes in D8? Are they excited about Backdrop?
Cheeky-ness aside, I've heard frowing talks of 'exit straties' since D7... I fully agree that Backdrop is too late. Before I knew what it was, I was hoping it might be to D7 or D8 what Pressflow was to D6 :(
I don't know of any of my
I don't know of any of my developers who are excited about Backdrop. The one who made the biggest impact converting us to Drupal now works for Acquia, and she started dabbling in Symfony while she worked here (hi, @ksenzee !) I've had several developers on board since who have complained heavily about how backwards Drupal is in certain areas, and how much easier it would be if it just had an object-oriented framework.
It's not Drupal's crappy core architecture that has made it successful -- it's a can-do spirit among its developers, a willingness to dive in and figure things out.
And it's not like OO doesn't exist in Drupal -- Views has been OO for a very long time, and there are lots of Drupal developers extending Views quite successfully.
Agreed, those with a can-do
Agreed, those with a can-do attitude will get up and running and figure it out, Drupal 6, 7, or 8. I suppose the whole 'exit strategy' talk is a separate topic.
Thanks for the reply, I appreciate the insight.
Core contribs know the value of progress but not its cost
I disagree with this, for the simple reason that these are guys who know Drupal well enough to realize that NEW Drupal 7 and probably Drupal 6 sites are being created and it will be impractical to upgrade them to Drupal 8 when it comes out.
I see many developers having to decide whether it will be a good idea to create new Drupal 6 or 7 sites or abandon Drupal altogether. The fact is Drupal 8 is going to cause the problems Drupal 7 created for Drupal 6, which is basically mess up development of third party modules, and waste all the time invested in mastering Drupal 6 and 7. Once bitten twice shy.
As experienced Drupal 7 developers get to know BackdropCMS better they will decide whether to stick with their Drupal 7 investments and skills or abandon Drupal 7 altogether. Something like this may determine whether the Drupal community stays together or breaks up and Drupal is more of a community than a product.
My Drupal skills are not that great but It already makes me feel better about creating new Drupal 7 sites.
Take a look at the Services module https://drupal.org/project/services. It has been discontinued for Drupal 6 and what is worse is that the links required for anyone who wants to see what they can do to fix it were simply removed from the main page. I had to Google a lot to see what was going on and what I could do if I wanted to continue it using. Although some patches were tendered the test suite required to verify it for Drupal 6 was not good enough and no one had the time to take it up as most efforts are going into Drupal 8. Given how REST is so important you need to ask how much one can rely on a team who can discontinue such a critical module. Issues like these don't inspire confidence.
Have you noticed that it is now that Drupal.org is switching to Drupal 7, 3 years after its release ? https://drupal.org/node/2085755.
It is irrelevant how good Drupal 8 is or might turn out to be.
Frankly if anyone is at fault here it is Drupal core contributors - that means Dries and Co - neglecting the concerns of those who need to preserve their D6 and D7 investments. I feel that people would be happier to learn Drupal 8 and contribute to it if they were convinced that their D6 and D7 investments wouldn't go to waste. They already did this once and got burned. They can't be expected to do it again.
Are you human is too complicated?
PS. The are you human thingy requires too much 3rd party Javascript in these days of NoScript
@Frank thanks for persisting
@Frank thanks for persisting through the are you a human thingy! It is the most effective thing I've found for stopping spam, though -- with Mollom we were getting batches of 50 - 100 spams through every day, while at the peak it was blocking ~7000 spams per day!?! AYAH has it down to maybe 3 or 4 a day.
Very good points about the cost of upgrades, and Services module. I totally agree that Services is necessary for a lot of integration work, mobile app support, and more -- it's a shame nobody is stepping up to maintain it in D6 (but understandable). That is going into core in D8, though, so that's another point in D8's favor.
The cost of upgrades is a major, major problem with Drupal these days, and D7 -> D8 is looking to be as big or bigger a jump as D6 -> D7. I'm actually drafting up a post about the cost of ownership compared to value in Drupal, as compared to other platforms. This has long been perhaps the biggest tangible cost to running a Drupal site -- the cost of upgrades. I keep hoping it's going to get better, but if anything it's getting worse, at least up to D8.
Once Drupal is a Symfony app, will future upgrades be less painful? Time will tell. But I'm guessing that with much better object-orientation, future upgrades can be a lot easier -- if well implemented, modules can simply inherit the updated base objects with potentially no changes whatsoever.
So I guess I take your points as the reason why Backdrop is a bad idea -- the very issues you raise with Drupal are what I hope Drupal 8 will largely resolve -- and Backdrop is likely to perpetuate.
Warning programmers about danger of Drupal
As a programmer I have university degree. And I want to warn another programmers about drupal.
I have been working with Drupal for 4 last years.
Working as site builder and programmer.
And I want to warn new programmers about what is not said.
Drupal is not for programmer's use.
It is for web masters' use.
You can think like this: "I will learn how to create the modules and I will be creating good web sites for money".
But it is not like this.
The customers don't want your custom code in their web sites. :( .
They want site built only on base of drupal.org modules. It is an official ideology. They call it "the drupal way".
And this could be done only by advanced tuning of hundreds of modules.
To understand how to do this you would need years and years. And this is nott even about programming. You will not be programming doing your drupal work.
And so you will be turning to a weaker programmer.
And when you would learn your knowledge then a new version appears and you would need to learn again.
Now Drupal 8 is too complicated to waste your programming abilities on it.
It has no sence.
It is my experience.
I wasted my programming time and skills for the trap with name drupal.
Now I am leaving from Drupal.
Yeah, I've seen this attitude
Yeah, I've seen this attitude before.
The thing about Drupal is that it's a huge existing code base. Programmers tend to prefer green-field development, being able to write code from the ground up -- it's a lot more fun. Working with other people's code puts you at the mercy of their development patterns, their bugs, their foibles. And because there is so much existing code for Drupal, it's extremely rare you get to actually write something new.
But Drupal is not the only place that happens -- it's rare for programmers working at a job to get to write anything brand new -- that's a benefit you'll mainly get at startups.
Yes, there is very much a "Drupal way" of building things so you go with the flow, and it has been counter to much of the more formal computer science world. But it's hard to argue with results. Drupal, in spite of its quirks, has been getting the job done for years. And it is getting much better with each version.
The problem with developing in Drupal without using "the Drupal way" is maintenance. We pick up a lot of customers who had previously worked with other developers, and we've seen a wide range of hacked-together solutions that make it really difficult for clients to manage their own content, or make changes down the road. What's great about "the Drupal way" is that you can keep changing your site as your business evolves, adding fields, tweaking views, changing rules, and more, without needing to bring in programming talent.
The whole point of using Drupal is to get results quickly, not to make you a better programmer.
About this topic.
About this topic.
I had a fun.
Do you think Drupal 8 become a good OOP system?
What a laugh.
It's the same procedural a lor, with the same procedupal hooks, which uses some oop code.
It was the same with drupal 7.
And to the site builders drupal 8 gives nothing. The admin functionality are completely the same.
But Drupal 8 is much much much SLOWER then drupal 7.
It would be a real pain to find a virtual hosting for Drupal 8 site.
Or maybe customers now want to hire linux administrators on a permanent paid servise for vps, vds yetc?
No?
They will have to :) . If they want their drupal 8 elephant site to work.
Have you even looked at
Have you even looked at Drupal 8?
Hooks are gone. If you want to provide a new kind of block, you have to use a special annotation to register your code so it will get loaded -- this annotation system has replace hooks (and does bring a new level of weird to the table). And then you extend the appropriate class. It has gone much more object oriented, a far different coding experience from Drupal 7.
And the admin experience gets a nice upgrade with in-place editing, aka Spark.
It's way too early to compare speed -- it hasn't begun to be optimized. But there's one key area I expect to see a huge performance improvement -- with Ajax calls. With a much better routing system in place, I'm expecting a much smaller memory footprint for individual calls, which should translate into a very nice improvement for rich internet applications, letting us break out of having to provide everything on a single page and build far more interesting apps that progressively load things. That's an area that Drupal never handled well, but will now handle as well as any other PHP app...
What about into 2019
It's been six years now since this article was published and I'm only just catching up with Backdrop vs D7 vs D8 and stumbled upon it. It's clear that D8s focus as of today is large medium enterprise sites which is great but unfortunately most developers will start off doing small-medium business'. What are they suppose to use if D8 is overkill ? A pumped-up version of D7 perhaps?
I'm new to Backdrop having it recommended to me at a Drupal conference recently. Essentially I wanted to do everything I can do in D7 for small/medium business, but with a better backend experience which for me it delivers if not via multiple module ports. I've only done one of these but I'm happy to say it was easy enough in a couple of hours it was done.
Really my main concern is around a smaller community that doesn't seem to of grown significantly and fragmented security synchronization between CMS systems (D7/Backdrop) it's a concern for me running a small agency meaning re-porting or patching modules and extra time for contrib.
And now there's the headless bunch now relying on less CMS frontend architecture and opting in for other faster solutions like React. Layer upon layer of additional complexities and technologies for developers making things more and more complex and perhaps like D8 overkill for small/medium business or maybe an opportunity for those top end quality developers to stand out. I'm certainly not me :( I'm drowning in knowledge.
@John from your blog it seems like you've stuck with D8 and ventured into the headless world. I take it Backdrop is still in your rear view mirror and perhaps you use D8 for everything from small to large buids regardless?
Hi, Jason, Wow, hard to…
Hi, Jason,
Wow, hard to believe it's been 6 years already. Yes, we have firmly gone down the Drupal 8 path, and not Backdrop... Lots of reasons, including a couple you list.
In particular, while there were certainly a lot of people who had become accustomed to the various idiosyncrasies of Drupal, overall Drupal has been its own special snowflake of a system, before Drupal 8. If you're someone who knows Drupal better than any other system, changing to Drupal 8 might seem confusing and difficult -- but for everyone else, it's a far more comfortable, familiar pattern. Drupal 8 under the hood makes extensive, explicit use of object orientation and a lot more standard design patterns than any previous version of Drupal, making it far easier for somebody with a more conventional coding background or education to use. Does that make it more "enterprise" focused? Perhaps if you have a liberal arts background and have gotten into code by hacking on Drupal first...
I'm not trying to knock on anybody's experience here, by the way -- I have a liberal arts background myself! But I came to programming after spending years writing programmer documentation as a technical writer, and was always somewhat appalled at what I saw under the hood of Drupal, even as I became proficient at making it do what I needed it to do.
In short, I think Drupal 8 is by far the best Drupal ever -- and it's a shame that so many people who loved Drupal 7 have been so alienated by it -- and that the community, and momentum, seems to have shrunk pretty dramatically.
But that shrinking community might be due more to both the rise of WordPress, and the rise of front-end toolkits like React, Angular, and Vue -- not to mention static website generators.
To make things more interesting, I think we may well see Drupal 8 (and 9 on the horizon) have a long-overdue resurgence, for a couple reasons which I'll be blogging more about when I have a chance:
- WordPress with its Gutenberg editor going into core is becoming much more of a layout editor at the expense of being a good CMS
- Front-end toolkits still need a back end to store their content, and with its great support for webservices -- not just JSON and HAL but also GraphQL -- Drupal might just be the perfect match for having a powerful CMS that can serve up content to a rich front-end app.
That's our thinking, anyway -- why go to a SaaS back end to store your content, when you can easily deploy Drupal 8, add the content types, fields, and relationships you need, and then build your front end as desired, no back end coding needed?
No way I see ever deploying Backdrop, or Drupal 7 for that matter, again. Backdrop preserves all the worst elements of Drupal, in my opinion, and Drupal 7 now has a known end-of-life date, just under 3 years off. We use Drupal 8 for nearly everything -- but we have started doing a few stand-alone static sites here and there with a Vue.js front end...
Cheers,
John
First of, I come in peace :)…
First of, I come in peace :) ...please do not be offended by the tone in the next couple of paragraphs in this responce; if you met me in person, you'd see that I am a very open-minded and friendly person. This is just my human reaction to some of the comments in this thread.
I don't like starting any comment online with a negative vibe, but I have to say this, to get it out of my system, before I get to the actual point I want to make: ...I am amused by mentions of the Drupal community in this thread, when the comments here are made with a sense of self-superiority, clearly disrespecting a great portion of that community, which has helped make Drupal what it is today. I urge you to please read https://www.drupal.org/about/values-and-principles (again, if you already have before), and this time make an effort to get past the "Strive for excellence" section, and try to give some attention to the "Treat each other with dignity and respect". It seems to me that you are either missing the point of what the Drupal community is, or we have very different definitions for it. I personally like to think that developers of all levels (even non-developers for that matter) should be welcomed - it is not survival of the "fittest" - it is not a competition - please leave your work/industry/enterprise out of it.
Also amused by the first comment in the thread: "Whats worse is that it won't be compatible with Drupal at all, so they're pretty much making a new CMS..." ...when I started reading it, I was not sure if the person was referring to Backdrop or Drupal 8. Sooo... look at the time it takes to convert a D7 module to Backdrop (oftentimes just a single line change in the .info file - if the module is not extremely complex), to the time it would take to completely rewrite the entire module to be compatible with D8. So take that into account, then re-read that comment, then be puzzled :P
Now that I got the bitterness out of the way (in the spirit of most of the comments in this thread), lets get to the point...
Making Drupal (8 and beyond) more "compelling" to "elite" developers was meant to "get us off the island", bring more (experienced) people to the community, and (long-term) help with the adoption rate of Drupal + also help complete the porting of modules faster, to bring them to a stable 8.x version. Right? ...weeeell, here we are, 4 years later. Look at the state of the 8.x versions of say the top 20, or top 50 contrib projects. Look at https://www.drupal.org/project/usage/drupal and tell me that it honestly does not bother you that you can clearly see that the adoption rate (which is also an indication of the community growth/health) seems to be in a constant downwards route. Can you spot by the diagram at which point in time it all started? Was it around the release of D8 perhaps? Feel free to use archive.org to compare that to the upwards route after the release of D7 (Jan 2011) and to the same amount of time. So D7 brought us from 500k sites worldwide, to 1+mil sites. What does D8 have to show for that amount of time? Anyway, I won't go further with this, it has been discussed elsewhere (https://www.metaltoad.com/blog/sluggish-drupal-8-adoption-lags-even-d6).
The fact is that there is market for both D8 and D7 (now Backdrop I guess); so there is no point in arguing over that. There are currently 800k D7 sites, and any web agency or freelancer dev that fails to see the potential customers in that number, will lose a chance to make $$$ ;) ...the point is do these customers have the budget to rebuild to D8 now-ish, or would they be better off with upgrading to Backdrop (which takes way less time, hence less cost)? Now, if the "elite" Drupal developers/agencies do not care about those that want to stick with an affordable solution, also great; it leaves that portion of the market for the rest of us "lesser" developers. Why would the "elite" portion of the Drupal community though prefer those 800k to flee to Wordpress, instead of sticking with Drupal7/Backdrop? ...perhaps in the long run, they will come up with the budget to move to D8/D9. If the customers remain happy with a Drupal7/Backdrop solution, it won't be hard to convince them to rebuild to D9 when the time comes. So, profit for all the way I see it.
Now, I am a long-time Drupal community member, I am also a long-time Backdrop CMS community member (and also happen to be a member of its Project Management Committee). I love Drupal, and I love Backdrop. I am currently employed by an agency that has a focus on government and the enterprise, and I see the merit of using D8/D9 there. I like D8, but would prefer Backdrop for small/medium-sized projects. ...I guess my point is that I have used D8 before, and I am continuing to use it. Has any of you guys ever actually tried Backdrop out? ...if not, perhaps you'd want to give it a go: https://backdropcms.org/demo/create ...takes only like 5sec to spin a demo instance, and you'd be set with most things out of the box. I'm sure you'll find it faster to complete new, small projects. And for those of you that are fans of composerized setups, and headless, but don't want the overhead of D8 (again, for smaller projects), perhaps you'd also want to check out https://github.com/backdrop-ops/backdrop-composer, or give https://github.com/backdrop-contrib/headless a go.
Peace out my Drupal brethren :)
Add new comment