When I first heard the news that there was a Drupal fork, I was pretty surprised and doubtful. Then I heard who started the fork (Nate Haug and Jen Lampton, really respected Drupalers), and I got a lot more interested, really fast. I’ve been playing with Backdrop now for a couple of weeks, and have even contributed some pull requests. It’s helped me understand better the rationale behind the fork, and helped me think about what might happen moving forward.
There are several threads I want to follow in this post. It’s going to be long, so bear with me. It’s going to range from the technical to the personal.
First, I’ll start with what a fork in general means. Forks are common things in open source software. They happen quite often. That’s one of the benefits of open source/free software - if you don’t like the direction a project is going in, you can take the project in your own direction. It’s a lot of work and responsibility to do that, so it’s not often done. Not all forking is successful, and sometimes one or the other fork dies. There was the famous Mambo/Joomla fork. Mambo died because of it, so that is on a lot of Drupaler’s minds. (I certainly don’t think Drupal has anything to fear.)
So why fork Drupal? Drupal is a longstanding CMS that has been around since 2001, although has really only gained real popularity in the last 4 or 5 years. It has a large, vibrant community, and more contributors than any other open source CMS. It is now running quite a number of enterprise websites, including whitehouse.gov, newspapers and big corporations. It is very, very popular among nonprofit organizations. Drupal is in a particular moment, and I understand why this moment came.
For many years, Drupal was used by self-taught accidental techies, many of whom built their learning into a livelihood. Our team has folks like that. People without CS degrees, learning one step at a time. Some folks I know learned PHP because they needed to when they were building Drupal sites, or they got so excited about Drupal that they learned PHP so they could contribute. Over time, as Drupal got more and more popular, and people with bigger and bigger pockets were buying Drupal services, Drupal started to attract enterprise developers. Now, I’d probably wager that enterprise developers are as numerous as accidental developers in the Drupal community, if not more.
And the direction moving forward for Drupal is, in large part, because of that trend, because money talks. Dries Buytaert, the founder of Drupal, recently spoke about how Drupal was being “re-architected for world domination.” Their goal is nothing short of competing with the likes of Adobe and Sitecore, very high-end proprietary platforms. I don’t think this is a bad goal for an open source project. I’m all for open source/free software world domination!
So what does this re-architecting mean? Drupal 8 is, in many ways, a very different beast than Drupal 7 or 6. They incorporated a framework called Symfony. Incorporating Symfony means that Drupal gets a lot of advantages - the core (and contrib) can take advantage of rich libraries, it means fully embracing object-oriented coding, leverage namespaces and PHP autoloading. Drupal 7’s code is largely procedural, and has a custom autoload system.
So the big changes in Drupal 8 mean that in a sense, it’s keeping up with PHP’s technology. This is good stuff, but it has it’s downsides:
- There is, from what I understand, only about 25% of the code from Drupal 7 left in Drupal 8 (who knows how much of that will survive.) That is a lot of code. Pretty much everything has been (or has to be) taken from Symfony components, or re-written.
- It means that every single contrib module will basically have to be re-written. The “technical debt” is huge, not just for core. (There are now more new modules being written for 7 than 8.)
- It’s a lot more complex, and many developers who grew up on Drupal find it daunting.
- It’s a lot of bloat, and has performance issues (which will need to get fixed by launch.)
And remember, the reasons for this shift are about attracting enterprise developers and customers. It’s true, there are plenty of nonprofit enterprise customers, but most nonprofits aren’t. They don’t really need many of the advantages that Symfony brings to the table.
So why did this cause a fork? Backdrop came out of a situation of huge change, change that was daunting. It’s not just about a learning curve, which is a big issue. It’s also about the sheer hours involved in re-writing contrib and custom code to match.
Backdrop’s goals are pretty straightforward. Keep the easy-to-understand architecture of Drupal 7 and include the killer features, such as CMI (configuration management, moving all configuration to text files, thus easily kept track of using git, etc.). They want to appeal to Drupal 6 and 7 developers, some of whom have already left the Drupal project because of the big shift. They want to focus on performance. And they want to keep being able to attract entry-level/accidental developers. Backdrop is also aiming to slow down big, incompatible API changes, but speed up features to end-users.
If that sounds more nonprofit-friendly than Drupal 8, you’re right. I think it is. I think that the scenario where Drupal becomes big, complex, and enterprise-focused is a scenario which may include a higher ticket price for website development. You know those projects that hover on the edge of WordPress or Drupal, but fall into Drupal’s lap because of a need for some particular features hard to find in WP? In this scenario, there’s no point in even trying to sell Drupal 8 in those situations. It may well not be cost-effective. In Dries’ own words: “At Acquia we never compete with WordPress. We don’t see them ever.” Of course we never try to dissuade people from choosing WordPress, but we come across this all the time, and we know that for some sites we’ve built, WordPress was indeed an option.
Now for the more personal. First, as a developer, I am self-taught, but I’ve been developing websites since long before Drupal (I wrote my own CMS, back in the day.) At first, Drupal’s PHP baffled me (still does, sometimes.) I’ve played with Symfony, and liked it. So you might think that I’m a great candidate for the Drupal 8 bandwagon. But I’m really practical - I think about what my clients (individually, and the sector writ large) need.
Also, I’ve been a part of the Drupal community for more than 6 years, and have interfaced with it for over 8 years, since my days helping to get the Nonprofit Open Source Initiative off the ground. And one of the old hallmarks of the Drupal community was a certain kind of unfriendliness, especially to newbies and women. Thankfully, this has changed, greatly, over the past 5 years, but I still remember it. And, sadly, there has been some pretty nasty backlash from the community about Backdrop:
“Backdrop is about preserving the bad parts of Drupal for people who don’t want to learn actual programming skills” - John Locke
There have been tweets and quips of all sorts like this. I wouldn’t say this was the predominant reaction - there have been a lot of positive comments about the fork, as well as lots and lots of “let’s just wait and see.” But as I read a lot of tweets of the above nature the day after the announcement, I got a familiar twist in my gut, remembering things that happened years ago around Drupal. And I will say that I have gotten really friendly, helpful reactions to my contributions to Backdrop. That means a lot to me - not only personally, but professionally.
So let’s wrap this up. What does this mean?
It’s not clear. The Backdrop community is still tiny compared to the Drupal community (although it has grown greatly just in the couple of weeks I’ve been tracking it. There are now 70 forks on github (that means that as many as 70 people might be working on it.) So far, few, if any contrib modules have been ported to Backdrop, although it will be a lot easier to port contrib to Backdrop than to D8. When Backdrop will be released is as big a question as when Drupal 8 will be released, as is when enough contrib modules are ported to make it actually useful. If you aren’t a developer, and aren’t interested in wading into either project and contributing, thus seeing better the innards of what’s happening, there isn’t a lot of way to know how this is going to shake out. Even if you are, it’s hard to know. In a year, things will be clearer.
I expect to be using both, at least for a while. It will take a while to figure out which to use, depending on the state of each, and the use case. We have at least one client who would likely benefit from the advantages of Drupal 8, but many who don’t need them. Since both will have CMI, there isn’t really an advantage there.
There is room in the ecosystem for both! There is plenty of room for both platforms, given their different goals. No acrimony is needed on either side. Both projects can learn from one another.
Good stuff on Backdrop:
Leave a comment