My pickle of a problem
Previously, I have discussed my current work situation, which revolves around the fact that my organization is moving away from Drupal. This situation has led me to ask the question to Drupal or not to Drupal. To date, I’m committed to helping them migrate from Drupal to Sitecore.
I’ve also decided to remain committed to the sustainability of the Webform module. The “sustainability” of the Webform module has different meanings to different people and organizations within the Drupal community. Individuals want to know that there are resources available to provide guidance, review patches, and commit code to a project. An organization using Drupal and the Webform module wants to know that the code is stable, maintained, and secure. For me, I’d like to see compensation for my time in return for my continued commitment to the sustainability of the Webform module.
And that’s where it gets tricky. Who should do the compensating and how much? What’s the worth and to whom?
Being compensated to contribute and maintain code within an open source project can take on many forms. An organization could sponsor my work on the Webform module. At the same time, these opportunities are rare within our community. Frankly, assuming that a single organization could take on the responsibility of something like the Webform module might not be financially feasible.
My pickle of a problem is that I need to be compensated for my time to continue maintaining the Webform module.
Stepping back from my problem, there might be a more general solution for improving the Webform module’s sustainability. Still, sustainability is a pickle of a problem for an open source project like the Webform module.
The Webform module’s pickle of a problem
The pickle of a problem around the Webform module, Drupal, and Open Source is that people assume that everything is free. Open source code is free to use and distribute. The ecosystem built around the Webform module reinforces the notion that everything is free because we rarely put a “price tag” next to our contributions. The Drupal community is focused and committed to collaborating and building great software. I value this collaboration, so I wrote a blog post stating that I am against paid modules but for paid contributors and profitable organizations.
In that blog post, I acknowledge the giant sale funnels our “free collaboration” has created with our modules, themes, and projects providing a massive opportunity for awareness at the top of the funnel.
The Webform module is one of Drupal’s top modules, and it is included in one out of every four Drupal websites. Another way to look at this stat is 1 out of every 4 Drupal-related pitches, proposals, or project specification includes the Webform module. The success of those websites, the success of those projects all depend on the Webform module. So one has to ask: what’s the worth of ensuring that those websites and projects are up, running, and succeeding? My contributions have to be viewed as an integral part of that development, maintenance, and success.
To make the Webform module sustainable, we need to transform the Webform module’s perception from free software into a viable, necessary collaboration that requires involvement and financial support.
The challenge of sustainability
Someone in the community conjectured that the ideal way to make my work on the Webform module sustainable is for all Webform-related work and enhancements to be directed and funneled to the project maintainer. Yep, this could solve the problem, but our community is not set up this way.
Most Drupal agencies take on Webform-related projects, and they may contribute something back to the community as a patch or a Webform add-on. Some agencies contribute nothing back and are leveraging the collaborative power of open source for their clients. The challenge of sustainability is mostly due to the organizations that are takers and not makers.
Companies, from technology startups to technology giants, monetize Open Source projects without contributing back to those projects. Let's call them Takers.
As the name implies, Makers help make Open Source projects; from investing in code, to helping with marketing, growing the community of contributors, and much more.
You should read Dries’ blog post. For this discussion, the challenge is about balancing makers and takers and open source software freedom.
Balancing the freedom of open source software with sustainable contributions and paid support
I think the sustainability of the Webform module comes down to three goals:
- Encourage individuals and organizations to get involved.
- Encourage individuals and organizations to financially support the ongoing development.
- Provide paid support that helps the consumers and builders of the Webform module succeed.
None of these goals is anything new, and different implementations have created sustainable open source projects. For example, WordPress has successfully built its ecosystem of add-ons around paid support, and it works for their community. Simultaneously, the WordPress community has walled gardens around their add-ons where collaboration, interoperability, and reusability are significant problems within WordPress.
Drupal has the opposite of WordPress' problem where our openness and collaboration make it difficult for module maintainers to be directly and reasonably compensated. To successfully make my work on the Webform sustainable, I will have to address each goal directly and thoughtfully.
Getting people involved and contributing
Getting people involved is one of the foundations of the Drupal community and our collaboration. We encourage everyone to get involved on Drupal.org and at our events and conferences.
I want to continue to encourage everyone to get involved. Minimally, I want to nudge them to think about contributing. The most direct nudge would be open to prioritizing tickets created by people who contribute to the community.
As more people contribute to a project, it becomes imperative that a maintainer orchestrates tickets and pull requests.
Orchestrating tickets and pull requests in the Webform module's issue queue requires an ongoing effort by me, the project's maintainer. I need my commitment and effort to be sustainable.
Collecting funds to sustain development
As of now, the Webform module’s Open Collective funds allow for about 4 hours of sponsored development each month, covering ticket triage, critical bug fixes, and quarterly code releases. The funds might be just enough to minimally maintain the Webform module.
Minimally maintainable is probably not enough to keep the Webform module at an acceptable status quo. For the Webform module to grow, I need to explore creating a more substantial income source.
Offering paid support for the Webform module
Offering paid support services around Drupal is nothing new, and it is what motivates organizations to be listed in Drupal’s marketplace by earning commit credits. Drupal’s marketplace is an important part of our community’s sales funnel. A project’s landing page is part of an organization’s decision process to Drupal or not to Drupal. The Webform module’s project page is the best opportunity to make my ongoing work on the Webform module sustainable. The value proposition that I am offering is to help ensure an organization’s “Webform” success by providing paid support.
The most immediate value of paid support around the Webform module is the fact that I am the subject matter expert (SME). I can consult, review, and provide guidance for any enterprise custom or critical implementation of the Webform module. Many organizations are building event registration and application evaluation systems using webforms. During the pandemic, Webforms have even helped with financial oversight and relief requests.
Paid support for organizations
I see two angles for how to promote the benefits of paid support for the Webform module. The first angle involves organizations using Drupal and Webform. These organizations will want to know that their projects will be successful. Small organizations could engage with me for support directly. Large organizations on the other hand, especially government projects, can’t easily pay an individual developer to do work, which is why they hire a Drupal vendor/agency. I think there may be potential for organizations thinking about using Webforms to nudge their vendors to hire the subject matter expert to ensure their project’s success. This leads to the second angle for paid support, which involves ensuring a Drupal vendor is successful.
Paid support for agencies and vendors
The second angle for paid support involves agencies and vendors paying for my expertise to ensure their client projects’ success before and after the contract is signed. Most organizations who choose Drupal have some understanding of the benefits and challenges of open source software. Within a “Response to a proposal,” an agency could augment their expertise by stating that they have direct access to the Webform module’s creator and maintainer.
An approach to getting involved and support options: Pitch, nudge, and acknowledgment
My “getting involved and support options” pitch offers options that encourage getting involved, funding development, and paying for professional support.
This pitch needs to make people aware of the Webform module’s support options, and this awareness begins on the Webform module’s project page. I feel the most direct callout on the Webform module’s project page is to display a “Get involved and support options” triptych with individual panes for getting involved, funding development, and paying for professional support. Along with the “Get involved and support options” triptych, the Webform module’s project page should align more with the competitors and highlight features and add-ons. To continually nudge people, the “Get involved and support options” triptych should also appear in the Webform UI on the Add-ons and Help pages.
Nudging is going to be an essential part of the process.
Currently, I nudge people in the Webform module’s issue queue to the most appropriate support channels. Initially, I expected to leverage a lot more nudges in the issue queue. My experience is to keep the nudge as direct and straightforward as possible. I think the “Get involved and support options” triptych could appear when users create new tickets. If there are not enough funds in the Open Collective to pay me for my time, I will have to be transparent about this limitation. I will also throttle my commitment to the Webform issue queue based on the estimated annual budget of the Webform module.
Finally, we need to acknowledge individuals and organizations who help support the Webform module.
Drupal.org does a good job of tracking and acknowledging individual and organization contributions using the commit credit system. Open Collective tracks and displays all backers. At some point, major backers should be listed on the Webform module’s project page. Right now, only active maintainer’s employers are listed. Additionally, I will track tickets and tasks sponsored by the Webform module’s Open Collective.
For now, this is probably enough to start a discussion and move forward. I can follow up in the Webform issue queue with the Webform module’s project page and UI changes.
I am not asking for permission or forgiveness because I feel this is the most viable option for making the Webform module sustainable.
This is a long blog post that addresses the Webform module’s pickle of a sustainability and maintainability problem. My concern involves needing to be compensated so that I can continue to maintain the Webform module and support the Drupal community. In the large Drupal community and the Webform module, we need to figure out how to get people involved and help fund development.
It’s usually good to end a blog post by asking a few questions to encourage people to post comments. Right now, I feel the need to focus on moving forward with asking this question: How can we make the Webform module more sustainable? My answer is to ask people to get involved, fund development, and pay for professional support. Do you agree or disagree?
Throughout writing these “To Drupal or not Drupal…” blog posts, I like reread import posts in the Drupal community. Matt Tift does a great job chronicling the history of paid modules and why paid Drupal modules fail? And my answer is this: Funding development and paid support for Drupal modules could succeed; at the very least, it is worth trying.