Drupal 8

Community Ready!

socketwench.github.io/drupal8CommunityReady

So you might be wondering who is this weird person in front of you. And yes, I do make that face when I get to go on a business trip.

My name is Tess Flynn, otherwise known as socketwench.

That's wench, not wrench.

I'm the module maintainer for Flag, Flag Friend, and Examples.

And I work as a Drupal Developer for FFW, the largest Drupal consultancy in the world. Just in case you're looking for work, we're hiring. Hit me up after the session.

Drupal at a Crossroads

In many ways, Drupal today is at a kind of crossroads. There's been a lot of speculation, hope, excitement, even a little fear. Developers and businesses alike have a lot to be both concerned, and excited about.

Huge Changes

In code and process

There's been some huge changes with over the last several years. Critics have called Drupal 8 a completely different CMS from the previous version. While intimidating, there were many changes we needed for Drupal to be ready for the now and the future.

Gigantic Dev Cycle

4 years!

There's also been a gigantic development cycle for this version, longer than any other we've done in the history of the project. Four years! That's an eternity in the tech world.

"When it's Ready"

Led to speculation, worry

We also had the nagging problem that we never really knew when Drupal 8 was going to be released. We said, "When it's ready". This created a lot of speculation and even worry that Drupal would never get out the door.

Community Shakeup

Long time devs left or reduced involvement

We've also had some long time developers leave the project, or reduce their involvement. From an outsider perspective it's hard to read this in an alarming way, forgetting about the many new developers that have joined the project recently and had a big impact.

Forked!

Not the first, but highest profile

And let's not forget the big fork Drupal had recently. It wasn't the first, but it was certainly the highest profile.

But let me tell you a different story...

Let's go back to 2012

Drupal 8 had just gotten started

And I was sitting in an auditorium...

...listening to Larry Garfield give a talk an "Musical CMS: How Symfony is coming to Drupal".

And what I was hearing was really, really exciting.

This was my second Drupal camp. I actually had given a talk just the previous day on how does Drupal 7 work.

See, for year's I had used Drupal for my own site, but I never really developed any code for it, nor peaked inside core.

I decided to change that. I set up a debugger and stepped through the entire Drupal 7 init process.

And that's when I discovered something kinda surprising.

...even a little unsettling.

Drupal 7 is weird

The thing is, Drupal 7 is really, really weird.

Anachronisms

Straight functions (mostly)

PHP4's OOP was odd & incomplete

Drupal 7 is, to me, full of anachronisms. It's composed of straight functions -- mostly. There isn't anything wrong with that, it only feels...well...old fashioned. It was also justified in Drupal's case as PHP 4's OOP support was odd and incomplete.

Hooks are API Go-Fish

The thing that really bothered me was hooks, hooks are like API Go-fish. I had been coding for over a decade at that point. I've been through 4 years of college, worked in multiple languages and products, and I had never saw anything like hooks. Drupal 7, in essence, asks each module "Do you have a something-hook?" and if it does, it executes it. I just couldn't believe the project I had come to love the last few years works like that. I was dumbfounded.

Arrays of Doom!

Undocumentable Monstrosities

Lack of a language feature patched with human effort.

With the exception of the database layer, there were huge arrays of doom everywhere in Drupal. Either you needed to create them in your code, or work with huge, undocumentable monstrosities that you needed to run through a debugger first BEFORE writing your code. WTH!?

Tech Wasn't our Biggest Problem

We liked our own code...

...a little too much.

Not-Invented-Here (NIH)

Prefer in-community solutions despite costs.

PHP 4 Didn't Help

Dependencies were copy-paste.

Required manual effort to build, update.

NIH has a social cost

Sunk-cost Fallacy

"Point of no return" thinking

Haven't heard of the Sunk-cost Fallacy? It's an idea from behavioral economics that suggests once we've invested a certain amount of utility in something, we pass a point of "no return" where we're obligated to stick with it even when we know the problems.

