Drupal's Starshot initiative and its impact on my contributions… aligning the Webform module with Drupal CMS
My next two blog posts will examine my work on the Webform and Schema.org Blueprints modules regarding Drupal's Starshot initiative and its impact on my contribution to the community. The first post discusses how the Webform module aligns with Drupal CMS, and the second post will discuss how the Schema.org Blueprints module is adjacent to Drupal CMS.
Drupal Starshot
The Drupal Starshot initiative resulted in the creation of Drupal CMS.
"Drupal CMS is a package built on Drupal core, including refined common features from the contributed project ecosystem to create a great user experience out of the box."
In other words, Drupal CMS recommends contributed modules that solve standard requirements and challenges that Drupal Core does not immediately address. For example, the SmartDate module will be used within the Events Recipe instead of Drupal core's Date module.
The Contact form initiative includes the Webform module, which I rebuilt for Drupal 8 and have maintained for several years. Being part of the Drupal CMS ecosystem is an honor and responsibility, which comes at a time when my maintenance of the Webform module is waning.
Webform maintainership
At the end of the year, I think about the current and future state of the Webform module and my contributions to the Drupal community. My contribution milestones fall on Christmas Eve when I wrap up and tag releases for open-source projects that I have been tinkering with during the Fall. For example, the YAML Form module, a precursor to the Webform module, was created on December 25th, 2015. I have blogged extensively about my past contributions, and this post is about the present and future state of my contributions.
The Webform module is in an okay state, and I mean just OK. The Webform module extends Drupal's Form API. Drupal's Form API is overdue for a rewrite or refresh, a daunting task that could result in rethinking the Webform module's approach and architecture. Frankly, maintaining the Webform module's current architecture has become a daunting task.
Maintaining the Webform module is challenging due to its large user and code base. For nearly a decade, I have been working on providing a form builder to the Drupal community, with most of the work being done at a point in my career and personal life when I had "free time." Yes, "free time" is in quotes because no one's time is "free." Looking back at my blog posts, you'll see that engaging, writing, and speaking within the Drupal community was as valuable a contribution for me as writing code. Still, contributing considerable code to the Drupal community has made me think about the maintainability and stability of my projects.
Maintainability and stability
Creating and maintaining Drupal CMS is a vast and inspiring collaborative effort. Maintainability and stability will be a challenge that must be addressed by contributed modules and themes included in Drupal CMS. Here, I am discussing my challenge of maintaining the Webform module. But before I go further, I recognize that many people are helping me wrangle the issue queue and maintain the Webform module. I am incredibly grateful for their help.
The biggest challenge for modules, like Webform, included in Drupal CMS could be the "definition of done."
Definition of Done
Yes, there is a bad joke here: I'm kind of/sort of "done" with building and maintaining the Webform module. At the very least, I'm done spending hours adding new features to the module; developers should create new features as extensions and add-ons. I am not sure saying, "no new features should be added to the Webform module," is acceptable to some people in the Drupal community. Yet, I see a lot of value in having a module that solves a problem and stays focused on solving that problem. Pun intended; I appreciate that the Focal Point module stays focused on "allowing you to specify the portion of an image that is most important."
The Starshot initiative has given the Drupal community something to focus on, and this new focus has inspired many outstanding contributions. Some might be entirely unrelated to Drupal CMS. However, I can't help but recognize huge API improvements like converting procedural hooks to OOP, which are a byproduct of the Drupal community's focus and commitment to our software.
My contributions to the Drupal community are driven by problems and challenges I want to solve, also known as “scratching an itch.”
Scratching Itches
For the past ten years, the Webform module has itched me. I could be scratching at the Schema.org Blueprints module for the next decade. I am grateful that I found Drupal during my career and that I could contribute code and ideas.
At this point in my life, I wouldn't take on a challenge like the Webform module. Yet, having individual developers scratching itches has led to significant contributions to the Drupal community. At the same time, individual developers, including myself, can experience burnout or, in their professional and personal circumstances change.
Conversely, it is an ongoing challenge in open source to get organizations to contribute their fair share to the collective effort behind an open-source product like Drupal. Organizations don't look for scratch itches; they seek to build value for their consumers and shareholders. As an individual working for organizations, I have shown them the value of using and contributing to open source.
There may be an opportunity to harness the community's energy from Drupal CMS to continue improving individual and organizational contributions to our community. At the very least, Drupal CMS is making me examine my contributions to the community.
Takeaways
"The Webform is where it is and is what it is."
This statement is vague and open to interpretation. I built the Webform module at a specific time and place, and my work is winding down slowly. However, Drupal CMS has energized the community, and it may change the approach and maintenance of the contributed module ecosystem.
My next blog post will explore my work on the Schema.org Blueprints module. This module will likely never be included in Drupal CMS; instead, it will remain an adjacent approach to content models in Drupal.