Return to site

To Drupal or not to Drupal... maybe it's not okay when individuals or organizations leave the Drupal community.

· Drupal,Webform,Sustainability,Sponsoring

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.

So, maybe it’s not okay when individuals and organizations leave the Drupal community and leave behind projects that are not maintained.

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.

When someone stops contributing to an Open Source project, there are no exit interviews. This blog may serve as a forum at which I can conduct my exit interview.

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.

Role

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.

The role of maintaining the Webform module came with a lot of responsibility.

Responsibility

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."

My lack of "free" time led me to think and talk about the sustainability of my contribution to the Webform module and Drupal.

Sustainability

My "free" contribution was never going to be sustainable.

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.

The larger question remains not just for me individually but for us as a community: How do we make our contributions sustainable, and in turn, our software stable?

 

It’s a question that can’t remain unanswered for much longer.

Stability

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?

Can the Webform module live on without me? The answer is yes and no.

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.

Maintainability

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.

We continually need to make it easier for people and organizations to join and leave our community while ensuring that our software is stable, maintainable, sustainable, and improvable.

Improvability

"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.

Goodbye

So maybe this blog post won’t turn out to be the beginning of an exit interview.

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.

References

Related Blog Posts

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OK