Sunk Costs in Software

Makes replacement of large subsystems impossible

Usually this refers to cars, houses, movie or concert tickets, but it works in software design as well!

Sunk Costs in Drupal 7

PHPTemplate vs. Smarty, etc.

Simpletest vs. PHPUnit

Many others...

NIH made Drupal Insular

We rarely worked "upstream".

After discovering all of this, I was really discouraged. The coding techniques I had been familiar with for years just didn't apply to Drupal.

It all seemed too strange, too weird, and too impenetrable for me to even seriously consider writing a module or contributing to core.

I <3 Drupal

Just don't tell me how you work.

I really, really love you Drupal, but please, don't tell me how you work.

The thing was, I had assumed I was alone. That no one else had this bizarre perspective on our beloved CMS. That is, until I was sitting in that auditorium listening to Crell talk about putting Symfony in Drupal. And then I got really, really excited.

Four Years Later...

What Makes Drupal 8

"Community Ready"?

Technology is enabler for people!

So, who did we enable with Drupal 8?

Drupal Developers' Delight

Patching and Hacking

Hacking Core

Isn't just about patching files

Runtime Patching

Adds CPU, memory, debugging overhead

Services in Drupal 8

Enable best-practice runtime patching.

Dependency...

Heaven?

Composer

De facto PHP dependency manager

No more* copy paste!

Vendor projects removed from Drupal repos

*Soon, expected in Drupal 8.1.

Coreless Site Repos

Build your entire site using just composer.

No more Drupal Core in your site repo.

What about Non-Drupal Developers?

OOP Everywhere!

PHP 5 fully implemented OOP

The first thing was that we finally started using object-oriented programming. PHP 5 brought a full OOP features that we could finally leverage in Drupal.

More than just Objects

Functional Pain

Groups of API functions not related at language level.

Requires more training!

OOP Groups Functionality

At the language level.

D8 Class Library

Create more functionality...

...with less copy & paste.

Reduced "Drupalisms"

Lowers barriers for developers to use Drupal.

Provides a familiar environment to learn new skills.

The Web Changed

Drupal 7 was also built with the assumption of the desktop web at its core. When a request comes in, Drupal processes it, routes it to the appropriate handlers, and then returns HTML for display. With frameworks like React and mobile applications, the need to return HTML has gotten smaller and smaller.

No longer just HTML

Many endpoints only need content, not an HTML page.

Decoupled, Mobile, and Native Apps.

D7 was a poor REST Sever

Discouraged use of Drupal 7 as a backend.

Load Just The Things

Web services + progressive decoupling

Ready for decoupled front-end, mobile, and native apps.

Site Building Joy

Closing the Adoption Gap

Missing Functionality

Core alone was never enough in D7

Key contrib modules needed to make a complete site

Batteries Included

More Field Types

* Contrib in Drupal 7

Reference Field Types

Enable composite content.

Views In Core

Finally!

No more waiting to build a real site.

Views Dogfooding

Many core-provided pages are views!

Customize user and admin facing pages.

Config Management

CMI = Features in Core

Preserve configurations to files

Themer Happiness

PHPTemplate

Raw PHP in a theme is a bad idea!

Complicated syntax, security nightmare.

New Theme Engine

Twig means no more PHP!

Simplified Theme Layer

More theme templates, less functions.

Business Owner Bliss

No more upgrades

6 to 7 Upgrades Hurt

Module incompatibility, past mistakes, no rollback.

Easier, more cost effective to build a new site.

Migrate in Core

Repeatable & customizable content migrations.

Cruftless

Old DB tables and config left behind

Supported from Drupal 6

Transfer content directly from 6 to 8.

Config Deployment

Easier to Update Prod

With core alone.

The Drop Picks Up Speed

Development Cycle Problems

Lengthy Dev Cycles Kill Momentum

And contributor interest.

