I love working with Drupal. I feel fortunate that I found a software and a community where I can work for work, and work for play. It's not everyone who gets to do what they love every day. I get to interact with amazing people from all backgrounds and walks of life, share what I learn, and learn from others. I especially like that this community can often agree to disagree.
Here's where you might disagree with me: Drupal 7 was too hard to learn. Drupal 8 will be harder just by its virtue of being more complex. I want there to be an easier alternative, for example: Backdrop CMS.
Back in the day, Drupal used to be hackable. And by "hackable" I mean that any semi-technical yahoo (that's me, btw) who needed a website could get it up and running, and then poke around in the code to see how it all worked. The code was fairly uncomplicated, though often somewhat messy, and that was fine. At the end of the day, it did what you needed.
Over time, Drupal grew: it gained features, got more flexible, covered more use-cases, and gathered more fans. A community of developers grew up around Drupal, some of us are professional computer engineers, some of us were self taught and learned by reading and writing Drupal code, and some of us just learned enough to get by.
When Drupal 7 was released, things had changed significantly from Drupal 6, and though most of us now agree that learning the new system was worth the time, it was a painful transition for almost everyone. Drupal adoption slowed to a crawl for months after the release, many modules were slow to be ported, and the number of sites running Drupal (at least according to Drupal.org) actually decreased for a while.
It was hard for the professional computer engineers to grasp what the heck Drupal was doing, and it was hard for all the self-taught to learn all the new patterns and changes on top of what was known before. It was hardest of all for those who knew nothing about Drupal before their exposure to Drupal 7. The sum of what needed to be learned had reached new heights.
We realized that somehow in Drupal 7's development, we'd crossed a threshold. Drupal had suddenly become too hard to learn. I experienced this pain first hand as the Director of Training at Chapter Three, I trained hundreds of people on building sites with Drupal, building Drupal themes, and building Drupal modules. I realized that the problem was not lack of documentation (or even a lack of good documentation) the problem was that Drupal was not intuitive enough. I love Drupal, and I want it to succeed, so I devoted myself to making Drupal easier to learn ("learnability") and easier to use ("usability").
It was thought that one of the reasons Drupal was so hard was that it was mixing new concepts from the professional computer-engineering world, with old concepts from the hackable web software world. At the start of Drupal 8 development, a decision was made. Drupal would shift all its concepts and design patterns towards professional computer-engineers, and in doing so attract a "higher tier of developer".
Though many people bought into this idea at the beginning of development, nobody really knew exactly where the road would lead. Today, core developers are working hard to remove nearly all the old Drupal code from Drupal 8. The old way of doing things is slowly being replaced with a new way. Info files are being replaced with yaml. Info hooks are being replaced with annotations. Theme functions are being replaced with Twig templates. As of today we only have a 25% code overlap (by line-number differences) between what was in Drupal 7 and what will be in Drupal 8. There will probably be even less by the time it's released.
Now, I'm not saying the new way isn't better. A lot of really brilliant people I greatly respect poured hours of their own time into thinking these problems through, as well as making the actual conversions. What I'm worried about is how this will affect the existing Drupal community.
Today, the majority of the people in our Drupal Community aren't CS engineers. They are self-taught Drupal experts, people less technical than myself, and people who can get by using this awesome software we've developed to help make their lives easier. What is the transition to Drupal 8 going to be like to them? Well, I asked some non-core developers, and I didn't like what I heard.
A lot of professional Drupal developers already have exit strategies. They may even have a day job building or maintaining Drupal 6 and/or Drupal 7 sites, but they go home at night and study Ruby, Node.js, Angular.js, even some are looking into WordPress. They want to be "out" before they have to learn Drupal 8. These are smart, capable people, who I'm sure - if they wanted to - would be able to pick up Drupal 8. So, why are they leaving? Because Drupal 8 has become different enough that learning it feels like learning something new. If they are going to invest in learning something new, why not Ruby, or Node.js, or something else?
Enter Backdrop CMS
What if we could go back in time to when we decided to attract that higher tier of developer, and make a different decision. What if we decided to cater to the existing Drupal community, instead?
Let's look instead at what people found hard about moving to Drupal 7, and make those areas make more sense. Let's leave the rest of the existing Drupal 7 APIs alone (if it ain't broke, don't fix it) and see if we can add the new features people want on top of the architecture they already know (and love!) Let's make it easy to port contrib modules and themes from Drupal 7, and encourage our developer community to focus on delivering new features, rather than re-learn everything they used to know to make an administration page for their module (for example).
Would this kind of direction prevent a Drupal Colony Collapse? As it turns out - it might. Of the people I've spoken to (the ones with exit strategies) they all sound not only interested in a CMS that more closely resembles Drupal 7, but have offered to contribute (even though some of them have never even contributed to Drupal before).
I love the current community: masters, hackers & newbies too
Drupal 8 might be going after a higher tier of developer, but I think we should be focused on the community we have right now. I love that we have self-taught masters of Drupal as core-committers, Drupal trainers, professional Drupal developers, and all the way down the chain. What bothers me, is that so many people are thinking of leaving Drupal - because they fear that Drupal 8 will leave them behind.
I'm worried that the "hackers" may no longer find Drupal approachable, and we may not get many more self-taught Drupal experts moving up the chain. Walking in the door at Drupal 8 is going to be exponentially harder for these people than Drupal 7 was - and we know how much people struggled with that.
I want to catch those groups of people. I want to tell the developers not to leave, tell them that we still have a place for them. I want to catch the hackers, give them a light-weight CMS where they can pop the hood and tinker freely. I want to provide a place where they all can continue to crank out awesome websites that meet their needs, the needs of their clients, and the needs of the causes they believe in.
How can a fork be good for Drupal?
This thing we're doing, it's a big deal. And some people believe it will be bad for Drupal. I, personally, disagree. I still love Drupal, and I think a fork can be a healthy thing for a software project. Here are some of the reasons I think Backdrop CMS can help Drupal and the Drupal community:
- Almost all ideas for Backdrop improvements can be shared with Drupal
Though it's unlikely that much of the code developed for Backdrop can be directly applied to Drupal 8, most of the ideas will be 100% transferable. There are already issues in both queues referencing what the other is doing.
- A stepping-stone for developers who may otherwise consider leaving the Drupal community
There may be people who are afraid to learn Drupal 8 when it's released, but who aren't afraid to move to Backdrop. If these people use Backdrop for a year or two, and then later feel confident enough to move on to use Drupal 8 in the future, we've kept them in our community.
- A lightweight product for low-budget sites that may otherwise consider adopting other platforms
There may be projects that can't afford a Drupal 8 developer, or can't find someone to port contrib modules to Drupal 8 in their time frame or within their budget. Backdrop maybe a suitable alternative for these projects because modules can be ported more quickly from Drupal 7, and developers already familiar with Drupal 7 will be able to use it right away.
- A safe place to try new things (pull requests, semantic versioning, large team of core committers)
Since Backdrop is not Drupal, we'll have the the freedom to do things differently. The Drupal community can watch what we do, and see how it goes.
- We can learn from each other's successes & failures
Along the same lines as the above, if the new things we try fail miserably, the Drupal community will know not to try them. And if they succeed, they Drupal community may want to give them a try. Likewise, Backdrop has already learned a lot from Drupal, and we'll continue learning.
- Competition drives progress
Even since the announcement of Backdrop CMS, Drupal as made huge strides in improving the developer experience. Even if this project fails, I believe that Drupal software will be better off for it.
But, what about the Twig "initiative" for Drupal 8?
Don't worry, the Twig initiative is in good hands. We have a really great team working on Twig and the new Drupal 8 theme layer. Mark Carver has offered to step up and run our weekly Twig meetings, and be the general overseer of all things in the Twig initiative.
Yes, I have decided to step down as the Initiative lead for Twig in Drupal 8, but only because I didn't want there to be any conflicts-of-interest (real or perceived). My motive has always, and will continue to be, the same: I want Drupal to be easier to learn. Twig and the Drupal 8 theme system cleanup helps move Drupal 8 closer towards this goal for front-end developers, and I still believe strongly that it needs to succeed. There is still a lot of work to do, so I will still be participating in meetings, and sprints. I'll be present in the issue queue, and in IRC. I'm fully supportive of all the work that is still going on in this area.
There are a lot of really great people working on a lot of really great things in Drupal 8. None of that should be understated. I still deeply respect all the people involved in Drupal 8 development, and no one can discount the thousands of hours that went into improvments. I also believe that Drupal 8 will be successful.
Backdrop is just another Drupal-like product. When Backdrop is released, we will have another Open Source product in the CMS landscape. When the time comes that I have a new project that needs a CMS and Backdrop is a viable option, I'll choose the right tool for the job.
I'll still be working with (and contributing to) Drupal until then.
I want to hear from you
Before today I hadn't turned on comments on my personal blog. I'm turning them on now, for this post. Please share your thoughts below, and if you have any questions or concerns, please feel free to voice them here. I'll try my best to respond in a timely manner. (I know that emotions are high right now, but keep in mind that we are all working on something we care about greatly, and please be respectful in your comments.)