I love the title of the above Paul Gauguin painting - it’s three questions make you think about the past, present, and future. The Drupal community continually asks these questions as well. Personally, I feel Drupal is bigger than me and I’ve been more interested in listening to the dialog around these questions than entering the discussion. For two years I listened to the discussion about porting Webform to Drupal 8 before taking any action. My action resulted in the starting of a new module named YAML Form, which became Webform. My journey to building and maintaining the Webform module has gradually led me to start entering the "Drupal discussion".

And now, I want to discuss the past, present, and future of the Webform module.

For the past 10 years, Nate Haug (quicksketch) and fellow maintainers have done an amazing job building and maintaining the Webform 3.x and 4.x branch for Drupal 6 & 7. The ecosystem that grew from the Webform module is extensive with about 100 add-on modules.

Ten years ago, in the early days of Form API and before the Entity API, the Webform module provided its own subsystem for building and managing forms and submissions. The Webform module for Drupal 7 has a half a million installs and is the number 10 most-installed Drupal module. Simply put, the Webform module for Drupal 7 does its job and does it well.

With Drupal 8 and "getting off the island", which resulted in massive API changes, the Webform module was left floating out on its own. Porting the Webform module to Drupal 8 became an impossible task. It’s kind of shocking that a module with 500,000 installs couldn’t get the momentum to be ported to Drupal 8. Porting the Webform module without funding or resources was a daunting problem, but I had a client that needed a form builder for Drupal 8. I found myself forced to approach the Webform module for Drupal 8 problem from a completely different angle.

My approach was to come up with an MVP (minimum viable product) form builder for Drupal 8. My solution was to only use Form API with no UI, which resulted in a YAML-based form builder, which I named YAML Form. During 2016, I worked on the YAML Form module and gradually reached relative feature parity with the Webform module, which lead to it becoming Webform 8.x-5.x.

Webform 8.x-5.x is still in beta and it may remain there for the foreseeable future. Every release still contains a half dozen new features with bug fixes and some occasional regressions. I am supporting beta-to-beta updates so that people can feel comfortable using the beta releases, while knowing that they are responsible for doing some review and testing when updating to a new beta release. As we get closer to a stable release of Webform 8.x-5.0, I’d like to share my vision and goals for the Webform module for Drupal 8

Beginning with YAML Form module, I am committed to the Developer Experience (DX) when working with the module's code and APIs. I am intensely committed to making it easy to code form elements by hand using YAML. Another aspect to being developer-friendly is to have well-defined APIs and design patterns. Most design patterns used in the Webform are taken directly for Drupal core. The Webform-to-Submission entity relationship pattern was copied directly from the Vocabulary-to-Term entity relationship pattern used in the Taxonomy module. Webform Handlers were copied from the Image module's Image Style plugin integration pattern. If Drupal core did not provide a comprehensible pattern, I looked at the Examples module. Although the Webform module has a large code base, it "stands on the shoulders of giants".

I decided to live, breathe, and eat form builders, so I looked at what was being done with the Drupal 7 version of the Webform module and what was happening in other communities and products. Online form building is a very competitive landscape, but I boiled down my form builder comparison criteria to features, integrations, support, and quality.

The form builder market’s competitiveness lies in its features. It is the number one thing that is marketed towards potential businesses and users and with good reason - features is the most tangible differentiator. Even though Drupal is Open-source (aka free-to-use), as a community we need to compete with closed source and SaS solutions. I concluded the Webform module must be rich with features and not assume someone will create a sub-module that provides a specific feature. I am continually and iteratively adding, improving, and refactoring the Webform module's feature set.

Below is my evaluation criteria for adding a new feature to the Webform module:

• Has a competitor implemented this feature?
  If the answer is yes, it usually hints that someone has done some research and concluded that this feature provides value.

• How hard is going to be to implement and maintain this feature?
  Ideally, every new feature gets a dedicated test form with automated tests, which ensures that it is easy to maintain.

• Does this feature start to address some other future requirement?
  The Webform module has a roadmap and getting Field API integration working properly is a monumental task. Certain features, like multiple value support slowly pushes the Webform module in the direction of being about the integrate with Field API.

• Does this feature get developers to start thinking about other possibilities?
  The JSON and YAML exporters are not commonly used, however I included these examples to inspire developers to extend and/or build custom exporter plugins.

• Will this feature by customizable?
  Customizability, I feel, is a core requirement for all Drupal modules. Everything and anything needs to be customizable in the Webform module. I even feel there needs to be mechanisms to turn off features and functionality. For example, every single external JS library and Front-end UX provided by the Webform module can be disabled.

• Should this feature live outside the Webform module in a dedicated contrib module?
  This criteria is exactly why data analytics is no longer included in the Webform module. Data analytics is a key feature that can done in various ways and it should be provided by dedicated contrib modules or a third-party service.

Integrations are definitely features, which focus on pushing and pulling data and functionality from internal and external systems. At the bottom of every Webform competitor's feature list is a long list of integrations with systems like MailChimp, SalesForce, Google Docs, etc.

Supporting integrations with third-party systems is key to Drupal core and the Webform module. Integrations is one of the Drupal community's secret powers - we are an army of developers working on this challenge and sharing our solutions.

Making it easier to integrate Webforms with internal and external systems led me to create the submission handler plugin system, which allows Webform submission data to be routed and integrated with any system.