Semantic Versioning

Predictable releases every ~6 months.

Long Term Support when next major version starts.

More than Just Good Feels

Lets contributors see the value of their work...

...before they forget.

How OSS Gets Updated

When we started working on Drupal 8, we didn't know how long it would take. We certainly didn't expect it to take as long as it did.

You'd like to imagine the conversation goes like this. We have a project manager, or the original author of the project.

And they say it's time to start working on the next version of the project. Everyone is excited is, of course.

When we start planning out what we want to work on in the next version, however...

...everybody has their own ideas.

This is actually good for open source. Often we really do need many if not all of those changes and features, but implementing them all for the next version can take years.

Conflicting priorities

Easy/fun vs. Most Critical

Subsystem dependencies

There's lots of conflicting priorities when planning a new version of a piece of software. With a volunteer-run project like Drupal, it's easy to choose between what's easy and fun, vs. the most critical changes we need to make. There's also a lot of subsystem dependencies to consider when planning a major update. As replacing or updating one subsystem may require a

Technical Debt

"I don't have the time to do it the right way."

Shortcuts, brute force, and "temporary" workarounds.

So it's really tempting to think with all these needed changes, that we do it all! But instead of doing a huge release cycle, we'll break it up to several releases so it's easier to manage.

Incremental Updates

Define an endpoint several releases away.

Focus on one big change per release.

Mirror Universe

Great in Theory

More focused changes, less "too many cooks"

This is great in theory, since it allows developers to focus a few changes at a time, and avoid the problem of having "too many cooks" each with conflicting priorities and agendas.

Less Perceived Work

Easier for volunteer core devs to maintain momentum

The biggest advantage is that the perceived amount of work would be less for incremental changes rather than a huge, big-bang change. This makes it easier to maintain momentum for a core developement team made up of mostly volunteers.

Easier for Contrib Devs

A focused change takes less time to update modules

Focused changes is also easier for contrib developers as it takes less time to update modules to the new version.

Incremental's advantage?

It limits cultural shock.

Fewer changes make it easier to accept.

This all sounds great, but what's the real advantage of incremental updates? Incremental updates limit cultural shock. Big changes are easier to accept in smaller pieces.

So, why didn't we do that?

So...ummm, why didn't we do that?

Drupal 8 was a "Big Bang" Change

All changes in one version jump

Drupal 8 was a Big Bang change. We had all the changes, new features, and everything in one version jump.

Big Bang is Organic

The thing with Big Bang changes is that they're organic.

Let me explain what I mean. Imagine your software is like a house.

And let's say you're planning an addition to your house.

Now you can just plug in a addition, you need to take out the walls and do some demolition first.

As often happens during a remodeling, you start finding other things that you need to fix. And since the walls are out anyways, there isn't a better time to fix those problems.

Feature Creep

It's not just for new features...

...but for fixing things that were unplanned.

This is feature creep. It doesn't just mean adding new features, but also fixing other things we weren't planning to fix before. This happened a lot in Drupal 8. We started out with a few changes and soon we were replacing every little thing because, if we didn't fix it now, when would we?

Often requires a Tyrant

Or, at least someone that can say "No".

The problem is that to make incremental changes work you often need a tyrant.

'No' isn't the same in OSS

It discourages volunteers instead.

"Make it happen"

Doesn't encourage unpaid contributors

...they leave instead.

Drupal isn't an iPhone

And we're not working for Apple.

Big Bang is Exciting

Maybe not for existing developers...

But it has the effect of creating new interest!

It'll Just Hurt...Differently

Work is not really reduced

...only the perception of the amount.

Incrementally updating a large software project like Drupal is difficult in practice. Work isn't really really reduced, only the perception of how much work there is.

How's this sound?

Rewrite your modules...

...every 6 months...for 4 years?

Incremental can be Exhausting

Both for core developers...

...and contrib developers.

Band-aid Problem