A little over a month ago, a few Drupal developers announced something new: A fork of Drupal called Backdrop. There's been quite a bit of talk about it, of course. While I don't plan to be using it myself, Backdrop has raised a number of valid points and criticisms of Drupal that are worth discussing.
First of all, to be clear: The principles of Free Software and the GNU General Public License make it clear that forking a project is completely OK. Nate and Jen have done nothing wrong, legally or ethically, and no one should think ill of them for their choices. Drupal will not be ugly. I will be deleting any Backdrop-hostile comments on this post.
With that made clear, let's have a look at some of the criticisms that have led to the fork.
Drupal is leaving small sites behind
This is not a new criticism of Drupal. Drupal has been shifting further and further "up market" for years. The same criticism was leveled at Drupal 5. It was leveled at Drupal 6. It was a major challenge to Drupal 7.
It's also largely true, from a technical perspective.
Drupal's complexity, and with that its system requirements, have increased with every version in the 8 years I've been working with Drupal. I would actually argue that it was Drupal 7 that really broke the "casual shared host" user base. Anyone using Drupal 7 without an opcode cache is simply doing it wrong, because the code base is large enough that it won't scale well at all without one.
From a non-developer perspective, though, Drupal 8 is a huge leap forward. It may not look like it at first glance, but the integration of Views, Entity Reference, and a number of other such tools into core have produced what is arguably the most powerful content modeling tool in the Open Source world. The work done by the SCOTCH Initiative to upgrade blocks from a forgotten after-thought to a powerful "secondary content" modeling tool, using systems now consistent throughout core (plugins and fields, in particular), is a huge enabler for easier layout and site building capabilities. And let's not forget the Spark pseudo-initiative. While in-place editing is the flashiest thing they've accomplished, looking under the hood shows a lot of careful thought and work has gone into trying to bridge the gap between user flexibility and semantically chunked data.
That may not matter to developers who feel that Drupal has moved too far "up market". Certainly, Drupal is tackling bigger and more complex projects than ever before, and that necessitates more powerful (and often complex) tools. Most projects naturally follow that trajectory, since larger and larger sites tend to be more and more profitable and more and more interesting. Small sites become a "solved problem", and moving up market is the natural movement.
The problem is that the system that can handle big and complex Fortune 500 sites doesn't really scale down well to small brochureware sites, and the system that is optimized for simple sites can't handle the complex needs of an enterprise-level multi-faceted commerce site. "Well make modules" is only part of the answer, because figuring out what modules to use and how to configure them isn't always obvious to owners of smaller sites and introduces its own complexity.
The way to address that scaling issue is to divorce architecture from implementation. Create a layered design that allows complex bits to be removed entirely — not alter()ed or overridden, but entirely removed — when not needed. Instead of building a single monolithic system, build a system that is itself assembled from smaller, more loosely-coupled parts. I wrote about the need for an Additive System approach four years ago; a system composed of many small, loosely-coupled pieces better allows for scaling down just as much as scaling up.
Drupal 7's architecture, however, didn't really support that. Drupal 7 and earlier are architecturally monolithic. Stuff can be added via modules, but taking away core functionality or changing it radically is hard, often impossible, especially without breaking dozens of APIs. That has resulted in a gap in the lower-mid to lower end of the market that Drupal 7 doesn't fill very well.
Drupal 8, however, is a far more loosely coupled system. The massive refactoring effort that has gone into creating discrete systems that interact through clearly defined interfaces has brought us far closer to having an Additive System than any previous version.
The use of cleanly injected service objects, controlled by a Dependency Injection Container, make it easier than ever to selectively swap out an implementation for a high-performance MongoDB backend but also for a cheap-and-easy SQLite implementation with a super-simple schema, or even flat-file. It's far easier to configure something once in an install profile and disable the ability to change it in the UI entirely to simplify the interface. The more abstracted authentication and authorization system, breadcrumbs, and so forth make it possible to build not just more elaborate versions, but simpler, more focused ones, too.
I would love to see someone try to assemble a "Junior Drupal" that kept the Entity/Field system and Views, but threw out most of the administrative screens and unnecessary services and targeted just a simple node posting system with a trivially simple permission/administration system targeted at casual "blog++" users. Or one that ignores blocks entirely and uses pure-Twig for all theming and layout. Or one that does nothing but process and serve Atom feeds and has no other concept of content at all. The system is designed to support that sort of experimentation cleanly, and without actually forking code; it would simply require swapping out a whole lot of core services. Proper use of interfaces and dependency injection make that possible. Distributions could finally be more than just built-up CMSes.
Would that be successful? Would it be useful? I have no idea. But I do know that Drupal 8 comes far closer to supporting such experimentation than anything Drupal has ever done before. The way to serve the low-end market as well as the high-end isn't to try and hard-code more things to MySQL. It's to do exactly what we've done in Drupal 8: Loose coupling, clean interfaces, and an Additive System.
It's hard to keep up with API changes
"The Drop is always moving", as we say in Drupal. That Drupal allows itself to break APIs between release has been a long-standing source of pride for many. Certainly it has worked out well for us many times. Every time a new major Drupal release comes out, there's much wailing and gnashing of teeth over the APIs that have changed and yet modules do get updated, the system moves forward, and the market share grows.
That process won't last forever, though. The bigger the market share, and the larger the sites built on Drupal, the harder it becomes to swallow large API breaks between versions. Talking about backward compatibility, or better still forward compatibility, is something wise Drupal developers have known we would have to face sooner or later.
Of course, once again Drupal 7's architecture made backward compatibility effectively impossible. Big piles of naked arrays do not an API make, and keeping raw data structures backward and forward compatible is extremely difficult. It makes innovation, experimentation, or even just evolution much more fragile, because you don't know who might be relying on an implementation detail that you've exposed.
Building an API that can evolve without breaking is not easy. It takes hard work, discipline, and planning. It also requires defining clear, clean interaction points between components. In PHP, there is a language construct for exactly that: Interfaces. Using interfaces does not, of course, automatically make code extensible. However, it aids in building APIs that can evolve without breaking.
The other side of the equation is not technical, but social. Drupal's traditional development model actively encourages "abandoning" a stable version as soon as it's released, because there's immediately a new blue-sky next version of Drupal to work on, but we don't know how long we have before that goes away again. That immediately draws attention to the next shiny without needing to think about non-breaking evolution. That may sound fun, but believe me it's really not. And it's not a good plan for the long-term health of a project.
That's exactly why at DrupalCon Prague I lay down a challenge to core developers: Leverage this new capability in Drupal 8 and evolve the platform without breaking APIs. Drupal 8 is the first version of Drupal that makes that possible, and we should leverage that.
The feedback to that presentation was overwhelmingly positive. Most notably, Drupal 8 release maintainer Nathaniel Catchpole was firmly in support (and had been suggesting something very similar himself for a while). In follow-up conversations in Prague, most of the core team is at least tentatively supportive. Dries and Angie are particularly cautious of making sure that we have enough resources to maintain Drupal 8 feature branches, but if we can make that happen then I think it's likely that we'll be taking a new approach for Drupal 8 and allowing feature-evolving backward-compatible development. There's continuing discussion of it happening as we speak.
And that's made possible in a large part by the drastic changes that have been made in Drupal 8 to shift to a loosely coupled, object-oriented, interface-driven architecture.
Novice developers can't handle fancy architecture
Of course, all of those changes to the architecture result in a very different system than we're used to. A great many Drupal developers learned to code from Drupal, and as a result there is a fair bit of concern that the new Drupal 8 approach will be harder for novice developers to pick up.
While that's an entirely legitimate concern, I think it's vastly over-stated.
For one, most developers who learned to code by just reading, copying, and pasting Drupal did so years ago. Drupal 7 is, in fact, a rather obtuse and hard to understand architecture for anyone who isn't already fully versed in render arrays. It's far harder for people to "just pick up" Drupal 7 than it was for Drupal 5 or 6. The claim that Drupal 7 is easy for people to pick up randomly and Drupal 8 isn't is really only made by people who already know well Drupal 7 and versions before it... which means it's not a fair comparison in the first place.
For another, it's certainly true that many of the core bits inside Drupal 8 are highly involved. Complex software is complex. But that was true of Drupal 7, too. How many developers really understand all of what goes on inside the Drupal 7 menu system? Relatively few. How many really understand the entire form rendering pipeline? Relatively few. How many really need to in order to get their day to day work done? Relatively few.
The same will apply for Drupal 8, just as it always has, and just as it does to the majority of software projects. The further you get toward the inner workings of the system, the more knowledge will be needed but the less likely you are to need to be there in the first place. "Well you stick this function here, name it this way, and some magic happens" gets replaced by "Well you stick this class here, tweak this YAML file, and some magic happens".
It's not inherently any more complex. With cleanly documented interfaces that cluster highly cohesive functionality together replacing a handful of pseudo-hooks that don't hint at each other's existence I'd argue it's actually easier to pick up. (Certainly that's been most people's experience with Field widgets and formatters and other things that are now core Plugins, so far.)
The other part of this argument is that OOP code is hard and only for a "higher-tier" of professional developers, while "mere mortals" can only handle mere procedural code. To be frank, I believe that argument to be completely false. It is certainly true that developers who do have an academic background or formal training are far, far more likely to have an OOP background than a procedural one. It's also true that the overwhelming majority of PHP projects today are OOP-based, so anyone with any experience outside of Drupal is going to find it easier to learn Drupal 8 than Drupal 7.
I've talked to Drupal business owners who have said they have an easier time hiring novice developers with no experience and training them on Drupal than they do hiring an experienced developer who already knows PHP well, because those who already know PHP from any other project are turned off by Drupal's array-oriented programming. For pretty much anyone other than total novices, an OOP-based system is going to be more familiar and easier to pick up.
However, that doesn't mean the "little people" can only handle procedural. Procedural and OOP are simply different mental models for how to address an algorithm; neither one is universally "natural" for the human brain. It takes time to train yourself into thinking that way. For developers coming from a "blank slate", copying and pasting one magic incantation until you learn how it works is the same process whether it's a procedural magic incantation or an object-oriented magic incantation. If anything, more highly-cohesive magic incantations (related stuff is in one class together) are easier to copy and paste. People learn what they're exposed to.
Existing developers will be left behind
That of course leaves the largest constituent of array-oriented developers around: experienced Drupal developers. It's entirely true that for developers not already plugged into Drupal 8, there hasn't been a great deal of concerted effort to get them trained and on board with the new system. Documentation for the new systems, outside of docblocks, has been lagging severely. That makes sense, though. Why train people on a system that's still shifting daily? Developers who are not working on core probably shouldn't be paying close attention to it until very recently, because what they learn one day will change the next. A blue-sky development process is like that.
But is that really surprising? We're still in early alphas of Drupal 8, and the API is not actually frozen. Honestly, we're still 5 months at least away from an 8.0.0 release, and that's being optimistic. When Drupal 7 was "not quite frozen yet", how much documentation was written? How many books were out? How many screencasts were there? How many people outside of the core 100 or so really knew how much work porting from Drupal 6 was going to be? It was pretty thin on the ground.
Now that the Drupal 8 development is slowing down, though, we're seeing that change at exactly the right time. Drupal Planet has had dozens of blog posts about Drupal 8 development and getting up to speed in the past few weeks. A few companies have already begun offering training seminars on Drupal 8, with the appropriate "it's not quite frozen yet" warnings. (That includes my own employer, Palantir.net, with training seminars led by myself and Robin Barre. Expect our next event sometime in December.)
At DrupalCon Prague, there were two different "Lab" sessions (2 hour hands-on workshops) on Drupal 8 module development, plus a Core Conversation by Joe Shindelar on teaching people Drupal 8. That was followed-up by a BoF with several core leadership folks discussing various tools to make learning Drupal 8 easier. That will likely include more blog posts, a push on core documentation, and improved tooling. The Coder module is now developing a roadmap for the Drupal 8 version of Coder Upgrade. There are also people working on Drush commands or similar to help build out scaffolding for Drupal 8 modules, which will greatly simplify some of the more mundane parts of starting a module. (I think there may even be multiple efforts here.)
As Joe said, we need to start teaching people Drupal 8 Now. Not 6 months ago when everything was still up in the air, not 6 months from now when Drupal 8 is in RC state, but right now. And right now is exactly when the discussion is happening, and plans are forming to build a network of trainers who can help bring the whole community up to speed on Drupal 8.
No one wants to leave existing Drupal developers behind. And no one intends to. On the contrary, work is underway to ensure that the entire Drupal community moves forward, together.
Looking forward
Trite as it may sound, the future is ahead of us. Drupal has a number of challenges, and a number of structural and institutional problems that need to be addressed. In fact, they are being addressed... by Drupal 8. Drupal 8 will be an exceptional release; both in the sense of "really cool" and "really rare". The work of hundreds of people over the past 2-3 years has been to not simply add features to Drupal, not simply to innovate its API, but to push the project forward structurally and culturally to allow us to address long-standing pain points of our development cycle and community evolution.
What some may see as an unfamiliar change is, in truth, the way we address problems that have plagued Drupal for many releases but could not be handled any other way. Loosely coupled architecture, more industry standard techniques, and the removal of long-standing and long-outdated assumptions are not a threat; they are exactly how we can address issues of small-scale sites, of Drupal's spastic and often painful upgrade cycle, and of the constant challenge of finding Drupal talent in a field where Drupal rarely overlaps with talent in any other area. And we will do it without abandoning our current strong community.
Drupal 8 is going to kick ass.
Very interesting post, thank
Very interesting post, thank you !
Actually, what you point out is also perfectly valid for eZ Publish 5.
It's not about code, OOP, architecture, APIs, etc...
It's not about code, OOP, architecture, APIs, etc... The real issue IMO is about the "By whom / for whom" question.
While in the past many of us where pretty confortable with the "By developers / for developers" idea, this started to shift slowly with Drupal 7 ("for end users") and heavily with Drupal 7 ("for end users and big corporations").
The real impact of this in the development process is not about the code itself but about "how decisions are made" and by whom. While in the past it used to be more like "- I need this feature- Ok, try coming up with a good patch, we'll see..." with Drupal 8 I've seen it more like: "We" do need this / You guys code something / Ok, kind of works, we commit it.
And the practical consequence of all this is that it may be as hard getting committed a small module improvement with little or no impact on other subsystems, as a big architectural DX-impacting "revolutionary" improvement, with little or no discussion at all, just because "we needed it" (who?). That can be really frustating for some people.
Then the discussion comes later, of course, and that's what we are watching now. And it's not about changing the 100% of the API, but about doing it without real consensus.
So well, maybe Drupal 8 is "by corporations / for corporations", then we developers can just sit back, relax, wait for it to be released, and then (maybe) use it or not. And in the meanwhile give Drupal 7 some more time because since Drupal 8 "needs" to be packaged with so many features, we have no idea of when it will be released.
So I really have no doubt about Drupal 8 going to be a truly great system. My only question is for whom.
It's by people who contribute
It's by people who contribute code, and for people who contribute issues to drupal.org.
That's naive beyond the pale.
That's naive beyond the pale. Dries himself admitted in a computerworld article what drupal is about now:
"I think with small sites I'm not willing to give up on them but I think we just need to say we're more about big sites and less about small sites, but then the small sites are still very useful to get people into the community, Buytaert said."
I'm not sure how happy the small site developers are going to be about being 'used' to poach developers for the community while the needs of the very environments they come from are being actively cast aside.
However, I think what irritates me the most is the disingenuousness of all the spin being proliferated due to being afraid to outright offend the smaller site focused developers (which tend to serve as a source of future enterprise and core developers as well as the huge contrib community so crucial for success) while clearly tossing their needs aside anytime there might be a potential conflict with enterprise goals.
Say/spin whatever you like, whenever there's a dichotomy between enterprise and smaller site needs we know who'll win.
I also find it quite serendipitous that all this recent outreach for drupal 8 comes hot on the heels the backdrop announcement (probably the first fork by such high profile core developers that might actually have a chance to succeed).
if backdrop succeeds in only making the drupal core community more concerned, responsive, and inclusive it will have done the community a great service.
Regardless of what Dries
Regardless of what Dries says, all the work takes place in public. Check the issue queues and if you don't like it then communicate using them. It should be transparent, civil, and sensible.
Disagree with Dries
That's Dries' attitude, not the entire community's attitude. Don't confuse the two. :-) Dries is an overall weak BDFL (in the sense that he doesn't exert the level of control that, say, Fabien does over Symfony).
I fought to keep Drupal low-end scalable for a long time. At this point, though, there is a threshold below which it just doesn't run from a system requirements standpoint. The growth of cheap VM hosting, though, and with it the availability of opcode caches, gives us a new chance there. That's especially true with newer PHP versions (5.4 in particular) that greatly reduce memory usage.
A loosely coupled system, though, like Drupal 8, is our best shot at seriously engaging the low-end again. It allows us to separate out different parts of the system, optimize them properly, identify the system hogs and corral them into discrete systems we can optimize or replace, etc.
I am not willing to cede the low end for the sake of enerprise-y sites, but I'm also not willing to sacrifice large sites in the name of running on $5 over-sold shared hosts. The way to cover the "big middle" is flexibility, which is what Drupal 8 offers.
Oh yeah, and kick-ass site builder tools. We've got that in spades. :-)
I should have been clearer on
I should have been clearer on what qualifies as small. I agree 100% with not being able to cater to $5 over sold shared hosts.
But there's a entire universe in between $5 hosts (sorry, but you get what you pay for, so be it) and enterprise level sites with $$$,$$$ to throw at projects. I'm in probably what qualifies as an enterprise but in the healthcare industry where IT budgets are severely lacking. I simply cannot continually justify 1) having to throw $$,$$$ at better infra for each intranet site and 2) planning for $$,$$$ per site every time a major version 'upgrade' (which we know it's not, it's a complete rebuild for anything but the simplest sites) requires me to get off an insecure and no longer supported version. I'm actually fearful of having to pitch a d8 upgrade which will likely take a year or more to rebuild the site and upgrade any custom modules and themes. Suddenly, all the benefits of going with an open source solution like Drupal pale in the face of the cons.
Make no mistake, d8 is going to force shops between the $5 shared environments and super enterprise environments seriously reevaluate their selection of drupal in favor of something else that will require as much work for migration but provide a more stable forward path.
If that's part of the grand plan then so be it-- those of us in that predicament will find another solution I'm sure. We found Drupal, we'll find a successor. But if not, no amount of spin, training, and outreach will stem the exodus.
I just don't understand your
I just don't understand your statement about how D8 being released forces you to pitch a D8 upgrade to a client just to "get off an insecure and no longer supported version."
Even with the current model D7 is fully supported until D9 comes out in ~2017 if we're lucky? I don't understand why not just leave sites on D7? There's nothing about D8 being released that makes D7 sites stop functioning or insecure all of a sudden. And see my below comment, pushing for even further support on D7 is something I'd completely get behind, so that it's fully supported until D10 comes out (when would that be, 2020?).
Of course there's php version support implications here as well, but let's get through those as a community, update D7 if/when appropriate here, etc. No reason to not get serious about long term support.
Agreed - one can easily still
Agreed - one can easily still find D5 and D6 modules around with support... this leaves D7 with the same expectations for D9. And really - what kind of (person) client leaves a site un-upgraded for more than 3 years, and is that the kind of client you want to deal with forever?
Migrate
Let's not forget that inclusion of migrate in D8 core, essentially replacing the upgrade path. This will be really appealing to clients. Now they can jump from D6 to D8, instead of having to hit D7 in the transition. Since that announcement I have already notified customers of this option. Two of them, that were planning on just sticking it out with D6 until time for a major site upgrade/restructure, have now decided to go to D8 once it's stable.
It's probably the result of
It's probably the result of being in healthcare. But my apps and systems are routinely subjected to security evaluations which result in a laundry list of stuff that I must do to comply. No gray area and no discussion.
And granted, the 'evaluation' is not necessarily being done by those best positioned to understand the technology involved, but past experience has taught me it's absolutely pointless for me to argue that my app and server are not susceptible to some random security bug reported against a particular point version of php.
And the site in question is on d6. A decision was already made to forgo an upgrade to d7 and wait for d8 (but that was prior to all the symfony integration). However, unless Dries unveils a new policy, d6 will become unsupported and not receive security updates when d8 is released. Thus my dilemma.
And as you rightly point out, this doesn't even address all the issues resulting from the version of php required for a particular major version.
I'm not, in any way, arguing the bureaucracy I have to handle is correct. But it is a fact of life. And I'm sure I'm not the only one.
As much as I've seen complaints about the d6 to d7 transition, I didn't think it was that bad (though I admin, I've never bothered with an upgrade just a rebuild and migration, and module updates). And I was confident that the estimates I could provide for different task times (rebuild, upgrade custom code, upgrade theme, migrate data, etc) were pretty spot on. From what I've seen to date, I have zero confidence in initial estimates which are already too long.
I get that the 'drop is always moving'-- i really do. And I've argued, sometimes passionately, that, though sometimes difficult, it is the correct philosophy. It's just that this time the drop didn't move... it morphed into something else completely. And I'm not sure I'm willing to risk my career, especially in this economic environment, into such an unknown.
Where's the conflict between large and medium?
I totally sympathize with this concern in the abstract. I tend to dislike and distrust large corporations, because money can buy power and power tends to corrupt. However, I've been a Drupal user/developer for over 8 years now (disclosure: I currently work for Acquia, interpret that however you wish), and I can't currently recollect a single Drupal core decision that has favored enterprise sites at the expense of medium-sized sites (I say medium-sized given your followup comment). Perhaps my memory is bad or I just haven't come across the issues where this has happened, so if you're thinking of something specific, please share it. But when I look at what's gone into Drupal 8, from shifting the architecture to decoupled APIs as this blog post is about, to everything else mentioned in https://drupal.org/drupal-8.0, I see stuff that is just as valuable to medium-sized sites as to enterprise sites.
As this blog post also mentions, Drupal has always (or at least, for the last 8 years) required expensive upgrades/migrations/rebuilds to get onto a new major version for all but extremely simple sites. Site owners have dealt with this by either skipping one major version (which can be done with no loss in security support), or in some cases, continuing to stay on an old major version even past its security maintenance (do this at your own risk). So this problem existed well before Drupal entered the enterprise market. And enterprises like saving money just as much as medium-sized organizations do, so everyone in the Drupal community would like to see this problem fixed. And this blog post makes a case for how what's gone into Drupal 8 gets us closer to that goal for Drupal 8. As to what kinds of support policies or tools we can create to make things easier for people with Drupal 6 and 7 sites, that is in active community discussion (some ideas are mentioned in this blog post). Backdrop, a fork of Drupal into a project that is either less customizable or slower moving or both, is one approach to this problem, but there are others. What ends up being best for whom remains to be seen. Since it's all open source, everyone is free to decide for themselves what they want to pitch in and help on.
thanks
Great article @crell
A lot of thought and effort has gone into this post, thank you.
Thanks for this great
Thanks for this great overview. I'm excited about Drupal 8 but dread the notion of upgrading to it from existing sites. We just don't have the budget. So I think there will be lots of Drupal 7 sites that will stick around even when Drupal 9 is here just like there will be Drupal 6 sites when Drupal 8 finally drops.
This is the one big constituency that you missed out. Small to medium organizations (like charities or schools) who simply cannot expend the effort on keeping their Drupal install uptodate - even if it's only once every six years. I still have a handful of Drupal 5 sites I never bothered to upgrade. This is the target group that Backdrop is aiming at and although I will certainly build Drupal 8 sites, I might end up with some Backdrop one in the legacy sphere.
That's why so many people are looking to Wordpress. I've used the multisite feature to set up a bunch of simple sites and four years later, they're uptodate without any major effort from me (see here for details: http://techczech.net/2012/07/28/drupal-wordpress-choice/). Hopefully, Drupal 8 will make something like this possible and if so I will be singing its praises, but I fear that if Drupal 9 comes around bringing the same upgrade traumas as Drupal 6, 7 and 8 did, I and lots of other small site builders may not stick around.
The plan is to include
The plan is to include Migrate in Drupal 8: https://groups.drupal.org/imp
That's the goal
Yep. Drupal's boom-break-boom-break dev cycle is not sustainable. That's exactly why I'm pushing for us to stop doing that, and leverage Drupal 8's more loosely coupled architecture to have a smoother enhancement cycle.
Drupal 9, whenever it happens, will still have BC breaks. (That's why it gets called Drupal 9.) But if we do it right they should be far more contained and manageable than in Drupal 7 or Drupal 8, and many of them could even be available earlier than that in 8.x as optional forward-looking options.
Terrific article. One
Terrific article.
One erratum: "trained an[d] on board"
D'Oh!
Thanks, fixed.
I think you hit the nail on
I think you hit the nail on the head of something that has been bugging me about this whole thing. In my estimation Drupal 7 isn't anywhere close to approachable for a novice developer. I'm not sure I understand that as reason enough for a fork.
Honestly if people want to stick with D7, then I'd say a much better overall solution would be extended support for 7. I don't see anything yet in Backdrop that couldn't be accomplished as a D7 distro (albeit with some heftier patches than a normal distro). But turning Backdrop into an extended support 7 distro would ensure continued compatibility with the existing community modules, and would also alleviate some of the fears around the projected high cost to upgrade to D8. "Don't want to spend the $ to upgrade to D8? No worries, D7 is still here and will be supported for the next 5 years." Then at that point if there is continued interest in keeping D7 around in coexistence with D8 and D9 then the community should just keep supporting it. It would accomplish the chief goals of Backdrop, but in a better way since it maintains compatibility.
Security team
I would be in favor of that, but remember Drupal 7 is even in our current model supported until Drupal 9 comes out and that's not happening any time soon. :-) Drupal 7 still has several years of life in it. Beyond that, it mostly comes down to whether the security team has the resources to keep it patched. If they do, extended security-only support on Drupal 7 seems fine to me.
Yeah that's what I mean,
Yeah that's what I mean, extend security support for D7 even after D9 comes out (which I agree is a way off). Just because D8 is out (when it's actually out) doesn't mean that D7 turns into a pumpkin :-)
$5 Hosting?
I personally don't see the issue with small sites, $5 hosting and Drupal 8 for several reasons:
First off, a person using a cheap shared hosting plan, usually only has one website on that plan and that site consists of maybe 10 pages at most. I can't see D8 being such a dog that it won't perform well with 10 or so pages, especially with the built in core caching and the efforts of third party contribs like Boost.
"Well what about scalability?"
Second, if a website starts small, and needs to scale, like anything you change the environment to accommodate the growth. The argument about scaling is like telling a newly married couple that they need to trade in their smart car for a 12 passenger van in case they decide to "scale the family". No, that married couple will get a bigger car when they need one. Same goes with scaling a website. If you start out with a shared plan and the site grows, you either get a more robust plan that can handle it or figure out how to live with what you've got.
Third, all of this discussion about Drupal being bloated, or being a resource hog is such a moot point. Most software that gets written, gets bigger by nature. But so does the hardware. As software scales, the hardware scales. My current host recently upgraded their servers. Over the years, they upgraded the memory. At some point, they bumped the php limit from 96MB to 128MB and now it's at 256MB. The hosting has to scale just as much as the software scales.
Windows 7 doesn't run worth a crap on a computer designed in XP days... Why are so many people concerned about Drupal 8 running on "today's" hardware, when that hardware will be obsolete in a few years? Even if D8 releases in 5 months, it will be a minimum of a year before it's really ready for mainstream usage. How much will the hosting environment change in a year and a half?
Point is, I feel like people need to dismiss the argument about Drupal 8 being a resource hog and accept the fact that if it won't run on their current platform, it's probably an indicator that a change needs to be made anyway. Unfortunately within the OSS community, everyone expects the latest and greatest to run on 15 year old hardware... We have Linux the thank for that mindset... There's a time and place for using old cheap stuff, but a business website shouldn't be one of them.
Just my $0.02
Larry - Thx for the post and all you do/have done for the community!
I, for one, welcome our new base class overlords!
In addition, saying D8 "is a resource hog" now is way too early. It's not even in alpha. Refactoring and optimisation *can* only take place starting about now in the development cycle.
A "Small Drupal" user opting for D8
I build sites for small business mostly and everything Backdrop stands for (or promises at this point) resonates well with my clients needs which are primarily these two:
1. Stability / LTS
2. Low-Fi Hosting
It is very hard to sell a rebuild to small clients who are perfectly content with the current solution they run. It is true that it takes a good while for any major Drupal version to reach the point where it is no longer covered by security patches, but it is unavoidable. The pressure to rebuild from scratch a perfectly fine website is pretty darn high with Drupal compared to most other CMS out there. The extend of change in D8 appears to be massive and for the most part I can understand the reasoning behind it and I accept it as necessary change to enable less volatile progression with future versions of Drupal.
I understand Nate being discontent that D8 burning all sorts of bridges while most the same new features could be built using the D7 architecture. The question for me however is, how future proof each approach will be and I side with D8 on that matter.
That said, if despite massive changes, the D8 architecture turns out to be incapable of supporting future evolution, that would be the reason to abandon ship for good. I do not just think it would be nice if D8 could mark the beginning of a more stable, less BC hostile development path, I think it is essential and the major hope that justifies the investment required to move from D7 to D8.
Regarding hosting: Drupal is a lot more expensive than many contenders for anon sites (smallish sites that cater almost exclusively to unauthenticated users). You have a choice between abysmal page load times on shared mass hosting or pay at least 5x for decent cloud hosting on aquia or pantheon. VPS being more affordable is no argument here, the staff required to setup and more importantly administer them makes it the most expensive route for small clients.
I hope that we'll see D8 serve as a more stable technical foundation and I also hope that at some point someone will have a go at the mass hosting market for small Drupal sites, offering not top notch, but decent caching/performance without the bells and whistles (dev/stage/prod workflow) that most small sites don't actually require.
All that said, D8 gets away with almost everything, just for the incredible advancements in i18n support (that apparently will be hard to replicate in Backdrop relying on D7 architecture). I expect D8 to do really well in Europe for that matter alone.
Thanks for such a well thought out and well written post
I myself have been thinking that the core (no pun intended) issue here is that the Drupal community is having to make a choice about whether we are going to "go enterprise" or target ease of use for the non-technical people. My personal opinion is that Wordpress pretty much has the entry-level locked up and that it makes more sense for Drupal to go after the enterprise-level.
To me it seemed clear that it makes no sense to try to be "all things to all people." While I still feel that way, the big issue was that I couldn't see how it was possible to build a framework that was both powerful and extensible (like Drupal definitely is) while at the same time making it easy. The more configurability that a product has, by nature the more complexity it will have. I figured that the only way to make it easy was to build this huge wrapper layer that the newbies could use out of the box, while the experienced people would dig underneath that layer.
That huge layer would surely come at some cost, which was at a minimum likely to be worse performance. My thought about how to overcome this performance hit was that the framework would provide a way for the more advanced users to strip away that scaffolding layer and use the underlying more efficient (and more complex) direct access techniques.
You have raised an interesting point about loosely coupling things, providing clean interfaces and building an additive system to allow for experimentation and backward and forward compatibility. It's essentially the opposite approach as I had envisioned. Instead of stripping away the scaffolding to make things more efficient, you would strip away the compexity to make things more basic. While this will still likely take a skilled Drupaler to accomplish (and thus won't make it any easier for the unskilled ones), it does at least begin to provide some mechanism for configuring the framework so that it is usable in different environments.
I also appreciate the treatment you have given to the other points that followed in the post. It's this type of thoughtfulness that I think makes Drupal the great product and community that it is. Thanks for taking the time to put in the thought and writing this post.
Thoughtful and Balanced Analysis on D8/Backdrop
This was a great read and I appreciate the positive analysis on all the topics. There are however a few areas that I'd like to clarify on behalf of Backdrop.
Backdrop is of the same mentality. I'm pretty sure I've said it on every podcast we've done 1, 2, 3. Backdrop is not anti-OOP. This is an assumption people have been making because we're saying that the architecture of D8 is complicated. We do rail against the dependency injection container regularly however, so if you want to say we're against a particular pattern in D8, please use the DIC instead of OOP.
We also think Drupal 7 is too complicated and isn't particularly easy either. In attempting to take Drupal more down-market we're removing abstractions and simplifying systems. Of course, removing abstractions means breaking APIs, which we're also trying to avoid, so the significant simplifications may come in later versions (2.x, 3.x, etc). Just adding CMI and the underpinnings for the significant list of features to be added is probably going to be as much change as we're expecting developers to tolerate.
---
Otherwise, this was a great synopsis. Written from the core developer viewpoint, it's probably a little rose-colored about the possibilities D8 is going to deliver, but Backdrop's aspirations are similarly ambitious in different directions. :)
I think both platforms, Drupal 8 and Backdrop, will be successful. If what we've seen so far is any indicator, with a real focus on simplifying syntax, building documentation, and several marketing blitzes, the introduction of Backdrop has had a tremendously positive effect on Drupal 8. Regardless of the outcome, end-users are going to benefit from having this choice available, and both systems will be better for it.
SOLID Principles
First, I am proud of how the Drupal Community immediately embraced the "We won't be ugly" concept and it's good to see you and Larry following suit. We either buy into the concept the GPL offers users, or we don't.
Second, as an observer, I understand (and appreciate) both perspectives. This isn't a Drupal-only issue, API changes are so costly collectively we leave many websites behind, vulnerable and not able to take advantage of emerging technologies. On the other hand, the reason we are doing so has more to do with how software is constructed than that we are making more changes.
Finally, I'd suggest that the term OOP means very little in this debate. OOP, poorly implemented, can create inflexibility that is impossible to overcome. Taking my experience with Joomla, as an example, v 1.5 was that first step into OOP which should be a good thing, except those of us who worked closely with the code base this past 5+ years understand that implementing patterns incorrectly and not understand abstraction properly, created severe problems in the code. Those problems continue to this day.
A better point of reference for open source developers to rally around is SOLID -- http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 In applying those principles, it is easier to make changes to an application without impacting the API. Dependency injection is a key element to SOLID. Combined with Interfaces (and structured correctly) significant change can be implemented to framework level code structures without any need to adapt to the code change.
That's why I see the development strategy for Drupal 8 as smart. It is using SOLID principles in constructing the base framework. That should make it easier to then bring improvements without radical (or, in some cases, any) changes to the public API in the future.
Don't be STUPID, grasp SOLID
Anthony Ferrara (@ircmaxell) has been talking about this a lot lately in his talk "Don't be STUPID, grasp SOLID"
Target a a 'junior drupal' to small businesses & organizations
I like your idea of a 'junior drupal', but not this recurring idea of a simple Drupal website being a blog. Leave that to WordPress! Millions of small businesses, organizations and schools need websites—it would be great for basic Drupal functionality to target this need instead of a blog. A great selling point would be: Easy to create a basic, functional website; powerful enough to expand as much as you want as you grow.
Documentation is *absymal*!
> When Drupal 7 was "not quite frozen yet", how much documentation was written?
*Before* I added the new menu system to D6 it was documented. When simpletest was added we have written documentation, rallied sprints, created even an automator module to help people start. I have written the Field API tutorial on February 8, 2010. What are you talking about?
Good article and valuable discussion
I'm interested in this discussion, and have welcomed Backdrop, because web tools for small, low resourced organizations has been my Drupal focus for the 10 years I've been doing Drupal work.
I see it this way: enterprise-level corporations don't need my help. They're doing fine on their own. They don't lack for options, and the internet is theirs already. I realize it may sound hopelessly idealistic, but really: if I'm volunteering my time to work on free software, surely it's not for the rich and powerful. Surely it's not to reinforce and strengthen state and corporate power structures. Surely it's, instead, for an ethical commitment to those who are being left out--the small, local, community-based groups that are where the hope for positive change comes from.
I think we want to be extremely careful using terms like "natural" when describing what's going on in our software community. Our work has always generated multiple possibilities. Why particular directions win out calls for some structural and social analysis.
Practically, I've spent most of the Drupal 7 release cycle working, with very limited success, to produce, in Open Outreach, a distribution that serves the needs of small organizations. That gives them more than a brochure site. That instead gives them the tools that larger organizations enjoy, thanks to custom site builds that start at the tens of thousands of dollars.
In practice, keeping the best of our work and web technologies within the hands of the majority, not just those with money and power, is probably just as challenging and rewarding as delivering something that meets enterprise needs. I only wish I could call this a "solved problem"!
It's great that Drupal 8's architecture creates the potential for flexibility and pluggable systems that could serve small users as well as enterprise ones.
But what are we doing to ensure that's more than a theoretical possibility?
I've been using Drupal 8 for
I've been using Drupal 8 for about a month now so I think I can report with some confidence my experience, as someone who learnt PHP as a means to using Drupal 5, 6 and 7, although I started in Drupal 4.6 I did't really get going until D5.
For each version since D5 theming has gotten easier and easier, however it also got more complicated. Let me state this - Drupal 8 is on a whole other level, of both complexity and power - but it's a good kind of complexity and power.
I am a very average PHP developer, and even I can understand everything I need to, so far, to get stuff done. Larry points this out really well - do you really need to understand the entire theme system to build a theme - nope. Would it help if you did - maybe, maybe not. It depends, if you are building the sorts of stuff I am, then sure, it does help, but if your needs are pretty average, then no, you certainly do not.
For the D8 version of my major contrib project I have been able to leverage many things in Drupal 8, almost all of them new. CMI, yml files, many classes and by extension of that of course going OO. The "everything is a block" idea is a boon beyond comprehension for most themers - clearly I am excited about this.
OK, so the code is one thing I am thankful for thus far, the other is the ushering in of new ideologies. I've employed, as much as my understanding and capability extends to, this idea of loosely coupling things and of not invented here, completely replacing the layout system in my project with Susy Next (Eric Meyers SASS layout framework), yet you can easily remove it, or replace it with anything you want. The system is agnostic. I probably would not have gone down that road before because I never really thought in that space - D8 inspired that thinking, and thus triggered innovation and new ideas. For that I am very thankful.
In many ways I agree with Larry when he says small sites are a solved problem. Look, I've been doing this for a long time as well (web dev) and to be frank it's a brave new world out there people. A great many of yesteryears problems are solved, the really hard new problems are what need tackling now, and we need the tools to do it. On that level it's easy to see that D8 could not just evolve, it had to be a revolution, risky yes, but it absolutely had to happen, and now.
For me Drupal is just a tool for getting things done, that's not going to stop. I see enormous growth and potential in Drupal 8 and quite frankly I'm excited about it.
What I would say is this, dive in now. Really, get immersed in the code right now. I made a big commitment to learn new stuff this year and after all, isn't that what working in this game is all about?