The year was 2008. I was a senior in high school, and I had been running a web development business with a longtime friend for two years. During this time, my partner and I had produced over half a million lines of code for our in-house CMS. It was built on CodeIgniter, which was quite popular at the time - and for good reason: the developer experience was exceptionally good, and pretty much everything in the system was unbelievably well documented.
Our goal was to produce an enterprise-ready CMS that would allow almost anyone to click together an amazing website with little to no developer involvement.
Towards the end of 2008, we realized that all of those late nights/early mornings we spent on the system were piling up in the form of technical debt, and we started looking at what it would take to rewrite the CMS with a cleaner architecture in mind. In November of 2008, we found Drupal, and by December, we had abandoned our plans for a rewrite of our CMS, and migrated every customer we had (all ~10 of them) to new Drupal sites.
While Drupal included an awesome UI for everything that we wanted to provide to our customers, it was severely lacking in terms of developer familiarity. I remember having multiple lengthy IRC discussions about what it would take to move Drupal to an MVC architecture, and convert all of the include files to autoloaded classes.
So naturally, when I heard about the initiative to essentially rewrite Drupal on top of object-oriented Symfony components, I was pretty excited. I hadn’t ever weighed the pros and cons of this process, and I wasn’t really sure how it would turn out. However, since the core developers seemed pretty supportive of the initiative, I remained excited and dismissed the handful of dissenting opinions as reluctance to change.
In the meantime, I spent a lot of time building Drupal sites for one company or another, and I learned to love how Drupal did things. The Drupal Way, as we sometimes refer to it, has a lot of merit, especially in terms of learnability by newcomers to the project. During this time, I didn’t write very much code for Core, but I voiced my support for the work that other people were doing without spending a lot of time looking into what the changes actually looked like under the hood. This was extremely shortsighted, and I now know that.
I think anyone can agree that collaboration with the larger PHP community (“getting off the island”, as Larry put it) is a good thing. It will mean more developers from other projects can jump in and start building things with Drupal. A more Symfony-like architecture (or, as I’ve heard it called, “an unholy Java-esque monstrosity”) might also improve learnability with new CS graduates.
There are, however, other side effects of these changes that I don’t believe have been considered.
First off, just last week, we’ve had two pretty prolific contributors file patches to remove themselves from MAINTAINERS.txt (here and here), both citing lack of understanding of certain systems in core as reasons for leaving. I wonder, if two seasoned veterans of Drupal can’t understand something in Core, what are the chances that somebody else will be able to understand it? Are we willing to sacrifice the involvement of long-time contributors just to get off some island?
This is not a new trend. It’s not hard to see the difference in the list of people who frequented #drupal in 2008 and the people who frequent #drupal-contribute today. We have a vastly different pool of contributors. I’m not sure if this is due to normal community attrition, or people feeling like they’re being pushed out of the community due to competing technical goals for the project.
I, myself, have been resolutely avoiding Drupal 8 (and even left entirely for a short amount of time) because there’s yet another massive learning curve to get back to a state of proficiency with the platform. While I’m not opposed to learning new things, I’ve recently found myself wondering if that time would be better spent on something that’s more learnable, yet still built on Symfony components (like Laravel), or even switching languages entirely. I’m torn, though: Laravel or some other language might be a good choice from a technical standpoint, but I’ve made a lot of friends in the Drupal community over the past ~5 years and I’d hate to lose the opportunity to work with those people.
Second, much of the code that has been written and tested over the years has been reduced to a set of use cases, ripped out, and replaced with unproven code from another project. This has two effects:
It sends the message of, “Thanks for your contribution, but we’re going to remove it and replace it with this bundle of classes from somebody else. Hope that’s okay.” I know a normal part of the software development process is iterating on what’s been written and improving what we have, but normally, “improvement” implies forward progress. In my opinion, replacing relatively simple, procedural Drupal code with a pile of classes from Symfony makes things exponentially more difficult to understand with very little benefit.
It alienates the people that chose Drupal over the other frameworks. If I wanted to be a Symfony developer, I’d have chosen Symfony. But I didn’t. I chose Drupal - not because of strong technical “purity”, but because the goals of the project were closely aligned with mine at the time, and because of the awesome, supportive community that I found in IRC (which, I might note, was much more welcoming than what I found in the Wordpress or Joomla channels).
Third: we’re leaving people on the island. There has been a lot of discussion about getting off the island, but I don’t believe anyone has discussed who we’re going to leave behind, and I’m not just talking about core developers - end users may get left behind as well. It’s easy to chalk up resistance to Drupal 8 as unwillingness to learn or change, but as someone who’s experienced both sides of this argument, I think I can say with reasonable certainty that some people just aren’t going to like Drupal 8 - even some people who have staked their careers on Drupal.
In other words, it’s easy to say that we want to get off of the island, but it gets much more difficult to do so when we realize that doing so means we’re going to lose a lot of valuable contributors (with the possibility of gaining new ones), as well as some yet-to-be-determined number of users.
So what’s next? How do we solve these problems?
Honestly, I don’t know. I think it’s too late for Drupal 8. My experience with it thus far has been extremely discouraging to say the least, and I don’t know how much time I want to invest in it. Drupal 8 may be a release that I skip, and just hope that Drupal 9 is better.
I’ll reiterate: I am not anti-change. I know change is a part of our development process, and that we have good reasons for adopting the Symfony way of doing things. My problem is that the end result is extremely difficult to understand and unpleasant to work with.
I’d really love it if, in the comments of this post or in the issue queue, we could have a discussion about how to mitigate these problems when Drupal 8 is released, but as I said, I’m not sure how we can possibly fix this before D8 ships (especially when the API is “frozen”).
Perhaps I’ll learn to love D8 over time, but I know one thing: Laravel is looking damned good right now.