Lessons from WordPress Core

At DrupalCon New Orleans this month, my co-worker Andrew Taylor and I presented Lessons from WordPress Core.

We focused primarily on similarities in how core development is planned and executed, rather than on the substance of the code itself. In the post-Drupal 8.0.0 world, new features are released in core every six months. 8.1.0 came out on April 20th and featured BigPipe. 8.2.0 is scheduled for October 5th and will contain new features as well. Drupal 8 is the first major version in which major feature additions are happening in conjunction with the maintenance of backwards compatibility.

Community Structure

In our roles as Agency and Community Engineers, Andrew and I stay close to both the WordPress and Drupal communities. We saw this shift in Drupal organization and thought it looked very similar to what WordPress has done for years.

The WordPress community has:

• Multiple levels of authority and commit access to core.

• Feature-adding releases every four months.

  • Each cycle is led by a different “release lead” who acts as a technical project manager. This person has a bully pulpit to advocate for changes to be committed in the release, but cannot dictate which commits are made.

  • That cycle is broken down into five phases from planning to launch.

• Major features are added to WordPress Core through feature plugins. Teams form around new plugins to coordinate and track progress.

These teams, structures, and schedules look very similar to processes actively evolving in the Drupal community. Pre-Drupal 8.0.0, the concept of initiatives served as an organizing focus for teams of people working on Drupal core. Dries Buytaert’s opening keynote at DrupalCon New Orleans highlighted that the initiative concept is being refreshed. And the new initiative process looks a lot like what WordPress does in terms of separating out proposal, planning and execution stages. This more formalized process will help accomplish what was articulated in a blog post from Gábor Hojtsy in 2014. He emphasized that initiatives and their leaders “have responsibility to show the community there is a (1) shared goal, that (2) it is an achievable goal, and then (3) help people get there.”

Similar to the way WordPress has defined the role of “release lead” to be close to that of project manager, the Drupal community has renamed “Initiative Lead” to “Initiative Coordinator.” This terminology has even entered the Drupal community’s Governance project which defines roles related to core development. It is also a sign of community maturation that this governance document delineates among different roles with the team of core committers like Framework Managers, Product Managers, and Release Managers. Drupal can see from WordPress that more clearly defining the who / what / when / where / why of core development makes the work more successful.

Site Administration with JavaScript

Drupal can also learn from the Calypso project. Automattic, the dominant WordPress-focused company, funded the development of Calypso as an alternative administrative user interface. Calypso uses the WordPress.com API to feed administrative components written with React.js. The Drupal Community has seen a lot of similar discussion around using JavaScript frameworks for administrative tasks, including talks at DrupalCon. There are a few lessons that can be taken from Calypso for creating alternate administration in JavaScript:

• It is possible! A PHP CMS does not to rewrite itself completely to support a JavaScript UI.

• It can happen outside of Core. Calypso is a standalone project.

• Limited APIs limit reach. Some in the WordPress community would use Calypso were it not for the requirement of using WordPress.com’s API. A community-built API could have wider reach.

Backwards Compatibility and User Trust

The Drupal community’s jump to focusing on what would need to be rewritten to accommodate JavaScript administration highlights different attitudes on backwards compatibility. The WordPress community sees maintaining backwards compatibility as a huge driver of growth. Maintaining backwards compatibility means maintaining user trust which builds community. Dries articulated a different attitude back in a 2006 blog post: "I feel that preserving the ability to constantly innovate is of higher importance, at the present time at least, than preserving backward compatibility."

A willingness to rewrite significant portions of code allowed Drupal 8 to catch up with the Composer-based, Object Oriented world of modern PHP. That attitude has attracted many great developers and many great projects. However it is difficult, likely impossible, to know how many developers and projects were driven away from Drupal by regularly shaking the base on which sites are built. WordPress’ much larger market share gives Drupal a hint of what was given up and what could be ahead by keeping the focus on Drupal 8 longer.

Focusing the Team

Personally, I think the key lesson from WordPress is the huge upside to having a community with shared focus. 2016 will likely be the first full year where nearly all of the focus of the Drupal community stays on one major version, Drupal 8. Previously the community was split between core developers working on D8 while everyone else built and maintained sites in D6 and D7. We are just beginning to reap the benefits of having everyone focused in the same place. The initiatives, core committer roles and release schedule make that focus even clearer. WordPress shows that we can expect steady progress and improvements, especially for content authors, when all of the developers are working on the same version.