In this podcast, Kent Bye talks with Jeff Eaton and a couple of the top Drupal core contributors from Drupal 7, Daniel “sun” Kudwien and Nathaniel “catch” Catchpole. They discuss the maintainability of Drupal core, a retrospective of the ups and downs of the Drupal 7 development cycle, and alternate roadmaps for the future of Drupal core. Developer burnout is also becoming more of an issue, and they talk about the importance of recruiting more “code gardeners” to help review and evaluate core patches. Listen in for a wide-ranging and engaging discussion about the Drupal project and the concerns some of the core contributors are wrestling with today.
At the beginning of DrupalCon London, one of the top Drupal core developers named Daniel Kudwien (aka ““sun”) posted a blog called “The Drupal Crisis” about the woes of the Drupal 7 development cycle. He claimed that “Drupal core is not maintainable anymore. There’s too much cruft. Too many half-baked features that no one actually maintains.” and that “We need to be a solid framework, and also a basic but extensible CMS, like we’ve always been.”
After lots of discussion on this post, Sun wrote a follow-up blog post with a number of conclusions including “We need to discuss, propose, agree, and define what we are able and want to maintain in Drupal core,” “which core features are actually product features,” and “whether we can or want to move product features into a separate product project in the long-term.”
Channelling this interest into action, sun created a number of different issues within the drupal.org issue queue including this list of Discussion items and this “Make core maintainable” issue, which generated nearly 300 comments.
The “Make core maintainable” issue quickly turned into a discussion of which modules to remove from Drupal 8 core, and the question of what should stay and what should go led some core developers like Crell, eaton and catch to call for a more defined set of heuristics that the Drupal core maintainers could use in determining what should be included within the Drupal core product.
This discussion eventually led Jeff Eaton to create a spin-off issue called “Establish heuristics for core feature evaluation” that tries to lay out a list of criteria for evaluating which features should stay and what modules should go.
Asking what modules belong in core and which ones should be removed can be answered differently depending on whether you see Drupal as a primarily as a generalized CMS product or whether you see it as a development framework for a specific site. It’s actually both a framework and a CMS product, but this tension has brought the Drupal project to a crossroads when trying to make these types of decisions of what to include in the main project and what core developers are responsible for maintaining.
Eaton talked more about this tension between product and framework at DrupalCon London in his presentation called “Product, Framework, or Platform?” Instead of creating a false dichotomy between the Product vs. Framework, eaton is using the term of “Platform” in order to incorporate both the CMS product and anything else that can be created with the module system and development framework.
Another top core developer Nathaniel Catchpole (aka catch) wrote up a couple of related blog posts including “Why all the drama?”, where he does a bit of a retrospective as to what went wrong with the D7 development cycle from his perspective.
Catch also took a stab at expanding on the Drupal Framework vs. Product debate in another blog post called “Framework, Platform, Application, Features, Product, Workload” where he reiterates that Drupal is a hybrid of the two. He lays out a more nuanced and complicated 5-layered system for how he thinks of it, which is mentioned in this podcast a couple of times.
At the bottom of his post, catch points to a number of follow-up and related initiatives. Catch and sun created the “Unofficial Drupal 8 Framework initiative” that includes a lot of the low-level API clean-up.
In this podcast, catch and sun talk about the need to simplify and de-couple the system.module’s responsibilities in order to do unit testing and make core debugging more manageable. Here’s a list of issues tagged as part of this framework initiative.
There’s also a number of issues tagged with the Platform Initiative, which is centering around the heuristics for which features should be in Drupal core, and which ones should be removed.
Another related project is eaton’s Snowman initiative in order to create a number of installation profiles that give users a more options for what flavor of Drupal product that they’d like to use. There’s also a meta issue from eaton “[meta] More flexibility for core installation profiles.”
A related topic throughout all these discussions has been burnout of core developers. Randy Fay held Core Conversation about Burnout at DrupalCon London that is well worth watching. Fay also looked into a lot of research into burnout, and wrote an excellent series of blog posts:
What is burnout?
What can Individuals do to prevent burnout?
How does the Drupal community burn people out?
What can the Drupal community do about burnout?
In his Drupal Crisis post, sun says that “there are many more Drupal contributors who kept silent about their personal feelings for too long. In the end, we have several critical communication problems about fundamental topics in our community.” This has been contributing to the feeling of burnout.
One solution to core burnout is to recruit more help for the core development workload. Sun and catch talk about the need in the Drupal core development community to recruit and mentor more people who “code gardeners” can test and evaluate patches.
Other related links
ArianeK’s reflections on the burnout issue from the documentation perspective
A g.d.o thread summary about Acquia’s influence on core development catalyzed by sun’s Drupal Crisis post.
Drupal Learning Curve Comic
sun’s Drupal learning curve
Brought to you by the Do It with Drupal Conference October 12-14th, 2011 in New York City.
September 16, 2011 – 12:29am
85:25 minutes (48.92 MB)
mono 44kHz 80Kbps (cbr)