Drupal 8 Bets on Symfony: What Framework Adoption Signals

A platform decision that will not ship for at least a year deserves coverage now, because its consequences will land on planning calendars teams are already drafting.

Drupal 8, in active development with release still distant, has committed to a foundational change. Core components of the Symfony framework, one of the modern PHP world’s most respected projects, are being adopted into Drupal’s foundations. With them come the object-oriented patterns and practices of contemporary PHP.

The commits have been landing since last fall. The community debate has run through two DrupalCons. Project lead Dries Buytaert has made the direction explicit in his own writing.

This is, in our judgment, the most consequential architecture decision in the platform’s history. More so than anything in Drupal 7. It deserves a translation. What the bet means, what it will cost, and what an institution running Drupal should actually do about it, which is less than the anxiety suggests and more than nothing.

The bet, in plain terms

Drupal grew up building everything itself. Its routing, its database layer, its conventions. All homegrown, all bearing the accumulated decisions of a decade, all maintained by the Drupal community alone.

That self-sufficiency was rational when PHP’s wider ecosystem was weak. And PHP’s wider ecosystem was, for years, genuinely weak. It no longer is. The past few years have professionalized PHP dramatically. Modern frameworks like Symfony ship rigorously tested components. The community has converged on shared standards for how code works together. Dependency-management tooling now lets projects assemble from common parts the way mature ecosystems do.

Drupal 8’s bet is that riding this wave beats resisting it. Adopt Symfony’s components for the plumbing: routing, HTTP handling, and more. Keep Drupal’s genuine edge: the content modeling, the flexibility, the community’s domain expertise. And stop spending community energy maintaining home-built versions of solved problems.

What shared foundations buy, concretely. Better-tested plumbing, because Symfony’s components are exercised by thousands of projects beyond Drupal, and bugs found anywhere are fixed for everyone. A wider talent pool, because a PHP developer fluent in modern practice will read Drupal 8’s internals as familiar rather than arcane. That addresses the hiring bottleneck every Drupal shop, ours included, has felt for years. And an exit from not-invented-here maintenance, freeing the community’s finite attention for the layers where Drupal actually competes.

The strategic logic is the same one we praised when Drupal put jQuery in core five years ago, at much larger scale. Standing on shared shoulders beats rebuilding the shoulders.

The costs, stated as plainly

Bets have prices, and this one has two.

First, the retooling. Drupal’s existing developer base, thousands strong, learned a procedural, hook-driven style that Drupal 8’s object-oriented architecture will substantially replace. The community’s own debates have been candid about this, and so should we be. Some accomplished Drupal 7 developers will experience Drupal 8 as a new platform wearing a familiar name. And the contributed modules, the platform’s superpower, as we have said since 2006, must each be substantially rewritten. That takes seasons.

Second, the transition for site owners. The 7-to-8 move will be re-platforming, not an upgrade. We said the same about 6-to-7 and it was. The architectural distance this time is greater. Content migrates. Code does not, or not cheaply. Budget-holders should hear that now, in 2012, while it is a planning input rather than a surprise.

What to actually do, by situation

• Institutions on Drupal 7: nothing urgent, and that is a real answer. Drupal 7 is current, supported, and will remain so well past 8’s eventual release under the community’s support policy. Sites launched on 7 this year will live comfortable full lives. What changes is the long-range calendar. Pencil the eventual move as a project, with the platform-evaluation moment any re-platforming honestly reopens. And favor build practices now that ease later migration: clean content models, minimal hand-rolled custom code, configuration over cleverness. That advice was already ours. The future just raised its interest rate.

• Institutions on Drupal 6: your calendar is shorter, since 6’s support ends when 8 ships. The move to 7 remains the right move and should not wait for 8. The 7 ecosystem is mature now, and 8’s arrival plus stabilization is years away in practice.

• Developers and teams: the retooling is the career signal. Modern PHP practice, object-oriented patterns, and Symfony familiarity are now the direction of the largest CMS ecosystems, not just this one. Our own team’s professional development budget has been shifted accordingly this quarter. We would commend the same to every shop that expects to be building on this platform in three years.

The questions clients are actually asking, answered

The consolidated inbox, since the announcement has generated a predictable set.

‘Should we wait for 8 instead of building on 7 now?’ No, categorically. 8’s release is distant, and its stabilization more distant. A site built well on 7 this year will be mid-life, not obsolete, when the transition era arrives. Waiting for platforms is how organizations spend two years with the site they were trying to replace.

‘Does this change the WordPress-versus-Drupal calculus?’ Not today. The contested-middle worksheet from our platform coverage still governs on current capabilities. It adds a long-range consideration cutting both ways. Drupal 8 promises a more modern platform eventually, at the price of a transition. WordPress promises continuity, at the price of carrying older architecture longer. Neither is free. Both are honest.

‘What does this do to Drupal costs?’ In the transition years, expect upward pressure on Drupal 8 rates, since retooled developers will be scarce before they are plentiful. Expect a long, healthy tail for Drupal 7 skills too. Worth knowing when hiring or contracting.

‘Is Symfony itself a risk?’ The stewardship lens applies. A well-governed open project with a commercial sponsor and wide adoption, which is the healthy profile. Drupal is joining a commons, not boarding a vendor’s ship.

Reasonable questions, all with calm answers. That is the announcement’s actual character, despite the version number’s drama.

The wider pattern

Step back and this is part of a story bigger than Drupal. The web’s major platforms keep converging on shared, professionalized foundations. WordPress absorbed jQuery and is slowly modernizing its own internals. The enterprise platforms build on established frameworks. And now Drupal, the proudest of the self-built, is joining the commons.

The trend rewards exactly what our platform-selection criteria have always weighted. Ecosystems healthy enough to make hard modernization decisions. Governance capable of carrying them through community resistance. Communities large enough to survive the retooling. Drupal is exhibiting all three, in public. That is why this bet raises our long-term confidence in the platform even as it complicates the medium-term calendar.

The alternative, platforms that never modernize, fails slower and worse. Our files contain their case studies. We will cover Drupal 8 properly when there is software to cover. For now, the decision itself is the news, and the decision is sound. Plan the calendar. Trust the direction. Keep the custom code light. The usual advice, with a new deadline attached, eventually.