I have been frustrated with Drupal 8 before (and I am often still is). I wanted to fork Drupal. Let me start with a few insurmountable problems, regardless of the specifics of the fork:

"80% of people use only 20% of the features" -- but they often use a different 20%. And Drupal contrib covers them all. One of the strengths of Drupal is every problem having a contrib module to answer it, big or small. It's near hopeless reaching this diversity in a fork.

Second, two words: Security team.

Third, usually -- and this is the case for Backdrop too -- these forks don't happen at the tip (because someone is unhappy with the tip) but somewhere in the past. What happens to the useful work that happened between the fork and the tip -- in case, say, the gigantic Field API to CMI conversion -- in the fork?

Drupal was created to process HTML forms and to spit out HTML pages. This default is baked very very deep into Drupal 7. The current world has a lot more kinds of inputs and outputs and that needs complexity (ie REST). How much complexity is debatable but those simple days are gone. Drupal 8 is our answer because Drupal 7 missed this upheaval: the Apple App store launched in July 2008 and Drupal 7 was already under development and by September 2009, Drupal 7 was already code frozen. There were more than enough changes in D7 without trying to accomodate for the mobile world.

Finally, it missed a window. Yes, after the miscommunicated API freeze when the idea of Backdrop was raised I did consider just jumping ship but since Dries said we have work to do on the Drupal 8 developer experience... we'll work on Drupal 8 until it is ready I now believe we can make Drupal 8 a place that won't drove developers away. Yes, there will always be disagreement on the amount of complexity (I agree it's a bit over the top) but together surely we can make it good enough. It'll never be perfect. Looking back, if I try to be objective, which is hard, 'cos it's my baby too, Drupal was never perfect.

Commenting on this Story is closed.