As of late, I’ve been discussing the fact that my employer/organization is moving away from Drupal. I now face the decision "To Drupal or not to Drupal." I have decided to discuss this decision openly. In my previous blog post, To Drupal or not to Drupal… that is my mid-career crisis, I expressed the guilt I have about potentially not maintaining the Webform module and stepping away from the Drupal community. If the Webform module is unsupported, the Drupal community and organizations that need to create forms and collect submissions could suffer.

Generally, when people and organizations leave the Drupal community, they don't talk about it. Occasionally, there are snarky discussions involving assumptions on Reddit. As for me, I’m using my blog as a platform to have this discussion.

Before considering what my exit interview might entail, it would help to define my role and responsibility as the Webform module's maintainer in the Drupal community.

My initial contribution to Drupal began with the YAML Form module. I focused on building out the baseline functionality, reaching feature parity with the Webform module's previous version. As more people started using the YAML Form module, documentation and training material became essential. I created documentation using GitHub Pages. I recorded screencasts that walk-thru existing and new features. When the YAML Form module became the 8.x-5.x release of the Webform module, the usage stats started to increase significantly; I realized that maintaining this project required wrangling the issue queue and guiding users to additional help and resources. I also needed to provide training materials integrated into the Webform module's UI and help section.

At some point, when tens of thousands of websites reported using the Webform module for Drupal 8, my sense of responsibility increased. Governments and nonprofits, like the YMCA, rely on my code to register people for classes and activities. As such, they deserve some assurance that the code is reliable. This sense of responsibility and investment led me to write blog posts about my ideas and respond to people's bug reports, requests, patches, and suggestions in the Webform issue queue. Along the way, I realized that it is equally important to ensure that the Webform module is accessible. Finally, everyone wants to know that their forms and submissions are secure.

Writing and talking about the project has proved to be my best way to ensure that people are comfortable with the Webform module. Prior to maintaining the Webform module, I never talked or wrote about my code. Deciding to face my lifelong battle with stage fright when it comes to public speaking, I managed to present at dozens of meetups, camps, and conferences. My engagement with different people in the Drupal community inspired me to take on other challenges, including caring about the accessibility and the sustainability of the Webform module. With each encounter/exchange, I gained confidence and received invaluable feedback, which in turn led to a greater understanding of what I needed to do and what our community needed from me

In the Drupal community, making sure our code is secure is an ongoing challenge, with many discussions only made publicly available as a Drupal security advisory (SA). I found addressing security issues for just one module very challenging and an essential part of my role as a project maintainer. I tip my hat to Drupal's security team for the ongoing work ensuring all our websites and applications are safe. Even if I have no "free" time available to maintain the Webform module, I will always feel obligated to address security issues.

Over the past five years, I have started using the phrase "free" time to explain why I can't help people solve a particular issue around custom code or custom project requirements. I say, "Sorry, but I don't have the 'free' time to help you."

While contributing to an open-source project in my "free" time means I am not compensated for my contribution, the upside is I get to decide what I contribute and the quality of my contribution. Simply put, the Webform module is the highest quality code I have written in my career because I set the project's coding standard and timeline. I put five years of sweat equity into the project. Gradually I came to realize that my unpaid commitments and efforts are not sustainable. In an effort to circumvent this inevitable conclusion, I’ve experimented with sponsored features and paid support and even set up an Open Collective. Thus far (and this could change), I am a passionate programmer and not a business owner or a salesperson. The latter makes great software, and the former figures out how to make money from the great software. As an individual developer, I’ve yet to see how to make my contribution sustainable.

Sustainability means that our code and community is stable and maintainable. When someone leaves the community, we have to ask the question, "How can the Drupal community maintain that individual's or organization's contribution?". Keep in mind contributions come in all shapes and sizes, and it is not always code-based. For example, individuals and organizations organize and sponsor events. If they leave, can the event go on without them?

The most immediate reason I say “yes” is because the Webform module has a lot of test coverage, which ensures stability as the code evolves. I also have to say “no” because the Webform module is a massive codebase, which could become hard to maintain.

It is difficult to admit, but the Webform module's feature richness has created a maintainability challenge. I did not architect most form and submission features, including submission limits, using Drupal's modular plugin system. I did use Drupal's plugin system for several key aspects of the Webform module. For example, webform elements are entirely plugin-based, resulting in relatively well-encapsulated code that is easy to tweak, test, and maintain.

At some point, I missed the opportunity to refactor most of the Webform features into plugins. Every feature has test coverage, making it easier to refactor the code, but I don't have the "free" time to do this work. Code refactoring is not something most organizations and clients can justify sponsoring.

My leaving the Drupal community could create a big hiccup due to the size of my contribution and the fact that Webform is one of Drupal's most installed modules. Reviewing my situation, I’ve realized that we should think more about the maintainability of our top 50 - 100 contrib modules and themes. We may need to change the norm that one or, luckily, two developers actively maintain a contributed module. Like the Webform module, a few popular modules serve a particular business requirement for websites that install them. If these modules were not maintained, these websites would not be able to meet their business requirements.

"Improvable" is not a word I have thought much about while building and maintaining the Webform module. As I write this blog post, I see that "Improvability" is a useful trait for our software and community. Nothing is ever perfect, but we need to know we can make it better. Looking at the challenge of the initial painful migration to Drupal 8 followed by the successful iterative improvements we made to Drupal, including API-first, media, and layouts, the Drupal community has successfully improved Drupal's improvability.

"Improvability" is not a term often used in software and community. It encompasses the traits needed to be stable, maintainable, sustainable, and improvable. If we can improve our process and software when individuals and organizations leave the community, we will continue to grow and be successful.

The fact that I am writing this blog post means I am conflicted on what to do. The fact that you are reading this blog post shows that we all collectively care about our community. I’m putting it here because it’s where I always come to ask questions, reflect, learn and listen - it’s been my forum for my entire Drupal journey. It’s my Drupal community. It’s your Drupal community. It’s our Drupal community.

I wish we could have these discussions in-person at DrupalCon. I'm comfortable enough to talk about them here, and I hope to have them face-to-face sometime soon. Professionally, something has to change for me. Being a Drupal community member, I know we are continuing to change and improve how we collaborate; together, we will grow from this experience.

Once again, thank you for listening. As always, I look forward and hope to hear from you.

While researching and thinking about this blog post, I found the below articles helpful in understanding the who, why, how, when, and where individuals and organizations contribute to the Drupal community.

• The Cultural Construction of Drupal | Matthew Tift
• Stay For The Community Revisited | Greg Dunlap
• What is Burnout? | Randy Fay
• What Can Individuals Do To Prevent Burnout? | Randy Fay 
• What can the Drupal Community do about Burnout?  | Randy Fay
• On not doing Drupal anymore | Steven Wittens
• On contributing to Drupal 8 | Damien McKenna 
• Open Source is awful | Larry Garfield

Here are a few of my related blog posts that you may enjoy reading.

• It is okay for you to plan an exit strategy, we should be okay with off-boarding contributors, and everyone says goodbye
• Drupal is frustrating
• Drupal is the worst Content Management System except for all those other solutions