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.
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:
Feature-adding releases every four months.
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.
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
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.
Interested? Check out our takeaways from DrupalCon in the Big Easy, or see six reasons why WordPress is ready for the enterprise.Topics: Drupal, WordPress