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