Even though integrations are features, I have taken the completely opposite approach. I am avoiding implementing any specific integrations within the core Webform module. It is neither feasible nor sensible for me to maintain or manage this code. I know for the Webform module to succeed, I need the Drupal community to start providing and maintaining these integrations. Besides providing solid APIs and support for integrations, I decided to monitor integrations within the Webform module and on Drupal.org by creating and maintaining a list of Webform Add-ons.

Webform Add-ons is a curated list of Webform related projects, intended to make it easier for business owners and developers to understand the Webform module ecosystem. As this list grows, we can improve the UX and add new functionality such as filtering.

Support is key to successful software. Support requires interacting with end users, which builds confidence, while also getting feedback that can be used to improve the software. In my desire to see the Webform module succeed, I’m realizing that supporting this module is more challenging than writing the actual code.

Support is a very tricky concept when it comes to Open-source software because developers, including myself, tend to be more interested in building the software then supporting it. In the Drupal community, one cannot directly make money from Open-source software. Consequently, you are typically obligated and expected to provide free support.

I wake up super early - usually I get my best work done before 6 AM. Before my house wakes up and I become my kids’ private waffle chef, I make myself a private breakfast with a perfect lox omelette and a pot of fresh coffee. So one Sunday morning, I’m scrambling my eggs and my cell phone rings with a number I don’t recognize. Telemarketers don't usually make 6 AM calls on a Sunday morning, so I answer the call. It was a developer asking me Webform-related support questions. I don't know how to say "No", so I replaced my eggs with my laptop and proceeded to provide free on-call support for the Webform module. This somewhat bizarre interaction demonstrates how some people expect Open-source developers to provide free support. The reality is most Open-source developers are like me, and if someone asks for help, we are going to give it. Still, because Webform module is free to use, it does not mean my time is free. Support is a tangible and valuable commodity.

My passion for the Webform module leads to what I feel is the most important goal and competitive attribute to software, which is quality. I want the Webform module to be an all-around high-quality product and a top-notch user experience. Occasionally, in Open-source doing just good enough work is okay and actually reasonable because developers are working for free. I strongly feel that Open-source’s strength lies in community and collaboration. Communal effort means everyone contributes and everyone benefits. YAML Form started out as a specialized MVP solution, but gradually as I saw more people using it, I wanted to provide a complete and high-quality solution.

In my mind, any feature or concept that adds "quality" to the Webform module is worth doing. I have literally held nothing back from this project or the Drupal community. Any reasonable feature request will be implemented. The quality and level of documentation are of utmost priority - I continually work to improve them by providing screencasts and encouraging the community to build out a cookbook of useful recipes.

The only things that have held me back from improving the Webform module are time and resources - they are the only real challenges to maintaining the Webform module and I see it impacting the future of this project.

The Webform module was, and still is, a specialized solution for building forms that collect data, compared to Drupal's Entity and Field API, which is designed to build websites and applications. The Webform module specializes in the user experience and performance around easily collecting scads of submission data. Drupal's Field API is focused on managing and displaying data as content. I respect the ongoing debate and comparison of Webform vs Entity/Field API-based forms, but my simple argument is the Webform module is for building forms and Field API is for building websites and applications. That said, Field API can definitely be used to build forms and webforms could be used to collect content for websites. Ideally, these two systems could and should work together.

The most immediate solution would be to make it possible for a webform to become an advanced optional front-end-to-node edit or user registration forms. The benefit? Webforms would have a lot more flexibility when it comes to layout, editorial content, inputs, validation, notifications, equaling easier customization. I also like the concept that a Webform could have a 100+ elements with only some of the elements being used to populate fields on a node or user. This approach recognizes the realistic limitation that Drupal's Field API should not have thousands of fields, while respecting that some webform submission data is content. The ability to embed Field API elements within a webform could also be useful.

I’ve shared my grand vision for the Webform module, and I’m confident many in the Drupal community would be happy with a stable release that includes ongoing support.

Ongoing support is a challenge in the Drupal community - very few modules possess a solid track record of providing ongoing support. I’m going to openly say the issue is that many people and businesses expect maintainers and developers to continually work for free. Companies that do allow developers to contribute to a project generally only do so because a client has a specific need. Currently, it feels like only a few big companies make solid ongoing contributions to Drupal and Open-source. Beyond that, the general level of contribution and investment drops off dramatically.

Something is amiss with our approach to funding and maintaining Open-source software - it may well be the biggest challenge affecting the Webform module’s future.

I’ll address this issue again in later blog posts. For now, I will leave you with my summation of the problem:

To truly understand the past and present state of the Webform module, it’s worth reading this discussion, which highlights the strengths and challenges we face in the community.

To quote myself from that discussion, "@quicksketch (and fellow webform maintainers) I am completely honored that you are open to having the YAML Form module continue the Webform module's legacy."

Initially, I expressed some trepidation about taking on such a massive project, but now after a year of doing it. I can openly say "I have got Webforms covered.” I see how the Drupal community has supported and contributed to my efforts.

I maintain that finding the time and resources for me to be able to continue to sustain and nurture the Webform module is the biggest challenge. And I have to think many Drupal developers and projects are facing the same problem.

I enjoy experimenting and solving problems with the Webform module. Now I’m venturing with generating income from my free Open-source project. My first attempt at this is called "Sponsor a Feature,” which is included in my recent DrupalCon presentation.

It’s safe to say that the Webform module will continue to evolve. The challenge lies in figuring out how to maintain the Webform module in a sustainable way. It is my hope that you enjoy my contribution to the Drupal community. Correspondingly, I also hope you’re up for the task of helping me and the Drupal community progress in our contributions to Drupal and Open-source.

Special thanks to Liz Berntson for reviewing and significantly copy-editing this blog post.