Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Oct 06 2020
Oct 06

This blog post picks up where my previous post about exploring a Schema-First approach to Drupal and Content Management System left off. After more research and thought into the goals and processes for taking a Schema-First approach to the Information Architecture behind a Content Management System, I realized that what I was calling a "Schema-First" approach is more aptly-named a "Schema.org-First" approach because I am exploring using Schema.org to structure reusable data within a "Schema-First" approach to developing software.

To clarify…

Schema-first development establishes a contract between developers and the operational expectations from project managers. A schema is foundationally an agreed upon set of standards and approaches – and in establishing the schema as a constrained contract, you can ensure that no matter what comes out of development, it will align with the stated overall goals.

-- Using a Schema-First design as your single source of truth

Schema.org is a collaborative community activity with a mission to "create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond."

-- https://en.wikipedia.org/wiki/Schema.org 

Key to the success of a Schema-First approach is "an agreed-upon set of standards and approaches," which I believe for web content (i.e., structured data on the Internet) is Schema.org.

Previously, I highlighted some of the benefits of using Schema.org to structure a Content Management System's information architecture. The background, reasoning, and process for taking a Schema-First approach to API design is discussed in Kristopher Sandoval's blog post, Using a Schema-First design as your single source of truth. In this post, I want to spend some time talking about an overarching benefit for using a "Schema.org-First" approach to create a "single source of truth," leading to a unified content management system.

Single source of truth

The goal of Schema.org-First is to unify an organization's data, make it easy to author and distribute content, and to create a "single source of truth."

In information systems design and theory, single source of truth (SSOT) is the practice of structuring information models and associated data schema such that every data element is mastered (or edited) in only one place.

-- https://en.wikipedia.org/wiki/Single_source_of_truth 

To create a single source of truth for content, organizations need to create one place for content to be accessed and ideally edited.

Most enterprise organizations have multiple Content Management Systems and authoring tools for creating content. It is no surprise each department's schema for a blog post is different.

Reinventing the (information architecture) wheel when it comes to web-related content is unnecessary

Establishing that all web content within an organization should use Schema.org as the foundation for structuring the data pushes all departments to create homogeneous content. An added benefit of having Schema.org as the standard is it reduces duplicate work and costs related to building and maintaining a website's content architecture. Simultaneously, there is still a common problem that organizations with multiple departments most likely have various Content Management Systems.

In theory, each department could maintain separate Content Management Systems that transforms and pushes Schema.org data into a centralized Content Hub/Repository, which could result in a lot of repetitive work, additional overhead, and complexity. The most practical approach is to have a centralized and unified Content Management System using a Schema.org-First approach.

Unified Content Management System

Besides the immediate benefits of Schema.org improving Omnichannel publishing, SEO, and the syndication and aggregation of content, a Schema.org-First approach helps address one of the biggest channels to unifying content, which is "Governance."

Governance in this context is about unifying content and departments within an organization. Frankly, I find it easy to transform and migrate content between systems but always challenging to transform a team's approach to authoring and managing content. Sometimes it is hard for people within an organization to accept change unless it helps the organization and makes their lives easier. Having a unified Content Management System helps an organization establish better governance, improve the quality of the content, and reduce the costs of maintaining multiple Content Management Systems.

I want to pause and emphasize that reducing costs is about reducing the amount of duplicate work and money spent around maintaining multiple Content Management Systems, and not about eliminating people's jobs. My goal is to show how reducing redundant costs and would allow departments to be able to do more with their resources and people.

Simply put, a unified Content Management System makes it easier for an organization to produce higher quality content, faster.

Moving dozens of department websites into a unified Content Management System can be a daunting task. Addressing this challenge is where the "Schema-First" aspect of a "Schema.org-First" approach stands out when migrating content and people to a unified Content Management System.

A Schema.org-First Migration

Schema-First is an agreed-upon set of standards and approaches. Schema.org is the standard. Now let's talk about the process of migrating content to a unified Content Management System.

Migrations are a two-step process where the data must be mapped/transformed from the old system and then consumed into the new system. There are lots of ways to approach transforming and migrating data from one system to another. In this discussion, the destination system, which is the unified Content Management System, can pull data from each source Content Management System. One can also have the source systems push content into the destination system. Finally, there can be a collaborative migration, where the source system is transforming the data via an API, and the destination system is consuming the data. A collaborative migration can work out the best because an organization can have the developers and architects in the source system working in parallel with the developers and architects in the destination who are consuming the data.

The beauty of a Schema.org-First approach is that the source and destination content management teams know exactly how the migrated data needs to be structured before any code is created; the specification is available at Schema.org.

The source Content Management System's team knows the existing data architecture, and they have the immediate tools to transform it into Schema.org data. In most cases, the team should already know Schema.org, and they may have already started using it on their website. Because the source Content Management System most likely has a unique content architecture, each source team will have to write a custom data transformation. The good news is this could be the last time these developers ever need to write a data transformation script for the organization.

The even better news is the destination Content Management System's team only needs to write one script, ideally a microservice, to consume data from multiple Content Management Systems. Suppose the unified Content Management System development team spends the time to create a robust and stable Schema.org data aggregation system. In that case, the unified Content Management System will have a tool to ingest data from any internal or external content source. For enterprise organizations that might acquire a new company with a website, the unified Content Management System will have a well-defined process, as well as a tool for moving a website into a unified Content Management System.

I want to pause again and state the real value behind a Schema.org-First approach is not about technology or saving costs - it’s about making it easier for people to excel at their jobs. When I discuss how a Schema.org-First approach helps acquire a company's website, I think it also provides a way to onboard an acquired company's web content team. A successful and collaborative migration strategy provides an immediate and easy win for everyone involved and allows the acquired companies team to become part of the unified Content Management System.

Schema.org and Schema-first development's common goal is collaboration that makes it easier for people and organizations to be successful.


A Schema.org-First approach makes it easier to connect data and people.

Schema.org provides a standard to connect and structure web content. A Schema-First approach establishes an immediate connection between the people who are collaborating to build software. Using a Schema.org-First approach will create a single source of truth for an organization's web content and move its data and teams towards a unified Content Management System.

Getting organizations to leverage Schema.org while adopting a Scheme-First approach is a big challenge. The "API Evangelist" has some helpful thoughts and contemplations about "Why Schema.org Does Not See More Adoption Across The API Landscape?". I also highly recommend reading Kristopher Sandoval's blog post, Using a Schema-First design as your single source of truth.

If you are thinking about structured data and migrating to a unified Content Management System, which becomes your organization's single source of truth, my hope is that you will think about using a Schema.org-First approach.

Almost done…

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


Sep 21 2020
Sep 21

Currently, in Drupal’s admin toolbar, the Webform module is listed under ‘Structure’.

Webform module is listed under ‘Structure’

If you have installed the contributed Admin Toolbar module, which adds drop-down menus to Drupal’s admin toolbar, it’s relatively easy to access Webforms from any page on your website.

Someone recently asked me why ‘Webforms’ is listed under ‘Structure’ and not ‘Content.’

There are two immediate explanations as to why I chose to list ‘Webforms’ under ‘Structure.’

First, it’s much easier to add links to Drupal’s ‘Structure’ section because it provides a dedicated overview page. Drupal’s ‘Content’ section, on the other hand, displays a tabbed user interface to manage content, comments, files, and media. This tabbed interface does not easily support multiple levels of administrative pages.

Secondly, webforms are configuration entities that create webform submissions, which are content entities. This pattern aligns with how ‘Taxonomy’ and ‘Content types’ work, and they are listed in Drupal’s ‘Structure’ section. Generally, the ‘Structure’ section includes things that a site builder configures yet does not frequently update. The ‘Content’ section is where content editors continually create and update content. For a more in-depth explanation about Drupal’s admin tool, you can learn more about working with the toolbar.

For small websites with just a few webforms, like a contact or registration form, it makes sense to list ‘Webforms’ under ‘Structure’ because a site builder would configure these types of webforms once and not frequently update them. As organizations have started leveraging the Webform module to build applications and event registration systems, having ‘Webforms’ nested under ‘Structure’ makes less sense. For example, content editors that are only allowed to manage content and webforms would have the ‘Structure’ section visible with only the ‘Webforms’ sub-menu item.

the ‘Structure’ section visible with only the ‘Webforms’ sub-menu item

The above screenshot is awkward and confusing. Yes, one immediate solution is to move the ‘Webforms’ into the ‘Content.’ But the fact that the tabbed user interface in the ‘Content’ section is not able to support the Webform module’s multi-level tabbed interface remains. Let’s also not forget the question, ‘Are Webforms content, configuration, or both?’.

The problem is that some organizations are building more than just a few webforms, and there are instances where webforms are as crucial as content. The solution is to make ‘Webforms’ a top-level menu item with a dedicated icon under the ‘Manage’ section within Drupal’s admin toolbar. To further improve the user experience, I have also added sub-level menu items to ‘Webforms’ section, making it even easier to manage any aspect of the Webform module via the Admin Toolbar module’s drop-down menus. Finally, when ‘Webforms’ is moved out of the ‘Structure’ section, all administrative paths will begin with /admin/webform instead of /admin/structure/webform.

Moving the 'Webforms' menu item out of the 'Structure' section

This is a significant UI/UX change that may be appropriate for an organization’s Drupal site. Like many advanced features in the Webform module, I decided to make this a configurable setting via /admin/structure/webform/config/advanced. By default, the Webform module will still place the ‘Webforms’ menu item under ‘Structure’. For websites that are doing a lot with webforms, they can now easily move the ‘Webforms’ menu item next to ‘Content.’

For advanced Drupal site builders and developers, you can also move the ‘Webforms’ anywhere you want, including under ‘Content’ using Drupal’s menu system. My solution makes it easier for people to check a box and promote ‘Webforms’ in Drupal’s admin toolbar.

I like this new feature because it acknowledges that organizations can use the Webform module to build simple content forms or rich applications. In some cases, the Webform module is a key part of an organization’s Drupal installation, with lots of users collaborating to build webforms and manage submissions. This feature allows organizations to decide where the 'Webforms' section should live within their organization Drupal administrative interface.

In short, this feature represents the power and flexibility of the Webform module - small or large Drupal sites can create simple or complex webforms, and they can decide precisely how they want to integrate the Webform module into their websites.

Lately, there has been a lot of cool things. happening with the Webform module and you can learn more by following my blog at jrockowitz.com and watch videos on my YouTube channel.

Almost done…

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


Mar 09 2020
Mar 09

What is the future?

Our future user experience with computers is going to be significantly based on the intersection of personalization and voice assistants. Simply put, voice assistants are going to completely understand every question being asked, find the perfect personalized answer to every question, and empathetically return an appropriate response.

I have become slightly obsessed with voice assistants. In my limited free time, I am exploring both Alexa and Google Assistant. Both technologies have their strengths, weaknesses, and differences but their underlying user interaction and even their back-end code is glorified if/then statements. For example, “if” an end-user asks a question like, “What is the weather?”, “then,” the back-end code looks up the weather for the user’s current location and returns a response.

One of the key challenges for building useful voice assistant applications is conversational design. Although we all know how to have a conversation, designers and developers will need to discuss the problem and figure out the solution. A secondary challenge that I am noticing for creating engaging voice user experiences is providing the data behind the voice. Organizations are going to have to restructure their data to be more omnichannel and consumable by voice applications. For example, Mayo Clinic recently discussed how they had to rethink their editorial process to create content that is more distributable to voice channels.

As we begin to develop voice assistant applications and strive to build personalized user experience, everyone is going to come to the realization that we need to rethink how we structure, share, and consume data. If we collectively want to succeed, we need to collaborate and work together to define and implement standardized data structures.

Defining, standardizing, and structuring our data using Schema.org

The internet and modern computing exist because collectively we have become good at collaboratively creating and sharing open standards and open-source software. Schema.org is the most recent standard to emerge and the blog post excerpt below established who is behind Schema.org and why these organizations are working together.

“On June 2nd (2011) we announced a collaboration between Bing, Google and Yahoo to create and support a standard set of schemas for structured data markup on web pages. Although our companies compete in many ways, it was evident to us that collaboration in this space would be good for each search engine individually and for the industry as a whole.”

-- http://blog.schema.org/2011/07/on-june-2-nd-we-announced-collaboration.html

The homepage of Schema.org succinctly defines what is Schema.org.

“Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond.”

-- https://schema.org/

Based on the popularity of Schema.org, there is little need for any further explanation or even examples because everyone is implementing it…we are just doing it wrong. “Wrong” is a very harsh and critical word, and I hesitate to ever use it. At the same time, in this context I am now required to justify its usage and illustrate the mistake that we are collectively making when thinking about Schema.org.

First off, for many existing websites and internet applications, schema is an afterthought that is being implemented on top of our existing web pages and content. Fortunately, adding schema to our web pages usually results in improved SEO and Google page ranking. If we spend the time implementing speakable schema, we can also have our content promoted in voice applications.

To address the growing need to include schema within our webpages, every enterprise CMS offers some mechanism to add schema to generated content. Drupal has a Schema Metatag module. WordPress has a Schema plugin. Adobe Experience Manager has the ability to create, add, and manage metadata schemas. Laying schema on top of our existing content architecture feels more like a workaround or band-aid to the challenge of collectively defining, standardizing, and structuring our data. Everyone is still defining their unique content architecture.

We are failing to address one of the biggest challenges in computer science... naming things

If we step back and think about it, there are many different ways to describe something as simple as an image object. For example, should the text associated with the image be called title, caption, label, or text, and then how do we want to describe the image’s URI and metadata?

Would it be possible for everyone to standardize on one canonical definition on an image object? What would happen if a content management system adopted a Schema-First approach?

A Schema-First approach

Several people have begun talking about the benefit of a well-defined schema at the very beginning of a project.

“I think it would be fantastic if most vendors would be able to use schema.org as a starting point.”

-- Using schema.org as a starting point for (headless) WCM

“What’s the solution, then? Establishing a single source of truth through the use of schema-first design can help align software development. Identifying a common goal, and establishing a source for teams and processes to align themselves with is incredibly important, and in this piece, we’ll give you the understanding, and some tools, to do exactly that.”

-- Using A Schema-First Design As Your Single Source of Truth

As we start creating decoupled, headless content management solutions, it becomes more critical that the front-end teams get the expected data in the expected format. “Communication” is the single word that best describes the overarching benefit to a Schema-First approach. The idea that our websites and applications communicate using the same data structures would make the concept “Omnichannel publishing” a thing of the past and change how we syndicate and aggregate information.

Besides “Communication” there are several secondary benefits worth highlighting and using to as arguments to stakeholders who need to understand the benefits of going Schema-First.

“Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general.”
-- https://developers.google.com/search/docs/guides/intro-structured-data

Everyone especially, site owners and marketers want to have a website with excellent SEO, which increases the website's overall Google page ranking. Schema.org’s structured data is specifically designed to help improve how search engines understand shared content. SEO is the reason most organizations have added schema to the web pages. Now, we are just taking it one step further and building web pages on top of a well-defined shared schema.


Omnichannel is a cross-channel content strategy that organizations use to improve their user experience and drive better relationships with their audience across points of contact.
-- https://en.wikipedia.org/wiki/Omnichannel

COPE (Create, Once, Publish, Everywhere) approach to content management, which has been rebranded as “Omnichannel,” has helped people understand the importance of creating and distributing content. COPE and Omnichannel is still focused on an organization reaching users across an organization’s contact points. A Schema-First approach would make the “everywhere” in COPE mean “everyone”. Everyone inside and outside an organization would be able to share and consume data.

Syndication & Aggregation

Any organization that has implemented schema on their web content has seen the benefit of their content - that it is more accessible within search results and voice applications. It’s very hard for people to conceptualize what it would be like if websites and applications could seamlessly push and pull data from one website to another. It is hard to imagine that every single webpage with biographical or location information could have the data structured in the same way.

Even though we are creating API First Content Management Systems, it still requires developers to document the data being syndicated, and the developer aggregating this data needs to understand, transform, and consume the data. It pains me to admit that many organizations’ internal teams still struggle with sharing and consuming data.

Shouldn’t an organization press release be automatically consumable by any application?

An amazing proof-of-concept would be Schema-First CMS being able to pull in any NewsArticle from a website, like The New York Times, which implements Schema.org for their articles. A content manager should be able to cut and paste a URI, and with absolutely no code to normalize or massage the data, the external content should be available with the CMS.


“Now, one thing that schema.org won’t do for you is map to your product strategy, content strategy or layout.”

-- https://markdemeny.com/2019/09/using-schema-org-as-a-starting-point-for-headless-wcm/

A Schema-First approach is not a solution but provides a rock-solid foundation for building out an organization’s digital strategy and user experience. We also have to recognize that Schema.org is continually evolving, improving, and even deprecating some entities and properties. Fortunately, as one of my next steps, I want to explore prototyping a Schema-First Content Hub/Repository using Drupal, which as a community in their upgrade from Drupal 8 to Drupal 9, is learning how to evolve and properly deprecate code and data structures.

Next steps

Analyze, Prototype, Evangelize

The concept of taking a Schema-First approach to the Information Architecture behind a Content Management System is not going to be difficult to sell; the challenge is going to be implementing it successfully.

Schema.org is an evolving standard, and its shortcomings need to be analyzed and discussed. Examining how we are transforming our legacy content structures to conform to Schema.org’s specifications could show us what is missing from Schema.org’s specifications. We also need to determine what data should and should not be modeled via schema. For example, we should also think about how to manage presentation information and where it should live.

I am more of an implementation person and not necessarily a specification person. Everyone has their strengths and weaknesses. This is why I frequently use the word collaboration throughout my blog posts, to encourage everyone to contribute. The best feedback which I am going to be able to provide is going to come from implementing and prototyping a Schema-First content management solution. Fortunately, there are people like Peter F. Patel-Schneider at Nuance Communications, Inc. analyzing Schema.org (Article - Video),

Of course, I am guiltily optimistic in thinking that Drupal and its community can solve any problem. At the very least, Drupal is the open-source leader for enterprise content management and user experiences. And fortunately, I am not alone in thinking that Drupal could be a forerunner for a Schema-First CMS.

“So that’s why I’ve been thinking about how it would be if we just had one CMS which would, obviously, be perfect. The perfect CMS, or PCMS, for short...PCMS doesn’t exist, but many of the concepts mentioned in this article do. Drupal has something called the Content Construction Kit which brings ‘custom fields’ to a new level.”
-- A proposal for a perfect CMS

For me, I want to follow up this post with a proposal on how we can prototype a Schema-First implementation of a decoupled Drupal application, or maybe even more specifically, a “Content Hub/Repository.”


For open source and open standards to succeed, we collectively need to evangelize our thoughts and ideas. I know some organizations have invested time and resources in building better content models based on Schema.org. Organizations need to share their experience and get involved by encouraging clients to use and improve these standards.

For now, when your organization is layering Schema.org on top of your existing websites you should think about the possibility of a single way for everyone to organize, structure, and share data because I believe there is one, and Schema.org might be the solution.

Feb 12 2019
Feb 12

The only way to get someone to contribute to an open source project is to ask them.

At the beginning of the New Year, I set up the Webform module's Open Collective. I knew that in order to persuade organizations to back the Webform module or any Drupal-related Open Collective would require directly asking organizations to join the Webform module's Open Collective. Additionally, I also needed to listen to what an organization might want to get out of their financial contribution to an Open Collective

It is reasonable for organizations to ask why should they back an Open Collective and what should they expect in return.

At DrupalCampNJ, I paid a visit to the event's sponsors that I was friendly with and asked them to join the Webform module's Open Collective. I also decided to broaden my pitch to include asking people to consider backing any Drupal related Open Collective. The Simplytest.me and Drupal Recording Initiative collectives provide invaluable services that our community needs and everyone should help support them.

Everyone was familiar with the Webform module, and most people knew that I was maintaining the Drupal 8 version, but no one knew what an "Open Collective" is. Gradually, as I spoke to people, I managed to put together a concise explanation for the question, "What is Open Collective?"

Open Collective is a service which allows Open Source projects to transparently collect and distribute funds. Organizations who back an Open Collective will get a receipt for their financial contributions and be able to see exactly how the collected money is being spent.

The above explanation leads to the next relevant question which is "How is this money going to be spent?" My response is this: Spending the collected funds is going to be determined by what the backers want and the Webform module needs.

As the maintainer of the Webform module, I feel we need a logo. A logo will help distinguish the Webform module from the massive sea of online form builders. For some projects, the Webform module is a significant part of a proposal and a logo would help make the software feel more professional. In the near future, I am going to post an RFP for a Webform logo. Still, what I want is not nearly as important as what organizations need.

Discussing, Explaining, Listening and Delivering

I want to hear what people want or need from the Webform module's Open Collective. Since most people did not know what is an Open Collective, it was hard to expect them to know what they need from an Open Collective. As I spoke with people at DrupalCampNJ, I came up with two anecdotes that explored some potential use cases for an Open Collective.

My first anecdote happened when I finished setting up the Webform module's Open Collective, someone emailed me asking for help with debugging a broken image file upload, and they offered to pay me for my time. These small private transactions are complicated to coordinate, so I suggested that they make a donation to the Webform module's Open Collective and then create a ticket in the Webform's issue queue. I managed to resolve their problem quickly. Everyone felt that this was a successful transaction.

Another related anecdote: While brainstorming about getting people to help pay for open source development, a fellow software developer daydreamed that his company would happily pay to see a bug fixed or merely a patch committed. One of the most common frustrations in open source issue queues is seeing a patch sit there for months and sometimes years.

The above stories highlight the fact that besides using Open Collective to back an open source project, a collective could be used to execute transparent transactions using a common platform.

Would enterprise companies and organizations be more comfortable paying for open source work through an Open Collective instead of a private transaction with an individual developer?


At DrupalCampNJ, no one rejected the concept of backing a Drupal-related Open Collective. I was able to collect several email addresses which I am going to use to continue persuading and listening to potential backers. My next step is to write a short and persuasive email which hopefully will inspire organizations to back Drupal-related Open Collective.


In the spirit of full transparency, I will publish this email in my next blog post. For now, any feedback or thoughts are always appreciated. Hey, maybe my two anecdotes might have persuaded you to back the Webform module's Open Collective.

Almost done…

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

OKSubscriptions powered by Strikingly

Feb 05 2019
Feb 05

Looking back

Three years ago on Christmas day, I tagged the first alpha of the YAML Form module, which became the Webform module for Drupal 8. Looking back, it has been a great learning experience building and maintaining the Webform module. Looking forward, I want to make sure the Webform module is as stable as possible while still trying to smooth out any rough edges around accessibility and user experience. Everyone should feel that the Webform module is a stable, supported, and maintained part of Drupal's ecosystem of contributed modules. To help organizations and individuals understand what to expect from a stable release of the Webform module, it’s worth defining some general goals.

Setting goals

The goals of this blog post and the overall stability of the Webform module are to…

  • Define the ongoing stable release cycle.

  • Document what to expect from stable releases.

  • Encourage the growth of Webform add-ons and integrations.

Tagging releases

For the past three years, I've been tagging a new release at the beginning of each month. Frequently monthly releases were quickly followed up with a hotfix release to address unexpected regressions. Regressions happen because the Webform module is a feature-rich application with maybe not enough test coverage and definitely not enough eyeballs reviewing the code. Quality assurance is a challenge for open source projects; reviewing code for free is not as much fun as writing it. Even Drupal core needs help with improving the reliability of minor updates.

We need more people reviewing and testing each release.

For example, Webform 8.x-5.1 was released at the beginning of January. It has been followed by Webform 8.x-5.2-beta releases which will last until March, at which point we will transition over to release candidates that will go until April 1st when 8.x-5.2 will be released.

The availability of these beta and release candidates appear on the Webform project page and Drupal's available updates. Hopefully, people will test out these releases, especially for projects that are under active development and would benefit from leveraging the latest features and bug fixes without immediate concerns for stability.

What should people expect from the stable release of the Webform module?

Making changes

Now that the Webform module is stable and covered by the security advisory policy, it's important that we tag new releases anytime there are security issues. Security issues will force any pending beta or release candidates forward into next stable release. Until contribute modules support semantic versioning, this is the only way to move everyone forward to a secure release and stable release.

For me, second to ensuring the security of the Webform, is to ensure that the Webform module is accessible and usable for everyone. Accessibility and usability issues will be fixed as needed with change records documenting any major changes.

Anytime you update the Webform module, please read the release notes and change records.

Finally, the Webform module for Drupal 8 is designed to build amazing forms which can route submission data to any system. Any feature that helps improve this vision will be committed.

For example, I just added the Webform Attachment sub-module which provides webform elements that generate or load files that can be attached to a webform submission and an email handler.

It's important that Webform's ecosystem of add-ons and integrations continues to grow.

Expanding integrations

Even though the Webform module is a feature-rich application, advanced integrations with core and other APIs and applications, including Views, REST, Analysis, and Rules, should continue to be developed as dedicated contribute modules. Integrations with third-party applications also need to be built out as add-on modules. One of Drupal's and Webform's strengths is its flexibility and massive community who make it possible for Drupal applications to be integrated with any system.

Thank you to everyone who has contributed Webform add-ons which integrate with external applications including CiviCRM, Commerce, Druminate, Eloqua, HubSpot,, OpenInbound, iContact, MailChimp, MyEmma, Slack, Stripe, SugarCRM, Salesforce, and more…

Migrating to D8

Lastly, it's time for everyone to start migrating to Drupal 8. Heshan Wanigasooriya (heshanlk) built and supports the Webform migrate module which everyone should use to move their Drupal 6 and 7 webforms and submissions to Drupal 8.

Thank you, Heshan for making everyone's road to Drupal 8 a little smoother.​​

Looking forward

Once we are all migrated to Drupal 8, it will be time to upgrade to Drupal 9. Drupal 9 will provide us with a chance to explore what core improvements make it necessary to create a 6.x branch of the Webform module. Supporting headless webforms and the modernized Drupal admin UI using React could require us to rethink and rework some internal APIs and the form presentation layer.

Getting Involved

There are many ways to get involved with Drupal and the Webform module. And getting involved helps us all.

If you work on a new project which requires the Webform module, please use the latest beta or release candidate during development and testing.

If you create a useful Webform add-on or integration, consider contributing it back to the Drupal community by collaborating on an existing project or creating a new project.

If you launch a Drupal 8 project using the Webform module, consider backing our ongoing effort by joining the Webform module's Open Collective.

Almost done…

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

OKSubscriptions powered by Strikingly

Jan 28 2019
Jan 28

Caring about Webform accessibility

Caring about Webform accessibility was a significant and unexpected personal milestone that happened last year while working towards a stable release of the Webform module for Drupal 8. It’s not that I didn’t care about accessibility, I just never paid attention to it.

Mike Gifford and Andrew Macpherson, Drupal's Accessibility Topic maintainers, helped me understand the importance of accessibility. They also gave me some direction for how to address webform related accessibility issues. This experience led me to do a presentation about Webform Accessibility @ Design4Drupal and to strive to fix accessibility issues in the Webform module. I learned to care about accessibility, but it’s not enough - I still have to ask the question…

Have I done enough to make the Webform module accessible to everyone?

Accessibility can't be neglected

Accessibility has become an important and persistent topic in Open Source communities. I've stated how impressed I am with WordPress's reimaging of its page building user experience, called 'Gutenberg'. At the same time, I was disappointed to see how the WordPress community, specifically how Automattic, addressed accessibility issues related to Gutenberg's user experience. My criticism is based on my sense of the responsibility associated with maintaining an Open Source product used by tens of thousands of websites, and in WordPress' case, is used by over 30% of all websites.

Open Source developers can't neglect or ignore accessibility.

Open Source is about sharing and collaborating on code and ideas with everyone; therefore the result of our collaboration needs to be accessible to everyone.

Drupal's commitment to accessibility

Dries Buytaert, Drupal project lead, recognized the quagmire that was created with WordPress's Gutenberg debacle and posted a call-to-action to the Drupal community titled "Drupal's commitment to accessibility."

Today, I've come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.

-- https://dri.es/drupal-commitment-to-accessibility

The Drupal community has defined an accessibility gate with Web Content Accessibility Guidelines (WCAG) guidelines for releasing new Drupal core features. It’s inspiring to see the Drupal community's commitment to addressing accessibility. Whenever I peek at the Drupal's Accessibility Slack channel, I continually see pings to Andrew Macpherson asking him to review new core features for accessibility issues. Asking one person or even a group of people to review new features for accessibility issues does not scale very well. I’m hesitant to distract Andrew from his Drupal core accessibility responsibilities to help me with evaluating the Webform module for accessibility issues and yet I know it needs to be addressed.

Before the New Year, I was able to chat with Andrew about Drupal's and Webform's accessibility, and I suggested that accessibility should be treated like Drupal's commitment to security. Drupal has a dedicated security team, which displays badges next to stable releases that are covered by Drupal's security advisory policy. Maybe this approach is too extreme, but we need to improve how we make accessibility part of our process when building and maintaining core and contributed projects.

It’s impossible to build a team that can monitor all of Drupal for accessibility issues. My conversation with Andrew led me to suggest that I should try to 'self-certify' and assess the Webform module's accessibility. At the very least I should review, document, and quantify the Webform module's commitment to accessibility. The challenge I faced was…

How to self assess the Webform module's accessibility?

Initially, I found this task to feel daunting until I googled "Accessibility checklists" and found Berkeley's Web Access team's accessibility self-assessment documentation.

Berkeley's Web Access accessibility self-assessment

Accessibility is Usability!!!

-- https://webaccess.berkeley.edu/home

This statement from Berkeley's Web Access homepage is brilliant because it transitions everyone's acknowledgment that usability is a key part of a website's user experience and makes us realize that accessibility is just as important. The Berkeley Web Access team has put a significant amount of thought and passion into these resources.

Berkeley's Web Access site is a comprehensive, up-to-date resource for beginners and experts. There are resources discussing what is a screenreader, what does "keyboard-only" mean? and tips and how tos. They even link to Drupal's accessibility statement. What spoke to me directly was their self-assessment section with a DIY accessibility checklist.

Berkley's DIY Accessibility for Developers Google Sheet is precisely the tool I was looking for to help me take a crack at self-assessing the Webform module's accessibility

Performing the Webform module's DIY Accessibility Audit

To properly self-assess the Webform module's accessibility, it helps to establish some goals. My accessibility self-audit goals are to…

  • Develop a process for auditing the Webform module's accessibility

  • Document and remediate any Webform or Drupal accessibility issues

  • Define a benchmark for the Webform module's accessibility

My process is to fill out the DIY Accessibility Audit spreadsheet's action items AS-IS and avoid making any changes to overall spreadsheet architecture or recommendations. I decided to use WebAIM's WCAG 2 Checklist with my favorite accessibility evaluation tool, the WAVE extension for Chrome. I also wanted to leverage Pa11y, an automated and command-line testing tools. All new accessibility issues would be documented on Drupal.org via Issue #3026393: [meta] Self-assess the Webform module for Drupal 8's accessibility. The completed spreadsheet will define a benchmark for the Webform module's accessibility.

I also think it’s important to note that all aspects of the Webform module's accessibility are being reviewed and assessed, not just the generated public-facing forms. The form builder and administrative user interfaces must also be accessible to everyone. Since the Webform module is built on top of Drupal's Form API, some accessibility issues may be coming from Drupal core. Therefore, I’m also going to track and document related Drupal core accessibility issues.

Here are results from the Webform module's DIY Accessibility Audit

When I began reviewing and filling in the DIY Accessibility for Developers spreadsheet, I had a misconception that I’d be able to share some statistical results that quantify the Webform module's accessibility. The first page of the spreadsheet does include the number of issues and their statuses. I don't feel saying X issues exist with X fixed and X remaining portrays a complete picture. The experience of filling out this spreadsheet did give me an understanding of what is required to make a user experience like the Webform module accessible.

Developers need to start reviewing their project's user experience through different perspectives. To understand accessibility, developers need to navigate the project's UX using just the keyboard and recognize that every piece of content and the visible widget will be read aloud by a screen reader.

I found that the combination of reviewing the WCAG guidelines and comparing the results from two automated tools, WAVE and Pa11y, helped me to see any immediate problems. Listing out individual WCAG guidelines with Webform and Drupal specific notes helped me apprehend the Webform module's accessibility. I did find and remedy a few accessibility issues, which were all related to the proper labeling of form inputs with appropriate contextual information, which would be read aloud via a screen reader.

The Web Content Accessibility Guidelines (WCAG) can feel overwhelming but when I approached them using WebAIM's WCAG 2 Checklist, it was easy to just read through them and determine which guidelines apply to the Webform module. Collaborating and iteratively defining an accessibility checklist with recommended accessibility testing tools for Drupal core and contribute projects would help ensure the accessibility is part of our Drupal communities process. Some of this discussion is already happening via Issue #2857808: Automating accessibility checks

Self-assessment can improve Drupal's accessibility

Self-assessment is one of many tools and approaches to improving Drupal's accessibility. We recognize security and automated testing as part of our process and visibly on every project page. Shouldn't accessibility be treated the same way?

Personally, I take a lot of pride in knowing the Webform module is one the most accessible form builders on the market. This is something I want to promote to anyone evaluating the Webform module and Drupal.

Promoting the Webform module's accessibility

To truly and publically define the Webform's accessibility benchmark, I decided to add the below callout to the Webform module's project which links to the completed spreadsheet and this blog post.

The Webform module is committed to being accessible to everyone.

The Webform module is committed to being accessible to everyone.

Contributing and funding Webform accessibility

Improving the Webform module's and Drupal's accessibility requires an ongoing effort. Every minor release of Webform and Drupal should include accessibility improvements. If you have the time and resources, please get involved in the Drupal and the Webform module's issue queue. Organizations that rely on the Webform module should consider backing or donating the Webform module's Open Collective. Backing the Webform module's Open Collective will help us improve accessibility and encourage the overall growth and support of the Webform module.

Final thoughts

I like Berkeley's Web Access statement that "Accessibility is Usability!!!" so much, I decided to play with these words and came up with…

Open Source is Accessibility!!!

This statement plays with multiple meaning of accessibility because Open Source is built on the idea that the software's source code should be accessible to everyone. It’s now time for our software to be accessible to everyone.

Everyone needs to care accessibility and your opinion matters. Asking people to self-access their code might be asking too much. At the same time, I'm proud of the accessibility bullet point I have added to my resume skills. Striving to include everyone and anyone is never a bad idea. For me, being an Open Source developer is more than just writing code, it’s about working with a diverse and inclusive community of people, and doing my level best to make sure everyone is acknowledged, heard, seen and considered. We’re all individuals but we’re also all part of the big picture.

What do you think about encouraging Drupal core and contrib developers to self-assess their code and projects?

Please post your thought below and consider backing or donating to the Webform module's Open Collective.

Almost done…

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

OKSubscriptions powered by Strikingly

Jan 15 2019
Jan 15

Open Source

Open source and me

For the past two years, I have been blogging about my experience building and maintaining the Webform module for Drupal 8 and have had some lively discussions about them all. As the Webform module moved from beta or release candidates, I shared my experience in two posts titled Webform 8.x-5.x: Where Do We Come From? What Are We? Where Are We Going? and Webform, Drupal, and Open Source...Where are we going?. Throughout my blog posts, the question persists…

How is open source sustainable?

Open source and organizations

In 2018, open source has become a success story, particularly for large organizations. As someone who has been building websites since Microsoft Internet Explorer 4.0 (1997), I see the fact that Microsoft is going to use the open source Chromium rendering engine as an amazing achievement for open source and even Microsoft. Microsoft has transformed from calling Linux a cancer to fully embracing open source collaboration.

Open source allows organizations to make a collaborative investment that provides them with a large technical return.

Organizations sponsor open source, however, the work is done by individual developers who may work for an organization or independently within the open source community.

What about individual software developers who contribute to open source? At what point do we recognize their part?

Open source and individuals

I recently wrote about Why I am one of the top contributors to Drupal? which explains my motives for my contribution to Drupal and my commitment to maintaining the Webform Module for Drupal 8 for the foreseeable future. One key reason behind my contribution is…

Open source allows individuals to share their passion with a collaborative community which improves their professional profile/resume.

The lone software developer has become a thing of the past. Modern software is a collective and collaborative process. Many software developers’ first experience with software collaboration is when using or contributing to an open source project. Ideally, the lone software developer becomes a member of the open source software community.

That said, building, maintaining, and sustaining collaborative communities where organizations and individuals work together is challenging.

Open Source and community

Growing, nurturing and building anything comes with a set of challenges and difficulties - open source projects are no exception. And this is where structure comes in. Structure, a system, a framework - whatever you want to call it - helps us gauge where we’ve been, where we’re going and where we want to be. Communities need to have some system of governance and sustainability. Open source projects are built by a loosely knit community of developers working together and making decisions.

The most common decision making roles in open source is the 'maintainer' because they help make sure a project continues to grow and work.

Maintainers need to be able to maintain their projects. Projects need to be maintained.

Open source and sustainability

The discussion around open source sustainability is ongoing. Danny Crichton at TechCrunch recently wrote a comprehensive essay about the current state of open source sustainability. It is a worthwhile read with useful background information and references.

There are several approaches to funding/supporting open source developers. To me, the most appealing approach is Open Collective because it is exploring how to collect and distribute funds for an open source project in a completely transparent way.

Open source software is typically created using full transparency. The problem of open source sustainability may be best solved using full transparency.

Open Collective

Open source and Open Collective

Open Collective is a platform for global collaborations to transparently collect and distribute funds.

Open Collective is trying to solve the much larger issue of global collaboration, and open source is one type of collaboration. Besides an open source project, an Open Collective can be set up for a meetup, a political group, or even a Drupal Camp.

Persuading people to contribute funds to an Open Collective requires a mix of marketing, messaging and incentives.

Open Collective and incentives

The strongest incentive to get anyone to do something is to provide a tangible result. Tangible results can be elusive when fixing a bug or upgrading some code. Finding the right messaging and incentives requires experimentation. Incentives should help people get the most out of the software. Incentives could be bug fixes, feature requests, support requests, documentation. If these experiments are successful with organizations and individuals backing and funding an Open Collective; the Open Collective will face its next challenge which is spending the money.

Once a project has money, it is up to the maintainers of that community to decide how to spend it.

-- https://techcrunch.com/2018/06/23/open-source-sustainability/ 

Open Collective and money

It is doubtful that most open source maintainers and contributors can be fully compensated for their late night hours and weekends contributing code, design, documentation, project management, and other expertise to an open source project.

We need to figure how to best spend the money in ways that provide a high return.

In the Drupal, we like to say “Come for the code, stay for the community.” Communities require infrastructure to work and grow. Reinvesting an Open Collective's funds to grow a project's community could give everyone involved some incentive. For example, we could use Open Collective funds to make it more financially feasible for a project's maintainers to speak at events. Another concrete reinvestment of funds is paying for code sprints.

Open Collective is providing a tool which helps improves open source sustainability. It is up to each project's maintainer to determine how to use this tool and collected funds.

How can Open Collective directly benefit the Webform module and the Drupal community?


Open Collective and Webform

The goal of this blog post is to initiate the conversation around leveraging Open Collection within the Drupal community. Developing and refining the marketing and messaging for the Webform module's Open Collective is going to be an interactive process with some experimentation.

Webform and marketing

The success of the Webforms' Open Collective is going to hinge on the Webform module's project page on Drupal.org, the Webform module's page on Open Collective, and some callouts in the documentation, videos and maybe in the Webform module's user interface

Webform and messaging

After three years of working heavily on an open source project, I strongly feel that the most important message to new and even old people in the open source community is…

Everyone is welcome and we are here to help.

Gradually within the Webform module's Open Collective, we need to figure out how to talk to the consumer of the software by…

Communicating the value of contributing and providing incentives for people to contribute.

Webform and incentives

Support is the most immediate incentive to get people to pay for open source software. WordPress' plugin ecosystem openly asks and sometimes requires people to pay for support licenses. I never want to force or trick a user to pay for support. The Drupal community is passionately against paid modules. Nevertheless, it’s important to communicate to people that supporting an Open Collective will help support the Webform module and the Drupal community. There is no doubt they go hand in hand.

Frankly, I already escalate issue queue tickets created by people and organizations who are active contributors or sponsors in the Drupal community, especially if they are members of the Drupal Association. BTW, I also welcome and escalate tickets created by new members of the Drupal community. I have not publicly documented this policy, but it is worth asking "Should we be providing free software with free support?"

Webform and money

How the funds in Webform module's Open Collective are being distributed is tricky but not impossible. Initially focusing on reinvesting any funds back into the Webform and Drupal community and the software is a fair and reasonable approach. The collected funds should only be spent on event/speaking related costs and direct improvements to the Webform module's user experience, accessibility, and marketing.

Reinvesting funds for marketing might be the only controversial expense. I am going to tread lightly with spending money on marketing, but the Webform module needs a logo, maybe a better slide deck, and some SEO to compete with the 100's of other form builders on the market. BTW, Drupal's community is so awesome I would not be surprised if someone contributed a logo to the Webform module.

Webform and me

I am not going to get rich from the Webform module. I am incredibly fortunate to have steady consulting work, which allows me to contribute my time to the Webform module. The Webform module is a professional and intellectual challenge for me. The sustainability of the Webform module is part of this challenge.

What fascinates me most about the challenge of open source sustainability is the scale that our open source projects are benefiting everyone including large organizations. Large organizations have realized that they can tap in the power of open source software and its communities.

Open source needs to push back on organizations and ask them to give back.

Us and open source

“The culture of our community should be one that gives back and supports community projects with all that they can: whether with employee time or funding. Instead of just embracing the consumption of open source and ignoring the cost, we should take responsibility for its sustainability."

-- Henry Zhu of Babel

Open source is about us. Us is anyone that uses open source projects. Sometimes, we forget that even the individual or organization that uses the software without contributing back to open source are still peripheral members of our community. We need to explore how we are marketing open source projects, think about our messaging and provide some incentives to welcome and encourage everyone to get involved.

Join the Webform module's Open Collective

Almost done…

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

OKSubscriptions powered by Strikingly

Dec 12 2018
Dec 12

Webforms in Drupal 8 are configuration entities, which means that they are exportable to YAML files and this makes it easy to transfer a webform from one server environment to another. Generally, anything that defines functionality or behavior in Drupal 8 is stored as simple configuration or a configuration entity. For example, fields, views, and roles are stored as configuration entities. Things that are considered 'content' are stored in the database as content entities. Content entities include nodes, comments, taxonomy terms, users, and also webform submissions.

Configuration is exportable as YAML.
Content is stored in the database.

Managing Configuration

The core concept behind Drupal's configuration management is you can export and import how a website is configured (aka how it works) from one environment to another environment. For example, we might want to copy the configuration from your staging server to your production server. Drupal 8 has initially taken the approach that all configuration from one environment needs to be moved to the new environment. The problem is that…

The imported configuration will clobber (aka replace) any existing configuration

In the case of webforms and blocks, this is a major issue because site builders are continually updating these config entities on a production website. The Drupal community is aware of this problem - they have provided some solutions and are actively working to fix this challenge/issue in a future release of Drupal.

Improving Configuration Management

Below is a summary of these three modules.

The Config Filter module provides an API for controlling what configuration is imported or not imported for different environments.

The Configuration Split module allows defining sets of configuration that will get exported for different environments.

The Config Ignore module allows specified configuration not to be imported (aka ignored) and overwritten.

Geert van Dort's recipe for Configuration Management

Geert van Dort has written a great resource documenting how to exclude config from configuration management in Drupal 8 and he uses Webforms as his example. Geert van Dort's article is a must-read.

There is one somewhat obvious configuration management gotcha that I have not seen fully documented.

The importing of outdated configuration gotcha

In the Webform issue queue, I am repeatedly seeing tickets related to exported webform config that have not been properly updated. For example, someone exports a Webform from 8.x-5.0-rc10, updates the Webform module to 8.x-5.0-rc26, runs the database/config updates, and then imports the Webform configuration from 8.x-5.0-rc10, which is missing any new configuration properties and changes from 8.x-5.0-rc26. Usually, I am able to pinpoint the missing update hook and suggest that someone runs the missing update hook using a drush command like…

drush php-eval 'module_load_include('install', 'webform'); webform_update_8144()';​

How to prevent the outdated configuration import gotcha

Good configuration management comes down to deciding on an approach and following it.

For me, the above concept was the most important takeaway from Michael Anello's Drupal 8 Configuration System Basics.

The solution to prevent the outdated configuration gotcha is to define a process and follow it. Below is a general outline of the steps required to make sure your exported configuration is always up-to-date

On your local or development environment:

When deploying core and contrib module updates:

I have deliberately avoided including what specific mechanism you should be using for updating your site, which generally should be a combination of GIT, Composer, and Drush because the most important step is…

Make sure when you update Drupal core and contrib modules, your exported configuration has also been updated.

The Distribution Configuration Gotcha

Distributions are full copies of Drupal that include Drupal Core, along with additional software such as themes, modules, libraries ​and installation profiles.

Distributions include predefined configuration files, which can quickly become out-of-sync with the distribution's modules. For example, a distribution's exported configuration could be expecting an older version of the Webform module. It is the distribution maintainer's responsibility to keep the configuration up-to-date which is challenging because they have to do a full installation of the distribution, update the distribution's modules and then export the updated configuration. This is a very tedious process.

One immediate thing that a module or theme maintainer can do to help distribution maintainers is to keep change records and tag any changes that might impact a distribution. Another best practice is to try to keep configuration breaking changes to a minimum.

Webform specific configuration management tools

Exporting webform configuration

The fact that an entire Webform is exportable into one file has made it possible to create feature and element specific test webforms, which I use during automated testing. Currently, there are over 200+ test webforms included in the Webform's test modules. The Webform module provides an 'Export' tab which allows you to easily and quickly export any webform.

Webform Export Tab

Webform Export Tab

If you find an issue with a webform, the best way to get help is to isolate the problem to a simple example webform, export it, and then upload it to the Webform issue queue.

Tidying exported YAML

Another minor enhancement you will see in exported Webform is that the multiline strings in the YAML file are formatted in a more readable form. To learn more, see Issue #2844452: Export configuration YAML strings as multiline. If you need your exported YAML configuration file in a slightly more readable format you can also use the Webform's tidy Drush command.

Repairing admin configuration and webform settings

If you happen upon some webform configuration that is outdated, you can run the drush webform:repair command or click the 'Repair configuration' via the admin UI under that 'Advanced' configuration tab (/admin/structure/webform/config/advanced)

Repair Webform Configuration

Repair Webform Configuration

The future of configuration management

I have been using Drupal's configuration management since early alpha releases of Drupal 8 when configuration was not even stored in the database. The Config Filter, Configuration Split, and Config Ignore trifecta of contributed modules show how the Drupal community can work together to fix some challenging issues, paving the way for solutions to make their way in Drupal core.

The concept that we can quickly export an entire Webform into one shareable file is awesome and has made my life exponentially easier in maintaining the Webform module for Drupal 8.

The proposal for the Configuration Management 2.0 initiative is comprehensive and exciting. For example, if the Webform module could hook into the configuration import process, we should be able to repair outdated configuration as it is imported. For now, I want to say thanks to everyone involved in Drupal's Configuration Management Initiative.

Almost done…

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

OKSubscriptions powered by Strikingly

Nov 27 2018
Nov 27

Attending Drupal Events grows our community

In my last blog post about Talking about Advanced Webforms and Showing Code, I mentioned my presentation needed work and I needed practice. At DrupalCamp Atlanta, I was able to do just that. I delivered my 'Advanced Webform' presentation and received some very valuable constructive criticism on how to simplify and improve my slide deck from Michael Anello (ultimike).

At DrupalCamps I enjoy presenting and sharing my passion for the Webform module with the Drupal community. I also value hearing and seeing what other people are doing with Drupal. In Atlanta, listening to Jesus Manuel Olivas (jmolivas) passionately talking about using GatsbyJS with Headless Drupal was inspiring plus I want to mention that this approach represents a huge paradigm shift for all enterprise content management systems. Besides hearing about the latest and greatest technologies at DrupalCamp Atlanta, I also learned how much work it is to organize a DrupalCamp.

The organizers of DrupalCamp Atlanta did a fantastic job. Kaleem Clarkson (kclarkson), one of the camp's organizers, posted a call to action for organizations using Drupal to sponsor an event

Sponsoring an event

Kaleem's post titled, Sponsoring a DrupalCamp is Not About the Return on Investment (ROI), reminds everyone of the importance and value of sponsoring a camp. He also acknowledges that some companies focus and roles are shifting within the Drupal community. I think the most important question/situation Kaleem addresses is…

If Drupal is the "enterprise solution", what does this mean to our community and camps?

I am 100% okay with Drupal being an enterprise solution. Large organizations are using Open Source and they need an enterprise content management solution. Enterprise companies using Drupal need to train and support their employees; DrupalCamps are a great place to start.

Companies should sponsor Drupal events and the community

Kaleem makes solid arguments as to why a company should sponsor an event, which includes visibility, credibility, and collegiality. Companies have to keep track of their ROI, so it is important to ask what does a company gets and wants from Drupal event. The best way to get a company to open their wallets is to show them some results. Drupal is the result of companies and people sharing time and money to build something outstanding. We need to entice new companies to sponsor event and sprints.

Sponsor a sprint

Code sprints happen at every Drupal event. Sometimes there are organized collaborations with a dedicated time and place and other times peoples are committing last-minute patches and tagging a new release before a presentation. Events and sprints tend to go hand-in-hand, but it’s worth emphasizing that code sprints produce tangible results.

I always get nervous before I get up in front of a large audience, so instead of biting my nails, I work on fixing a bug or writing some cool feature enhancement to the Webform module. I have recognized this pattern, so now when I go to camps I have a personal Webform code sprint agenda.

At Design4Drupal, I started caring about and fix accessibility issues. At DrupalCamp Atlanta, I finally fixed all the lingering issues with conditional logic and even created a ticket for a stable release of webform. My point here is that things happen at Drupal events and sprints, sponsoring companies help make these things happen.

Companies should help sponsor and provide content and speakers for Drupal events.

Sponsor a speaker

Drupal events can’t happen if there is no one willing or able to get up at the podium and talk about Drupal. Good presentations and keynotes can inspire and even shift the direction of the entire Drupal community.

Who is speaking at Drupal event

There are generally two types of speakers at a Drupal event, the first is someone representing their organization/employer, and the other is someone representing their personal and professional interest. Both types are valuable and add to the collective discussion and evolution of Drupal and its community. Some speakers, including myself, represent an organization and their personal and professional interest.

Organizations need to encourage their employees to speak and contribute to Drupal. Everyone benefits when an employee participates in a Drupal event. Personally, learning how to speak publically is my biggest personal and professional accomplishment while working on the Webform module. Having my recorded session available online allows potential employers and clients to know that I am not afraid to get up in front of a large group of people and talk about Drupal.

Organizations also benefit from having employees promote services, hosting, products, and ideas being built around Drupal. Of course, we don't want DrupalCamps to become paid infomercials but these events provide opportunities for organizations and developers to collectively help steer the direction of Drupal.

Supporting individual speakers

There are a bunch of people in the Drupal community who are the maintainers of specific modules or APIs. For example, I am the maintainer of the Webform module for Drupal 8. I travel on my own dime to events and talk about the Webform module and related topics. The only limitation I run into with traveling to events is the cost per event, which for anything outside of the New York tri-state area is around $750 to $1,000 dollars. I am not exactly sure if people should be paid to speak at events, however, I know first hand that travel expenses limit where and how often I speak at Drupal Events.

Should organizations sponsor speakers?

There are three immediate benefits to sponsoring a speaker.

First, you get the subject matter expert to come to your community and share their ideas. For example, as a community, we need people passionately talking about using GatsbyJS and Headless Drupal at as many Drupal events as possible.

Second, you get to pick the brains of subject matter experts for ideas. I know that if an organization paid for my travel expenses, I would have no hesitation spending a few hours helping them review and understand how they can best leverage the Webform module and Drupal 8 for their client's projects and needs.

Finally, helping to offset some of the costs for someone who is sharing their ideas and time with the Drupal community is a great way to say thanks.

Proposing that a speaker should be sponsored/paid to talk at a Drupal event is going to require some more thought and work. There is one aspect to all our Drupal events which should be paid for… the red button.

Sponsor the red button

Kevin Thull has been recognized for his ongoing contribution to Drupal community which is making sure our presentations are recorded and shared online. I will let everyone in on a little somewhat known secret to getting your session proposal accepted at a DrupalCon - you need prior speaking experience. Kevin's session recordings from DrupalCamps are used and vital to the DrupalCon speaker selection process.

Let's not forget that Kevin's 600-plus session recording helps to share information with people that could not attend a DrupalCamp. We have all faced the quagmire of trying to understand how a module or Drupalism is supposed to work and have watched a recorded presentation to get over this challenging hump.

Kevin started a GoFundMe campaign for "paying for food and commuter costs out of my own pocket, which average around $350 per camp." He is really close to his goal of $5000. We should all contribute to making sure he reaches this goal and then exceeds it.

Click the damned button!

Click the damned button!

Final thoughts

The Drupal community is massive, and we collaborate and solve some amazingly challenging problems. The challenge of sustainability is only going to be addressed when we figure out our economy around Open Source software. Realistically, the recent high profile acquisitions of RedHat and GitHub is tied to these companies’ reliance on software-as-a-service (SaaS) and cloud computing. Both companies contribute heavily to Open Source. These acquisitions are significant to ongoing growth and success of Open Source but these are large transactions.

Drupal and Open Source community still need to figure out what smaller transactions are required in order to help grow and sustain our communities. For now, giving $10, $20, or $50 to help Kevin Thull continue to record our presentations and share our ideas and passions is a good start.

Support the Red Button

What are your thoughts?

I am sure Kevin and I are not alone in trying to figure out how to offset the costs of presenting at and recording DrupalCamps. Conversely, there are also organizations who are also figuring how to start or continue support DrupalCamps and Meetups. Please post your thought below and on Drupal.org

via Issue #3012321: Governance Taskforce Recommendation "Provide Greater Support For In-Person.

Almost done…

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

OKSubscriptions powered by Strikingly

Nov 05 2018
Nov 05

For the past two North American DrupalCons, my presentations have focused on introducing people to the Webform module for Drupal 8. First and foremost, it’s important that people understand the primary use case behind the Webform module, within Drupal's ecosystem of contributed modules, which is to…

Build a form which collects submission data

The other important message I include in all my presentations is…

The Webform module provides all the features expected from an enterprise proprietary form builder combined with the flexibility and openness of Drupal.

Over the past two years, between presentations, screencasts, blog posts, and providing support, the Webform module has become very robust and feature complete. Only experienced and advanced Drupal developers have been able to fully tap into the flexibility and openness of the Webform module.

The flexibility and openness of Drupal

Drupal's 'openness' stems from the fact that the software is Open Source; every line of code is freely shared. The Drupal's community's collaborative nature does more than just 'share code'. We share our ideas, failures, successes, and more. This collaboration leads to an incredible amount of flexibility. In the massive world of Content Management Systems, 'flexibility' is what makes Drupal stand apart from its competitors.

Most blog posts and promotional material about Drupal's flexibility reasonably omits the fact that Drupal has a steep learning curve. Developers new to Drupal struggle to understand entities, plugins, hooks, event subscribers, derivatives, and more until they have an ‘Aha’ moment where they realize how ridiculously flexible Drupal is.

The Webform module also has a steep learning curve

The Webform module's user experience focuses on making it easy for people to start building fairly robust forms quickly, including the ability to edit the YAML source behind a form. This gives users a starting point to understanding Drupal's render and form APIs. As soon as someone decides to peek at the Webform module's entities and plugins, they begin to see the steep learning curve that is Drupal.

Fortunately, most Webform related APIs which include entities, plugins, and theming follow existing patterns and best practices provided by Drupal core. There are some Webform-specific use cases around access controls, external libraries, and advanced form elements and composites, which require some unique solutions. These APIs and design patterns can become overwhelming making it difficult to know where to get started when it comes to customizing and extending the Webform module.

It is time to start talking about advanced webforms.

Advanced Webforms @ DrupaCon Seattle 2019

Drupal Seattle 2019 - April 8-12

Drupal Seattle 2019 - April 8-12

DrupalCon Seattle is scheduled to take place in April 2019, but session proposals are closed. There are a lot of changes coming for DrupalCon Seattle 2019. The most immediate one affecting presenters is that proposals are limited to either a 30-minute session or a 90-minute training. I understanding this change because a well-planned and focused topic can be addressed in 30 minutes while training someone requires more time. I’m happy to say that my proposal for a 90-minute Advanced Webform presentation was accepted. Now I need to start putting together the session outline and materials

Talking about advanced ​webforms for 90 minutes is going to exhausting so I promise everyone attending there will be a break.

I’ve decided to break up this presentation into two parts. The first part is going to be an advanced demo. I’ll be walking through how to build an event registration system and maybe an application evaluation system. During these demos, we’re going to explore more some of the Webform's modules advanced features and use-cases.

The second part of the presentation is going to be a walkthrough the APIs and concepts behind the Webform module.

Topics will include…

  • Creating custom form elements

  • Posting submissions using handlers

  • Altering forms and elements

  • Leveraging API's

  • Writing tests

  • Development tips & tricks

This presentation is going to require a lot of work. Luckily, I have six months to practice my presentation and work out some of the kinks.

Talking about code is hard

Fortunately, there are plenty of DrupalCamps before DrupalCon Seattle where I can rehearse my presentation. Two weeks ago, I presented the second part of my training at BadCamp and learned that scrolling through code while talking is challenging. I struggled with clicking thru PHPStorm's directory trees and showing different interfaces for entities and plugins.

Being able to navigate and understand code is key to climbing Drupal's steep learning curve.

I enjoy giving live Webform demos because I really believe that physically showing people how easy it is to build a form makes them feel more comfortable with getting their hands dirty. Even making mistakes during a live demo helps people see that clicking a wrong button is just part of the process. For me, the most successful and inspiring presentations are the ones where I walk out of the room with a new appreciation of the topic and a new perspective regarding the best way to learn more about the subject matter. My live demo of code at BadCamp did not work great but now I have the opportunity to improve it and I need to…

Figure out how to show the code.

Showing code during a presentation

A few years ago, my friend and coworker, Eric Sod (esod), did an excellent technical presentation about Drupal Console, which is a command line tool used to generate boilerplate code, interact with and debug Drupal. He figured out how to get past the challenge of talking and showing people how to use a command line tool. He did this by recording each console command. It was an inspiring presentation because he calmly stood in front of the room and explained everything that was happening in his recorded demo. He didn’t have to worry about misspelling a command.

Eric's approach to pre-recording challenging demos may be the solution that I am looking for. I am going to test it out at DrupalCamp Atlanta.

Going on the road and practicing this presentation

The biggest takeaway from this blog post should be:

The road to presenting at DrupalCon requires a lot of practice.

If your session proposal did not get accepted for this year's DrupalCon, keep on practicing. Make sure to record your presentations, even if it is a private screencast so that you can share this recording with next year's DrupalCon Minneapolis session selection committee. They want to know that you are comfortable getting up in front of a sizeable and curious audience.

There are plenty of upcoming local meetups and DrupalCamps where you can present..

Below are the DrupalCamps I am hoping to speak at before DrupalCon Seattle.

I hope to see you at a local DrupalCamp or we can catch up at DrupalCon Seattle. And if you have any suggestions on how to improve my presentation, for the next six months I’ll be working on it and I’m all ears…

If you want to know where I am speaking next, please subscribe to my blog below or follow me on Twitter.

Almost done…

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

OKSubscriptions powered by Strikingly

Oct 17 2018
Oct 17

In my last blog post, I explained, "Why I am one of the top contributors to Drupal?" and examined my ongoing contribution to the Webform module for Drupal 8. My post was inspired by Dries Buytaert's annual who sponsors Drupal development post. Now I want to dig into that list of who’s and acknowledge other individuals contributing to Drupal.

Let's explore some of the top contributors to Drupal.

I am deliberately limiting the discussed contributors to people that I have had minimal or no direct interaction with online or in-person. I want to explore their contributions based on their online presence versus directly interviewing them.

Every contributor's online presences tell a story

The Drunken Monkey

I genuinely value Drunken Monkey's contribution to Drupal's Search API module.

This module provides a framework for easily creating searches on any entity known to Drupal, using any kind of search engine.

We rarely appreciate an API module until we have to start using them and diving into the code. The Search API module for Drupal 8 is a magnificent example of great code which conquers one of the hardest challenges in programming: naming things.

For a recent project, I was diving into Search API's code, and Drunkey Monkey helped me out when I discovered Issue #2907518: Breakup tracking of content entities into smaller chunks to prevent memory limit issue. For the developers out there, if you read through the issue to the final patch, you will notice that Drunken Monkey manages to even improve some APIs while fixing the problem.

The Search API Guy

The first place to understand who is who in the Drupal community is people's user profiles. The most immediate thing that stands out about Drunkey Monkey is that he is…

The Search API Guy

This statement is something I can relate to because I have also promoted myself as "The Webform Guy for Drupal 8". I learned from maintainers like Drunken Monkey that becoming the person behind a Drupal project is a valued role in the Drupal community. On a related note, Thomas and I have both been members of Drupal community for 10+ years and this fact indicates that it can take time to find one's niche in the Drupal community.

Drunken Monkey is Thomas Seidl

Thomat Seidle (drunken monkey)

Thomat Seidle (drunken monkey)

Thomas Seidl is a developer from Vienna, Austria, and has been involved in Drupal and search since 2007.

-- https://drunkenmonkey.at

Thomas is the man behind the code and his personal website promotes his contribution to Search API and offers his paid support services. His promotion of paid support directly contributed to his sponsored work porting Search API to Drupal 8.

Acquia generously agreed to fund all available time for both Joris Vercammen (borisson_) and me in December and January to work on this port and related modules

-- https://Drunken Monkey.at/blog/search_api_d8_alpha_12

Thomas was a student who became a mentor

Thomas' code and ability to maintain something as complex and important as Search API hints that he has professional training. Thomas has a Master's degree in Computer Science and a Bachelor in Engineering Physics.

Being mentored and mentoring is the not so secret sauce to Open Source. Thomas has some experience doing both because he participated as a student in four Google Summers of Code and twice as a mentor.

Not surprising, Google Summer of Code has helped many other people begin their Drupal careers /experience.

What was Thomas's first foray into the world of Drupal?

Thomas' first post and patch to Drupal

Looking at someone's very first post on Drupal.org can lead to many conclusions or thoughts. Some people test the Drupal community's waters by asking a simple question. Others post an issue and then disappear. Then there is someone like Thomas who hits the ground running. His very first post on Drupal.org from 2007 is…

Issue #176124: Fatal error when running all tests

I started to smile when I read this issue because first off, Thomas found an existing ticket that was impacting him and then proceeded to provide a patch. It’s also worth noting that he was fortunate to have two active Drupal contributors, Rok Žlender and Peter Wolanin, in his sphere.

Finally, and definitely worth noting, Thomas, the Search API guy, had many individuals and organizations helping him. He highlights and acknowledges them on the Search API project page. Giving props to the collaborating irons in the fire, both big and small, demonstrates a wholly appreciative understanding of what this is all about.

“Our thanks goes to Acquia, MD Systems, Intracto and a few smaller donors and clients for financial support. Thanks as well to the large number of people who helped with development tasks and patches.”

-- Thomas Seidl

Who is volkswagenchick?

AnyJune Hineline (volkswagenchick)

AnyJune Hineline (volkswagenchick)

Let's immediately acknowledge that 'volkswagenchick' is a pretty identifiable username. Appending the word 'chick' to one's username allows one to stand out in the sea of geeky names like 'optimusprime' and 'frodo'. I am not sure if AmyJune Hineline is German, but I was able to learn that she like Volkswagens and lives in the US.

Volkswagenchick is AmyJune Hineline

AmyJune's profile on Drupal.org is fairly simple but links to a wealth of resources. Immediately three things stand out on AmyJune's Drupal.org profile - she is the Community Lead and a Drupal Site builder with Hook 42 and has been a member of Drupal.org for less than three years.

Wow, three years into her Drupal career and AmyJune is one of the top contributors to Drupal.

Hook 42 contributes to Drupal

After reading and learning about Hook 42, I am tempted to do a dedicated follow-up post exploring the organizations that contribute to Drupal but for the moment, I think Hook 42 deserves credit and gratitude for their employee’s role and contribution to the Drupal community. And I’m not the only one who seems to think so - Hook 42 is making a major contribution to Drupal and does appear in Dries blog post.

Our organization is not only using Drupal, but also contributes back to the community and to the project by writing modules and themes, participating in forums, presenting at conferences, organizing Drupal events, and more.

-- https://www.hook42.com/team

AmyJune has a mentor

Besides having a great employer, AmyJune found one of the best instructors/mentors in the Drupal Community: Mike Anello (ultimike). AmyJune credits Mike’s Drupal Career Online for helping to get her started with her career in the Drupal community. A while back, I talked about Mike's Drupal Career Online.

I’m specifically intrigued by his Drupal Career Online for individuals; It's a 12-week, instructor-led online course that goes deep and broad into the technology, community engagement, and hands-on exercises to give you a rock-solid foundation for a successful Drupal career. Mike's helping Drupal newbies become Drupal rockstars. He’s helping to grow the Drupal community by inspiring and helping individual developers to join our community. "He is helping the little guy in our community."

-- https://www.jrockowitz.com/blog/little-guy

AmyJune just proved that Mike is helping Drupal newbies become Drupal rockstars.

AmyJune has an amazing story

AmyJune is a prolific blogger who has chronicled her journey.

Drupal was the feel good adventure I needed to move on. Being open-source and free, it allows more organizations, like nonprofits and higher-eds to have custom websites built to their specific needs while maintaining smaller budgets.

-- From Nurse to Drupal Programmer: an Intern's Journey

Reading AmyJune's blog posts and understanding her journey makes it clear to me that some of the top contributors to Drupal are not just coders but people who are an integral part of the Drupal community.

AmyJune's first issue on Drupal.org

Right out of the gate, AmyJune posted a very simple constructive comment:

Issue #2450191: Be more specific when listing dependencies so that `drush en office_hours` can work

AmyJune received a perfect response from John Voskuilen (johnv) the Office Hours maintainer.

Thanks for the feedback. Hope you enjoy this module.

Little did John know that he was also helping AmyJune on her journey to becoming a leader in the Drupal Community. Ironically and related to this first issue, AmyJune went on contribute many patches which improved the README.txt files for dozens of contributed modules.

What does IMCE stand for?

IMCE is an image/file uploader and browser that supports personal directories and quota.



Nowhere on the IMCE project page does it state what the heck does IMCE stands for. I am not even sure it is an acronym. Even with Drupal's amazing improvements to media and file handling, IMCE has continued to be one of Drupal's most installed modules.

Besides the module's name, the even bigger mystery is the project's maintainer, ufku. I would like to thank them for saving my butt on numerous occasions where the IMCE provided the exact functionality needed to fulfill a project's requirement. Ufku does not seem interested in racking up commit credits, but I’m intrigued to explore who they are and say thanks

Who is Ufku? The Unknown Drupaler



Ufku has been maintaining IMCE for over 12 years. They have been a member of the Drupal community for 14 years. Ufku's user profile is sparse and their personal website just includes an IMCE demo with README files. I even desperately checked ufku.com in the whois database and there is no identifying information

Ufku has made an awesome contribution to Drupal for many years and does not seek any acknowledgment.

Let's just say thanks to Ufku

Clearly, Ufku's commitment to IMCE shows that they value Drupal. I hope that Ufku's tremendous and continuous work on IMCE is on their resume because it demonstrates a fantastic commitment and contribution to Drupal and Open Source.

Ufku whoever you are, I want to say thanks.

Ufku first post on Drupal.org

I am hesitant to pry through Ufku posts on Drupal.org because clearly, they want to remain somewhat anonymous.

Ufhu's first forum post, one-click language switch without a module (drp-4.5), shows that from day one they wanted to share some code with the Drupal community.

There are so many more contributor stories out there

Every contributor to Drupal has a story and there are many ways to explore them. Personally, I always start with people's Drupal.org profile and if I get curious enough, I start hunting for videos and podcasts.

Hear more about AmyJune and Thomas

Below are some links to learn more about AmyJune and Thomas.

AmyJune Hineline (volkswagenchick):

Thomas Seidl (drunken monkey):

For now, ufku can be called 'The Unknown Drupaler'.

Learn more about Drupal contributors

Below are some blogs and podcasts where you can learn more about the people who contribute to Drupal:

Saying Thanks

I hope the biggest lesson you can take away from this blog post is…

Behind every line of Open Source code is a person or organization. Since the code and its history is Open Source, you can find out who that person is and thank them.

Almost done…

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

OKSubscriptions powered by Strikingly

Oct 01 2018
Oct 01

Who sponsors Drupal development?

We know who contributes

A few weeks ago, Dries Buytaert published his annual who sponsors Drupal development. His report acknowledges individual and organization contributions and what projects they are supporting. This report provides a high-level overview of who contributing in the Drupal community. There are some old names on this list and some new names.

Asking why they contribute

Now that we know who is contributing to Drupal, the next and more difficult question is “Why are they contributing to Drupal?” Knowing the story behind why an individual or organization contributes to Drupal will inspire more people to get involved and give something back to Drupal and Open Source.

My contribution to Drupal

This year, I was the number three individual contributor to Drupal. The previous year, when I first appeared on the top contributor list, it was completely unexpected. I joked with my son, Ben, that, "I won a race that I did not know I was running." Being included on this list was an honor that I did not expect to achieve, partially because I’m always in awe of the ongoing work by all the core maintainers and contributors.

Since last year, I have not slowed down on my commitment to the Webform module for Drupal 8. So I was not surprised to be included in this year's list. Over the past year, I have had several interesting conversations with other developers on the top contributor list, and what resonated with me the most is that everyone on this list has a different history as to why he or she contributes to Drupal. Here is more of the story.

There are different types of contributions

I found one of the biggest difference in our contributions and commitment to Drupal is whether our work is primarily sponsored or volunteer (aka unpaid).

Only 12% of the commit credits that we examined in 2017-2018 were "purely volunteer" credits (6,007 credits), in stark contrast to the 49% that were "purely sponsored". In other words, there were four times as many "purely sponsored" credits as "purely volunteer" credits.

-- https://dri.es/who-sponsors-drupal-development-2018

Right now, I would estimate < 10% of my contributions are sponsored (aka paid). The fact that I am doing all this work for free is not the norm for most contributors. It is essential to note that every single contributor that I know on the top contributor list has at one time or another contributed a ridiculous amount of volunteer contributions to Drupal before being finding an employer or organization to sponsor their work. Some people, including Dries, started contributing to Drupal in college, others do it as a hobby, and some just do it.

We all have different stories about how we discovered Drupal. Our stories begin with our first experience with Drupal, the software, which is quickly followed by our first experience with Drupal, the community. At some point, we contribute our first patch, it might take months or years for us to start contributing regularly or maintaining a project. Finally, for me and other major contributors something changed and suddenly we are spending a significant amount time contributing and helping maintain Drupal Core or a contrib project.

Why am I contributing so much to Drupal?

If I had to pick one word to describe why I contribute so much to Drupal I would have to say "Brand." I am willing to bet that most people did not expect me to summarize my contribution to Open Source with a word generally associated with marketing.

A brand is a name, term, design, symbol, or other feature that distinguishes an organization or product from its rivals in the eyes of the customer.

-- https://en.wikipedia.org/wiki/Brand 

Personal brand

The concept of a personal "brand" never really crossed my mind until I started to work with Marco Salazar, who is been my career coach for the past two years. I was inspired to work with a coach by Michael Schmid's (@Schnitzel) community keynote at DrupalCon Baltimore called "Your brain health is more important than your standing desk". Michael's first of many great suggestions was “get a coach.”

Marcos introduced me to the notion that everyone in the digital/social media world has a story and that story is communicated by one’s personal brand. The moment we create a Facebook page, a LinkedIn profile, a Twitter account, or a Drupal.org user profile, we have started to distinguish ourselves from others (aka rivals in the eyes of customers). Ironically, I never post to Facebook and rarely engage in social media, but I love to write and share code. You might say that the work that I do, the writing and sharing of code is how I’ve defined myself - my work is my way of defining myself - my content is the work. That said, all that posting, writing, creating on social media, and even coding is content

Code is content

At the heart of what I consider my personal brand is code, specifically the Webform module. Code alone is not really content.

Computer code is the set of instructions forming a computer program which is executed by a computer.

-- https://en.wikipedia.org/wiki/Computer_code

In Open Source, our shared and freely available code is still computer code but everything around the code is content. If documentation is content, presentations are also content, even a response to a question is content.

For the past three years, I have generated a lot of content around the Webform module beginning with my personal website, this blog, documentation, videos, presentations, and responding to support requests in the Webform issue queue and Drupal Answers. Ultimately all this content has succeeded in creating a name for myself in the Drupal community. Yes, being the maintainer of something like the Webform module will help get me a job interview, more importantly, content like this blog post and even how I respond to support requests help future employers and clients understand who am I and how I work.

I understand the value of people knowing about the work I do and how I do it because in the fast and changing tech industry, it is essential not to become obsolete. My favorite children’s story about overcoming the challenge of being obsolete is "Mike Mulligan and His Steam Shovel" by Virginia Lee Burton.

Mike Mulligan and His Steam Shovel

Mike Mulligan and His Steam Shovel

The story of Mike Mulligan and his steam shovel

In this story, the main character is Mike Mulligan, a steam shovel operator, and his steam shovel, Mary Anne, are being replaced by newer diesel and electric shovels because the industry and its corresponding tools are changing. The diligent and hard workers that they are, get word of an upcoming job and in an effort to not only do their job but to also prove they can do it well and efficiently, Mike and Mary Anne boast that they can dig as much in a day and 100 men can do in a week. Mike gets the job and he and Mary Anne succeed in digging the foundation for the town hall of Popperville in one day. It turns out to be their final digging job, however, the story's ending has a wonderful approach to addressing the shift in time and technology. Remarkably, the ending which was suggested to the book’s author by a 12-year-old boy is really special and should be saved for the first time you read this book to a child. I won’t totally give it away but suffice it to say, that Mike and Mary Anne are acknowledged, remembered and valued for who they are - the town of Popperville and the world shifts, but Mike and Mary Anne still have a place in society and are not lost in obscurity.

Everyone in the software industry can relate to the challenge of feeling obsolete. Even if we master the latest and greatest programming language or framework, there are dozens more that we should/could be learning. Mastering a programming language, even writing test coverage is challenging when our work is tied to deadlines and budgets. Open Source projects don't generally have budgets or deadlines; people are just sharing ideas and working to solve challenging problems.

Contributing the Webform module provided me with a new professional challenge and community

The challenge of contributing

One of my first blog posts provides a history and the process around of my work on the Webform module. That post gives a fairly complete overview of the actual work I am doing on the Webform module. In comparison, this current blog post is exploring why am I doing all the work in the first place.

Three years ago, I was reviewing my resume and felt that working with the same institution, Memorial Sloan-Kettering, for so many years (18+) was potentially going to hurt my career prospects. I noted that my work/consulting experience was very independent and contained minimal speaking and project management experience. It is worth stating that there is nothing wrong with staying a job for years, especially if they are one of the best employers in NYC

Maintaining a large Open Source project like the Webform module is more of a software architecture and community coordination challenge, then a coding challenge.

People are watching me code

In the story "Mike Mulligan and His Steam Shovel", Mike and Mary Anne get to work on what is to be their final digging job, intermittently stating that “we always work harder and faster as more people are watching us”. And there is undoubtedly something to this. It’s very rewarding when people appreciate the work I am doing on the Webform module. Watching people gradually move to Drupal 8 and start using my work is a great feeling, especially organizations and non-for-profits that I have a personal connection with, like the YMCA who include the Webform module in their OpenY distribution.

Now, that you know the story behind why I contribute to Drupal, it is also worth discussing precisely what am I contributing to Drupal.

What am I contributing to Drupal?

Every presentation and screencast I record begins with…

Hi, my name is Jacob Rockowitz

Hi, my name is Jacob Rockowitz

My sole contribution to Drupal is the Webform module. This is a very personal and deliberate decision. I am a one project kind of guy. I do my best work when I can focus on a concrete goal and purpose. Maintaining and working on a single, isolated project is not the norm for Open Source contribution. Open Source works better when people maintain some projects while contributing to others. But for me, I find I lose a lot of momentum when having to jump from one project to another. I also feel with subsystems like Webform, someone needs to be fully engaged able to add features, respond to issues and fix bugs in a timely and efficient manner.

Writing code

The Webform module is a feature-rich application. I generally add one or two new features each week and try to refactor some existing code on a bi-weekly basis. I try to break down most tasks into one to two hours of work, and almost never estimate a feature or change that will take more than four hours into a single ticket.

While working, I am very bullish when it comes to committing code - I like maintaining a certain amount of velocity as I do things. I find it really challenging to get people to review patches and frequently I will post patch, let it sit in the issue queue for a day, come back to issue, do another code review (of my code) and commit the patch.

Quality assurance

Everyone has different levels of availability and it's understandable that someone might have time to create an issue one day but not be able to come back to review the solution. I find maintaining a certain level of quality with peer review in Open Source incredibly challenging.

Drupal's core committers do an amazing job of requiring peer review and enforcing code quality. Drupal's contributed projects are a slightly different beast. Still, certain key projects like Webform need to define and continually review their process. When Webform 8.x-5.x is finally released on Christmas, I am going to review the process for maintaining a stable version of the Webform module.

For example, last year, when Webform moved into a release candidate, I started to maintain change records, which help developers and site builders get an overview on recent changes and improvements.

Knowing that my code is not always getting enough peer review and sometimes can cause regressions makes it crucial that I respond to issues and bugs.

Webform Issue Queue

Webform Issue Queue

Responding to issues and fixing bugs

Everything we post online is content, including how we respond to issues, which means our response is part of our personal and professional profile. I do my best to respond to every request almost immediately, especially if the research and resolution of an issue might only require a few minutes.

Over the past three years, I have responded to 100's of issues and support requests. Sometimes it is incredibly challenging dealing with people who take for granted that I am generally working for free. Surprisingly, sometimes my biggest feeling of accomplishment comes from being able to help someone who initially posts an issue that has "negative undertones". I always respond professionally and help them resolve their problem; they always say "thank you." I think I find hearing gratitude from someone whose initial tone was difficult or agitated to be a complete 360. And to have that kind of affect on someone feels good.

Around 50% of my commit credits are earned through quick bugs and support requests that usually take less than an hour. I also get to decide when an issue is resolved and a commit credit is earned. I agree with Dries that…

Not all code credits are the same. We currently don't have a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might receive a credit for ten minutes of work. In the future, we should consider issuing credit data in conjunction with issue priority, patch size, etc. This could help incentivize people to work on larger and more important problems and save coding standards improvements for new contributor sprints. Implementing a scoring system that ranks the complexity of an issue would also allow us to develop more accurate reports of contributed work.

-- https://dri.es/who-sponsors-drupal-development-2018

It’s really hard to determine what is and is not commit credit worthy. Even though responding to a support request does not take long, the fact that I provide ongoing and immediate support contributes significantly to people’s success with using the Webform module and Drupal.

Showing a breakdown of how a commit credit is earned, whether it be from a core or contrib task, bug fix, support request, and documentation can help us understand how everyone's commit credits are earned. And there are layers of value in constantly evaluating, learning and discovering the time, effort, energy and attitude that goes into these things.

The Drupal Association has already done an amazing job of continually improving Drupal.org user profiles, which for me is as important as my resume. The Drupal Association has also improved the tools available for creating and maintaining documentation.

Creating documentation

As the Webform module's features and user base grew, I realized that I needed to start thinking about documentation. I code better than I write but the Webform module's needs documentation. I set up the Webform module's documentation section and gradually revised different sections and pages. Before a stable release, the Webform Features page needs to be updated.

Producing help videos

I discovered the best medium for me to create documentation is screencasts. I found an amazing Creative Commons slides template and started creating and producing very simple screencasts. These screencasts are available within the Webform module and on Drupal.org. Putting a voice behind the Webform module has helped assure people that this is a supported project. Yes, these videos also help promote my 'personal brand.'

How am I able to make this level of contribution to Drupal?

The reported data shows that only 7% of the recorded contributions were made by contributors that do not identify as male, which continues to indicate a steep gender gap….The gender imbalance in Drupal is profound and underscores the need to continue fostering diversity and inclusion in our community.

-- https://dri.es/who-sponsors-drupal-development-2018

I am incredibly fortunate to have ongoing work as a consultant for a client like Memorial Sloan Kettering. This relationship gives me the ability to contribute to Drupal in between paid work. I can also write-off a lot of Open Source related expenses as professional development.

I am fortunate to have the means to contribute to Drupal.

It is important to acknowledge that gender and race play a role in how much people earn and how much (free) time they have available to contribute to Open Source. Without embarking on a much larger discussion, it’s essential to realize the gender and race inequality is more directly addressed when organizations and businesses get involved in changing things.

If more tech companies work to improve their diversity while also allowing their employees to contribute to Open Source this could tip the scales where gender and race imbalance in our community reside.

What is going to be my next contribution to Drupal?​

I am committed to maintaining the Webform Module for Drupal 8 for the foreseeable future and…

There needs to be a stable release of the Webform module.

I am willing to admit that it is time. My goal is to tag a stable release before the New Year. The Webform module has less than 50 open issues and only 4 critical issues so I think this goal is achievable.

In 2019, I would like to start exploring the next generation of Drupal Form API and Webform module. If I keep plugging away at the Webform module I can write a follow-up to this blog post in a year and maybe some of Drupal's top contributors can also share their story.

Sep 18 2018
Sep 18

Even though it is has been 20+ years since I graduated from college, every September I struggle to get back to work while also feeling inspired to learn something new.

This summer I took a rest from blogging about sustainability, but I kept on coding. I felt a little guilty thinking my blog might lose its momentum, yet somehow on the “work” side, I just kept on plugging away at the Webform module’s issues queue and managed to fix a bunch of issues and make some important accessibility and UX improvements.

Coding is what I love to do; it is what drives me.

Coding is what I love to do

As I charge forward toward a stable release of Webform 8.x-5.x by Christmas, it’s time to start thinking about what’s next for the Webform module. There are a lot of people in our community thinking and talking about the future of Drupal. Drupal and most Content Management Systems (CMS) are moving towards a decoupled and headless approach.

Headless software is software capable of working on a device without a graphical user interface. Such software receives inputs and provides output through other interfaces like network or serial port and is common on servers and embedded devices.

-- https://en.wikipedia.org/wiki/Headless_software

Beginning to think about headless Webforms and Form API (FAPI)

Webform and Drupal's Form API (FAPI) has to start supporting headless Drupal and decoupled websites and applications. The Admin UI & JavaScript Modernisation is beginning to think about and experiment with, how to make Form API work with React. React will provide us with a frontend framework to build the rich user experiences and applications that our clients and users need. Choosing a frontend framework is a big decision that necessitated a considerable discussion. React's a solid choice for a frontend framework but I’m not sure it should be the foundation for an Open Source reusable form builder.

If we could decouple form elements, validation rules, and data definitions in an abstract and reusable way, any application would be able to reuse these elements or web components.

Web components

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

-- https://www.webcomponents.org/introduction

Conceptually, I was sold on the value of web components while attending John Riviello and Chris Lorenzo’s session titled "Web Components: The Future of Web Development is Here", at Drupaldelphia. They showed how Comcast is leveraging web components across all their websites.

I also watched the "Webcomponents, Polymer and HAX: decoupling authoring for Drupal and beyond" presentation by Bryan Ollendyke and Nikki Massaro Kauffman from DrupalCon Nashville. The HAX project shows the potential of web components.

There is a lot to learn about frontend frameworks and technologies

Headless Drupal has opened up our world to a variety of frontend frameworks and technologies.

A funny thing that I have to openly admit is that I have yet to code a React application or build a single web component. It took me 20 years of no longer being a student but I can now candidly say, accept, and feel no shame admitting when I don’t really know something; while knowing I can learn it. There is no way that we can know every technology. The best we can do as good software engineers is to be comfortable with continually learning new things.

React, Web components and all frontend works are completely new to me. The heart of all frontend frameworks is JavaScript. The real challenge we are facing with moving into the headless Content Management System world is learning JavaScript.

Learn JavaScript, Deeply

Drupal has better code and API's than WordPress but I have to give Matt Mullenweg credit for directly pushing the WordPress community to become better developers. In 2015, Matt told the WordPress community "To Learn JavaScript, Deeply." The only other time I have seen a tech leader take such a direct and game-changing stand on a technology was Steve Jobs rejecting Flash in favor of HTML5. Matt Mullenweg told the developers of the most popular CMS to learn JavaScript, deeply

Dries Buytaert has shared a similar call-to-action with the Drupal community:

Sharing my journey while relearning JavaScript

JavaScript and I go back a long way. My first steps into the world of programming was using JavaScript to generate an email via an HTML form that built using MS FrontPage and worked in Internet Explorer 3. My first HTML form and JavaScript is still online and it even works after 20+ years.

My first CMS, called the Inettool, was built using JScript and ASP. The code was entirely procedural and honestly, I still have not determined the best approach to creating object-oriented JavaScript.

I will keep posting about my experience with learning JavaScript, deeply. For now, I need to wrap up development of Webform 5.x.

Wrapping up Webform 5.x and looking to 6.x and beyond

For the past 2 years, I have done an introductory presentation and screencast about the Webform module and it’s time to explore some advanced topics including testing, APIs, plugins, hooks, and more…

I will be speaking about Advanced Webforms at BadCamp in 2018. Please attend my session or like me, you might want to start learning JavaScript and attend other great sessions at these conferences and many more.

Almost done…

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

OKSubscriptions powered by Strikingly

Aug 06 2018
Aug 06

It is easy to not care about accessibility, mainly because we generally don't see or understand how people with disabilities use our applications. Frankly, even usability testing can become an afterthought when it comes to building websites. There are lots of move parts to a website or an application, and it is hard to pause and ask can someone access this information using just their keyboard and/or a screen reader. The more accessible your website is, the more users you can reach and engage with your website's mission or purpose.

At Design4Drupal in Boston, caring about accessibility became the central theme for my presentation, titled ’Webform Accessibility'. After I gave my presentation, I created Issue #2979628: [meta] Improve Webform Accessibility and started fixing some obvious and not-so-obvious issues with the Webform module for Drupal 8. Andrew Macpherson, one of the Drupal Accessibility Topic maintainers, was kind enough to spend an entire train ride from NYC to Boston discussing (via Drupal Slack) form related accessibility issues and how to resolve them.

There are tools that can show you obvious problems

The most common form accessibility issue I see across the web is a failure to provide descriptive labels for form inputs. Labeling form inputs makes it possible for a screen reader to describe what input value is expected, as well as determine how it’s going to be used. For example, a screen reader needs to be able to identify a website's search box so that users can find content quickly. The solution is to provide a hidden label or title attribute to a site's search box.

Identifying what inputs are missing labels can be a difficult issue to see. Luckily, there is the WAVE (Web Accessibility Evaluation Tool) provided by webaim.org, and it shows you which inputs are missing labels.

WAVE (Web Accessibility Evaluation Tool)

WAVE (Web Accessibility Evaluation Tool)

Listening to a screen reader will tell you a lot about your forms accessibility

In my presentation I stated that "screen readers can feel overwhelming," but gradually I’ve figured out how to use them enough to understand how they work without becoming a screen reader ninja. Here’s what I’ve discovered: the simplest approach is to enable the screen reader, for OSX press ⌘+F5, and then you can use the tab, arrows, spacebar, and the enter keys to navigate focus in and out of inputs and page regions. This allows you to not only hear what information and metadata is discovered by the screen reader, but also how it is communicated to end users.

Accessibility patterns provide examples and guides to solving hard to understand issues

Javascript does not hurt a website's accessibility. Lack of awareness on how to properly use JavaScript hurts a website's accessibility.

One of the most common uses of JavaScript is to hide and show different elements and information; this behavior is called a progressive disclosure design technique.

Progressive disclosure is an interaction design technique often used in human computer interaction to help maintain the focus of a user's attention by reducing clutter, confusion, and cognitive workload.

-- https://en.wikipedia.org/wiki/Progressive_disclosure

Everyone benefits from a web page or webform with less clutter. This is why the Webform module includes support for adding help tooltips and show more slide outs to form elements. The key trick is making sure a screen reader understands how to interact with these widgets, and that these widgets are easily manipulated using navigation keys.

The WC3 provides WAI-ARIA Authoring Practices, which includes a Disclosure (Show/Hide) example and people are working on Tooltip widget example. These examples made it easy for me improve the Webform module's tooltip and show more behaviors.

Webform tooltip example

Webform tooltip example

Keyboard access can make or break an impaired user's ability to complete a form

Personally, the most important thing to respect is that not every user can manipulate a mouse - reliance on a keyboard and/or some other means to navigate a web page or form is something that needs to be of the utmost regard in creating practical and successful accessibility.

When I chatted with Mike Gifford, the other Drupal Accessibility Topic maintainer, at DrupalCon Nashville, he cited that keyboard accessibility is essential for users who might be using a sip 'n' puff to navigate the web.

Sip-and-puff (SNP)

Sip-and-puff (SNP)

Sip-and-puff or sip 'n' puff (SNP) is assistive technology used to send signals to a device using air pressure by "sipping" (inhaling) or "puffing" (exhaling) on a straw, tube or "wand." It is primarily used by people who do not have the use of their hands.

-- https://en.wikipedia.org/wiki/Sip-and-puff

The concept and image of someone using a sip 'n' puff resonated with me. The technology is straightforward while making it possible for people with major disabilities to interact with something as complex as a computer. At the most basic level, we need to respect that users need to be able to tab in and out of regions and inputs. The biggest show-stopping accessibility issue I encountered with the Webform module was the fact that once a user tabbed into the CodeMirror editor, there was no way to exit the editor using the keyboard. The WC3 recommended solution was incredibly simple: make sure pressing the 'Escape' key removes focus from the editor and moves focus to the next input. Incredibly simple and yet something that, if not fully considered, could prove incredibly frustrating.

Drupal.announce() might be the most underrated accessibility feature included in Drupal 8

Drupal.announce() provides a way to express to a screen reader changes in the state of a page, toolbar, setting tray, and any element.

-- https://www.drupal.org/node/2014521

Frankly, the Drupal community is still working on figuring out when and where changes to a page should be announced to a screen reader. The most immediate use case is telling users when something on a web page or form has changed via JavaScript and Ajax. For example, when users filter a list of modules, blocks, or form elements, it helps to tell the user how many items are displayed or if there are no results. The most relevant example in the Webform module was telling users when a multi-step webform has loaded a new page via Ajax and communicating what page a user is on. Now, when you click back or next on an Ajax-enabled multi-step webform, the screen reader will announce to the user "'Registration: Contact Information' loaded. (Page 2 or 4)."

I finally bought an Echo Dot, a voice-controlled speaker. Besides playing “Would You Rather” with my daughter, it was immediately clear to me voice-controlled interfaces are going to improve disabled people's access to information significantly. Users will no longer see our websites, pages, and forms or interact with them using a keyboard. They will be spoken to and our websites, pages, and forms need to learn how to talk back.

If you care about accessibility, make it part of your process

Accessibility is now part of my process for maintaining and improving the Webform module. The three steps that I am currently taking to check accessibility are...

  • Assess your website's accessibility using an accessibility evaluation tool

  • Listen to your website using a screen reader

  • Interact with your website using just a keyboard

I feel adding some accessibility recipes to my coding cookbook has become my extra chapter in the updated version and there is really no going back. The latest version has to include this chapter - to my mind, accessibility isn’t an option.I take pride in knowing the Webform module's user experience is inclusive and works for everyone.

I am not ready to say the Webform module is the best form building solution on the market but I will put out this bold statement/challenge…

The Webform module for Drupal 8 is the most inclusive form builder on the market.

The Webform module empowers users with disabilities and professional web developers to build powerful and flexible forms that are accessible to everyone.

For now I’ll shut up and let my keyboard do the walking and my screen reader do the talking as I build a simple contact webform from scratch.

Download the Webform module for Drupal 8

Almost done…

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

OKSubscriptions powered by Strikingly

Jun 25 2018
Jun 25

Putting together my presentation about Webform Accessibility for Design4Drupal proved to be more challenging than I anticipated. I proposed this session to force myself to begin to address accessibility in the Webform module for Drupal 8. I mistakenly thought that I could do some research and become an accessibility expert. I assumed learning about accessibility was the same as learning a new programming language - you read a book, review the docs, write some code, throw out some code, refactor other code, learn about design patterns and - voila! - you now know a new programming language. I was wrong - getting up to speed on accessibility is very challenging.

Learning about accessibility can be overwhelming

Between screen readers barking text at you and massive well-thought-out guidelines, I discovered that understanding accessibility could be overwhelming. I thought I could enable VoiceOver, the screen reader built into OSX, and start using it. Instead, I was only able to digest VoiceOver in small five minute bites, trying to reckon one of the most challenging pieces of software I have ever used. I found myself empathizing with anyone with a disability attempting to navigate a website. Frankly, many people with disabilities are likely forced to give up trying to browse websites that don't care about accessibility.

My experience with just using a tool to assist with accessibility made me want to give up.

Why do I care about accessibility?

My difficulty loomed large enough that I considered coping out and seeing if I could just do a general Webform presentation at Design4Drupal. There are three other accessibility related sessions scheduled, and I am willing to assume that these presentations are going to be more thorough and educational. But that thought nagged at me and I wasn’t so sure I wanted to relent in defeat. My hesitation made me ask myself why I was doing a presentation about accessibility in the first place, and the answer became the below slide in my presentation.

About Me & Accessibility - I know accessibility is important. I chose to ignore it for years. I now have a responsibility to address it.

About Me & Accessibility - I know accessibility is important. I chose to ignore it for years. I now have a responsibility to address it.

I realized that I had a responsibility to address accessibility and I was determined to make a presentation that explains how I can discuss this topic. This led to the next slide and rendered an unexpected central theme to my presentation.

We don't have to accessibility experts. We just need to care about accessibility.

We don't have to accessibility experts. We just need to care about accessibility.

Of course, the purpose of my presentation is to begin the ongoing process of addressing accessibility within the Webform module for Drupal 8.

Learn more about accessibility

If you can make it to Design4Drupal, please attend my presentation and/or the three other presentations about accessibility.

If you can't make it to my presentation, you are in luck because one of the things I do to prepare and practice my presentation is record it. You can watch my rehearsal presentation and review my slides below. If nothing else, it’ll show that while I am no expert, I do care.

View and Download Slides

Get involved with accessibility

The most important thing that I want people to take away from my presentation is that they need to care about accessibility. You don't need to be expert to get involved.

Here are some places to start learning about accessibility and getting involved.

Almost done…

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

OKSubscriptions powered by Strikingly

Jun 11 2018
Jun 11

These are some of the ingredients that can make open source sustainable

The title of this blog post, "Project Management + Estimation + Mentorship = Sustainability" does not represent an exact formula for solving the challenges of open source sustainability. It establishes what I feel are the ingredients to a recipe that could significantly improve the sustainability of open source projects. To discover the right recipe for sustainability, it is key to define sustainability.

Defining open source sustainability

Open source sustainability is the ability of a community of people and organizations to collaboratively contribute to software that is freely available for anyone to use and alter.

The above description could sound like a standard cooperative or partnership agreement except that the General Public License (GPL), attached to most open source projects, makes the product of this arrangement entirely free for anyone to use and alter. This is the challenge of open source sustainability: the result of our labor, aka the product, is absolutely free. There is no doubt that people and organizations have found incredible value in open source software. But what is the value of the labor?

If no one owns something that is so important to us, how do we know that it will be cared for?

Personally, I am passionate about maintaining my project the Webform module for Drupal 8, because it is my baby. The reality is that our kids grow up and we need to make sure they are independent and healthy. We put in the time and effort because we consider it worthwhile and because we care. This parent/child analogy helps clarify the simple but key notion that everyone who contributes and is involved in open source cares about their project and community. People and organizations contribute a considerable amount of time to build and maintain their open source projects. It’s time and energy that could equate to money.

Time = Value = Money

Let's accept the reality that when a developer contributes to open source, they are typically taking time away for their paying jobs (and family) to write code, respond to issues, and even mentor contributors. Open source has added a massive amount of value to our work and society. Open source software is everywhere. It is on our devices and is used and relied upon by every tech giant.

Open source software requires time that results in high quality and valuable software, which has monetary value.

Money != Sustainability
(Money does NOT equal Sustainability)

When I was first starting thinking about how I could make my massive contribution to Drupal sustainable, I mistakenly thought money would automatically solve my problem. Money helps, but when money enters an open source collaboration things get more challenging to manage. One of the big takeaways from the Request for Commit podcast is that even when an open source project has funds, it’s complicated to determine how to distribute this money.

To properly propose, collect, track, distribute, and manage the funding of open source projects there needs to be a process.

Process = Sustainability

We are a community of people contributing to a vast collaboration, and this collaboration is defined and driven by our process. The fact that Wikipedia’s definition of 'Software maintainer' originates from Open Source software says so much about our process.

In free and Open Source software, a software maintainer or package maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in a source repository.

-- https://en.wikipedia.org/wiki/Software_maintainer

The role of software maintainer does not exist unless people contribute patches to be committed to the project. Software maintainers are mentoring contributors when they are reviewing patches. We are all mentoring each other when we review someone else's patch.

Everyone needs a mentor, and everyone is a mentor in open source.

Mentorship is what grows open source

Mentorship is a relationship in which a more experienced or more knowledgeable person helps to guide a less experienced or less knowledgeable person.

-- https://en.wikipedia.org/wiki/Mentorship

Mentorship helps to encourage high-quality contributions while also growing the community around open source software. It is essential that we embrace this very basic aspect of opening source development. Mentorship and code review is something that everyone understands and values.

Code review ensures quality and security. Organizations generally trust open source software because they know that multiple people review patches and pull requests before they are committed, and everyone is continually reviewing the code after it has been committed.

Open source communities need to leverage the fact that all code is peer-reviewed before and after it is committed to a project, especially when approaching organizations to fund and contribute to open source projects.

Getting organizations involved in funding and contributing to open source is crucial to improving sustainability.

Organizations need to be involved and committed to open source sustainability

Initially, I thought that leveraging the importance of mentorship and peer code review would inspire everyone to help fund and sustain open source. My mistake in this approach is that it is only applicable to people and organizations who understand and are involved in open source - they already care about and value mentorship and code review. The real challenge for improving open source sustainability is getting people who are not involved, yet rely on open source, to start contributing and funding the open source projects on which they depend

The more we can inspire people and organizations to become involved in open source the more sustainable we will make our projects and community.

How do we get people and organizations more involved in open source?

I found that the only way to begin answering this question is to step into the shoes of people and organizations who are not part of open source. One of my most immediate conclusions was…

People and organizations need tangible results to justify contributing to open source.

It is entirely fair for anyone being asked to contribute to open source to question what do they get in return. Sorry, but "free software" is too vague of an answer and there are some fantastic articles and blog posts that do provide great arguments as to why people should contribute to open source. Generally, we tout the benefits of contributing to open source and every project, including Drupal, offers ways to get involved. Open source development is a different process than what anyone is accustomed to in their regular day-to-day education or employment. Open source projects tend to not have tightly structured organization charts, hard deadlines, salaries or holiday bonuses. There are certain aspects of how businesses work that undeniably make sense and help everyone get their jobs done in a productive and happy work environment.

People and organizations need a tangible process to contribute to open source.

Yes, open source is a different process which changes from project to project. Two things I found that were typically under-recognized in most open source projects is the importance of project management and estimation.

We are underestimating the value of estimation

Estimation helps set reasonable expectations

Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.

-- https://en.wikipedia.org/wiki/Estimation

My last blog addressed, "Are we afraid to estimate our work in Drupal and Open Source?" and I hope the biggest take away is that estimation helps set reasonable expectations that make it easier for people and organizations to get involved in open source. Improving estimation within our open source projects would remove the "incomplete, uncertain, or unstable" aspects from our work. Estimation, even incorrect estimation (there will undoubtedly be trial-and-error periods), allows everyone to better understand the amount of work that needs to be done and the money required to accomplish it.

Discovering and improving how we collaborative estimate within open source would make everyone's experience more enjoyable and productive. I want to emphasize that anyone who gets involved in open source should have an enjoyable and productive experience

Excellent and thoughtful project management is what ensures that everyone is productive and happy.

Project management helps people be more productive and happy

Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time.

-- https://en.wikipedia.org/wiki/Project_management

Open source software is created via a massive team effort from people spread out across the globe. We have created a process where people collaborate to develop high quality, valuable, and secure products. Along our journeys to develop open source software we have built amazing communities that consists of more than just developers, and include people from every role in the software industry. Generally, open source does attract more developers because they write the code.

I am one of those open source software developers. I value my experience within open source but I have also come to understand that open source software is more than writing code - it is about the process of contributing code to a community.

The open source process has some major problems. Personally, at the beginning of this year, I recognized the risk of burning out and recently wrote about offboarding contributors. My post concluded with the realization that improving how we manage our projects and how the role of project management is going to keep open source communities healthy and sustainable.

Besides keeping people within the open source community prosperous, better project management will make it easier for people and organizations outside of open source to become members of our community.

Estimation combined with project management makes it easier for people and organizations to contribute to open source

Let’s acknowledge that Drupal is being used to build enterprise applications for some very big organizations. Some of these organizations have the potential to bring their game-changing resources to our community. Fortune 500 companies can easily contribute a few hundred thousand dollars to Drupal and open source. And some do because they see it as an investment. Frankly, I think the only thing limiting more organizations from investing in Drupal is the fact that it is hard for them to understand precisely what they will be getting for their money. Estimation would help them in that regard.

I am willing to go a step further and say that…

Better project management will increase the level open source contribution from existing contributors.

1 Project Manager = 100 contributors

Open source projects are always looking for new contributors. Open source disproved the notion that adding more developers to a project does not increase productivity. Still, open source needs to pay attention to everyone’s experience when contributing to open source. Thoughtful and excellent project management can make the difference between a developer making one contribution vs. a developer making a sustained ongoing contribution to an open source project.

I have personally seen numerous times how a good project manager can mediate conflicts and negotiate resolutions with our community. Project managers make sure developers don’t burn out while making sure a stakeholder's needs are addressed.

Project managers can help ensure that people and organizations get tangible results when they contribute and support open source.

Showing the value of project management (and leadership) in open source

Gábor Hojtsy, the multilingual initiative lead for Drupal 8, learned and shared his incredible experience, scaling Open Source projects, how 1300+ improved Drupal 8’s multilingual features. His leadership shows how careful project management can get people involved and providing sustainable contributions to an open source project.

Addressing the challenges of mentorship, estimation, and project management

To improve sustainability within open source we need to address a few challenges.

First, we need to explore how to make sure people and organizations get the most out of their experience when contributing and funding open source. Encouraging mentorship fosters a healthy interaction between software maintainers and contributors. Estimation sets reasonable expectations for people and organizations working within open source.

Secondly, I strongly feel that improving and valuing project management is the unrecognized secret sauce to growing open source communities and ensuring that people and organizations have a positive and sustainable experience.

Finally, open source communities must respect that some organizations need to see tangible results when contributing and funding open source software.

Recipes require taste testers.

This recipe, 'Project Management + Estimation + Mentorship = Sustainability' is going to require some more thought, experimentation, and tweaking. This summer I am going to do a more in-depth exploration of the recipe and open source sustainability.

For now, I would love to get your first impressions and thoughts in the comments below.

If we consider all the projects we’ve successfully collaborated on thus far, it’s a no-brainer that we can come up with some pretty great solutions when it comes to estimation too.

By this Fall, I am hoping we can try out some new sustainability experiments

May 30 2018
May 30

Estimation is not a new concept nor is it a bad word.

Estimation is not a new topic for anyone in the Drupal or open source community. We do it every day at our jobs. We even discuss estimation techniques at our conferences. We provide our clients with estimates when building and contributing back to open source project, yet we don't include estimations within our open source community and issue queues.

We all provide estimates to our clients - are we afraid to do it when it comes to Drupal and Open Source?

Before we take on this tough question, 'Are we afraid to estimate our work in Drupal and open source?', let's start off with a straightforward question: 'Why do we provide estimates to our clients?' The answer is just that our clients want to know how much something is going to cost and we want to know how much work is required to complete a project.

To give this discussion more context, let's begin with a very general definition of estimation

Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.

-- https://en.wikipedia.org/wiki/Estimation 

Here’s my hypothesis:

The lack of estimation in open source is hurting the onboarding of new contributors and the ongoing sustainability of our projects.

The Science of guessing - Drupal estimation techniques from project managers

While researching estimation within the Drupal community, I found a bunch of great presentations about project management and estimation. To me, "The Science of guessing - Drupal estimation techniques from project managers" by Shannon Vettes (svettes), Jakob Persson (solipsist), and Mattias Axelsson (acke), was the most comprehensive and inspiring presentation. Feel free to watch this presentation. I am going to pull a few slides from this presentation to help move through this exploration.

Every presentation I watched focused on estimation concerning managing expectations for client/employer based projects. Yet, no one addressed estimation within our open source projects.

Open source projects are afraid to estimate because everyone is working for free

I know the above statement is a broad generalization but until only a few years ago one of most popular credos in the Drupal community came about when it came to the release of next version Drupal. It was/is…

It will be ready when it is ready.

I am glad to say this policy is no longer applicable to Drupal core because the community has committed to regular six month releases. Still, I feel we struggle to commit to specific deadlines. Yes, we have rough timelines for when core strategic initiatives might be completed, but the truth is these timelines are guesstimates because as a community we don't include any estimations within our issues queue or process. We don't have any accurate metrics tracking productivity, velocity or return on investment.

For example, a few years ago our community came together to create the Drupal 8 Accelerate Fund and it is worth asking some general questions about that collaboration.

Was the Drupal 8 Accelerate Fund successful? What was the return on investment? How much work was completed for 2,500 man hours at $100 per hour?

A general question for the Open Source community is...

If an open source project began to collaboratively and publically estimate tasks, would we be able to give accurate timelines and roadmaps?

Maybe we don’t know where to begin but we have to begin somewhere. To get answers, we have to ask the questions.

I want to emphasize that I am criticizing our process and not any individual, team, or organization. I am asking a tough question because I want us to solve the problem of sustainability. Building and sustaining an open source project has a cost and we need to know what that cost is.

How has not providing estimates impacted our open source projects?

Personally, I have seen how the lack of estimation has impacted the Webform module's issue queue. I have seen incredibly challenging tickets that lacked a clear estimate of the amount of work to be taken on by someone, only to see them become frustrated because they are unable to complete the task. I have patches in the issue queue for tasks that are so complex I don't have time to review the code. My failure to estimate specific tickets has led to another common problem that estimation helps to address, which is breaking down complex tasks into smaller more manageable steps.

If the Drupal community wants to get big and small businesses involved, we need to be able to provide realistic estimates. We need to have real and practical examples - to be able to say based on our community's history and these statistics, if you give X dollars, we can complete this initiative or task which will help benefit your business.

We don't need to be afraid to ask people to estimate as long as we all acknowledge that everyone's level of commitment is going to be different. Open Source projects generally employ no one. We would need to collectively discover the best estimation technique while factoring in a realistic level of commitment that a developer or business can make to completing an open source task. And yes, we also need to track how funding impacts an open source project.

How would estimation benefit open source projects?

The below chart from 'The Science of Guessing - Drupal estimation techniques from project managers' shows how estimating the value, effort, and risk helps everyone understand what work needs to be done and what probably does not need to be done

Estimation: Why do we need them?

Estimation: Why do we need them?

For me, the sweet spot, low-hanging fruit are easy to complete tasks, and an essential quadrant for onboarding new contributors and keeping existing contributors engaged, especially if they only have a few minutes available to contribute. Personally, I always start out my work week going after a few easy tasks before taking on the more challenging tickets which bring a lot of value to the Webform module.

Some great examples of low-hanging fruit are documentation, patch reviews, minor user interface tweaks, reviewing and improving test coverage. Realistically we need to break down complex tasks into simpler easier to complete tasks and user stories.

Having estimation in our open source issue queues will make it easier for people, organizations, and companies to get involved.

Businesses and organizations need to know how to plan, budget, and communicate what it costs to contribute to open source

Estimates help us: Plan, budget, and communicate

Estimates help us: Plan, budget, and communicate

I persuaded my main client Memorial Sloan Kettering to become one of the largest earliest adopters of Drupal 8. The Memorial Sloan Kettering website was built while Drupal 8 was still in alpha releases and launched on a beta release. Memorial Sloan Kettering did contribute code back to the Drupal community but it was difficult to plan and budget for funding any module upgrades from D7 or D8 because project maintainers tend not estimate how much is required to upgrade a module. We worked with guesstimates and managed to upgrade a few modules.

Imagine if we were able to provide reasonable estimates, based on historical information combined with a collaborative methodology, to organizations. Imagine being able to say to company A if you allocate X dollars to this specific open source initiative, project, or task, we can accomplish B features.

So let me put my dream into a real-world context; every organization in the EU needs to comply with the General Data Protection Regulation (GDPR) and make sure that they are protecting their users' data while making this data available and portable to each user, and ultimately deletable. This is a very broad generalization of the GDPR but to comply with these regulations, there are going to have to be several improvements made to the Webform module. These types of features could be broken down into individual tickets with collaborative estimates so that organizations can allocate resources and/or funds to help themselves and their community comply with the GDPR. BTW, Drupal core is facing the same exact challenges with GDPR.

How could we collaboratively estimate in our open source projects?

There are many different techniques for estimating. The only concrete requirement that I feel is a must is that we use collaborative estimation technique.

3 Example Techniques: Ball Park Top-Down, Weighted Estimate, and Delphi Methods

3 Example Techniques: Ball Park Top-Down, Weighted Estimate, and Delphi Methods

Personally, I like the concept of planning poker which is a form of the delphi method.

Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development.

-- https://en.wikipedia.org/wiki/Planning_poker

I also like using story points to scope out the overall level of effort required for a ticket.

A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

-- http://www.tothenew.com/blog/how-to-estimate-story-points-in-agile/

Even being able to categorize and label tickets as easy, medium, and hard could make a big difference. Currently, in our issue queues on Drupal.org we can apply these types of tags to tickets, but users have to use the advanced search to filter by any tag. It’s not reasonable to expect a new contributor looking for an easy ticket to use an advanced search.

We also need to collaboratively calculate the value of our tickets

So imagine if you have been using Drupal for a few years and finally wanted to contribute something back to the community, and started looking for something to do. You find a task that several people have marked as easy to do and also provides a lot of value. Even if you have questions or run into a problem with the task, you might find a mentor in one of the people who helped estimate that ticket.

What challenges should we begin to collaboratively estimate?

Every GDPR task is going to provide a lot of value to organizations in the EU. Personally, I feel it is also important that we start recognizing the inherent and ongoing value in improving accessibility in our software.

Frankly, there are probably feature requests in the Webform issue queue that I do not see the value in and people are not able to collaboratively communicate the need and importance for these features. For instance, I am not actively doing any headless Drupal work; I am not sure of the value of improving the Webform module's REST API's. I guess that specific organizations see a lot of value in using the Webform UI/UX to build form's which can be served via a REST or JSON API.

What is my key point?

We need to stop guessing the value and work required to complete a task. We should collaboratively determine the value of a task and estimate the amount of work necessary to complete the task. Understanding the value, effort and cost required to get things done will make it easier and more rewarding for individuals and organizations to get involved and stay involved in open source communities.

How can we make estimation happen in our communities

What affects estimation? The Usual Suspects

What affects estimation? The Usual Suspects

I knew I had to include the above slide for the presentation in this post because it portrays the challenge of getting people, especially developers to provide reasonable estimations. Developers tend to suck at estimating which is why the role the project manager exists. Project managers are the keepers of the process. My last blog titled 'Our journeys within our community,' I concluded with the realization that project managers are one of the key roles in our open source community. When it comes to addressing the challenge of estimation within our open source project they are the best qualified to help define and discover the best technique to estimate our work collaboratively

Good estimation happens when there is a good discussion followed by some agreement and action.


Since this blog post began with the hypothesis that, "the lack of estimation in open source is hurting the onboarding new contributors and ongoing sustainability of our project", it must end with a conclusion.

It's hard to conclude how the lack of estimation is hurting our projects because we don't have a concrete metrics to work with, except the fact that everyone is relying on and contributing to open source.

To improve open source sustainability we need to examine our process and how we collaborate to create open source software. Estimation is a key part of the process of building software.

We need to determine the best recipe to sustain and grow open source. My most recent blog posts have circled around the problem and challenges of sustainability. I feel the below formula/recipe could help us solve the problem of sustainability.

Project Management + Estimation + Mentorship = Sustainability

Examining this formula will be the topic for my next blog post.

Almost done…

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

OKSubscriptions powered by Strikingly

May 16 2018
May 16

To begin to address sustainability in Drupal and Open Source, it’s important to explore our journeys within the community. We need to examine how we work together to grow and build our software and community.

This is going to be one of the most challenging blog posts I have ever written because I am uncomfortable with the words: roles, maintainers, contributor and mentoring. All of these words help establish our Open Source projects and communities. Over the past two years, while working on the Webform module I have learned the value of how each of these aspects relates to one another and to our Open Source collaboration and community.

Why am I uncomfortable with these words?

I am uncomfortable with these words because my general mindset and work habit are very independent and individualistic, but living on this island does not work well when it comes to Open Source. And changing my mindset and habits are things that I know need to happen.

Like many programmers, I went to art school where I learned the importance of exploring and discovering one's individual creative process. Another thing I had in common with many people who went to art school - I needed to figure out how to make a living. I went to the Brooklyn Public Library and started surfing this new thing called the World Wide Web. I was curious, confident and intrigued enough to realize that this was something I could and wanted to do - I could get a job building websites.

I built my first website, http://jakesbodega.com, using MS FrontPage while reading the HTML Bible and tinkering on a computer in the basement of my folks’ big blue house. After six months of self-teaching, I got my first job coding HTML at a small company specializing in Broadway websites. Interestingly, with the boom of the Internet, everyone's roles were constantly changing as companies grew to accommodate more and more organizations coming online.

My first experience with the notion of a Content Management System (CMS) was completely breaking a website by deleting a single server-side include. Sadly, what followed was the technology lead not seeing my mistake as an opportunity to teach and mentor me, but to ridicule me for not understanding that a server-side include is just a directive to pull the content of another file into the current file. BTW, I take pride in being a member of a community where the notion of ridicule is never accepted - there’s truly nothing to be gained from it. Rather, the worst response one might get is a link to https://en.wikipedia.org/wiki/Server_Side_Includes.

This negative experience made me buckle down, buy more books, and take the mindset that I’d just figure it out, which I did. I literally built a custom CMS, called the Inettool, from scratch using ASP/JScript. When I recall that experience, I still wish that I’d had a better role model who understood their responsibility and role as a technical lead and mentor.

Discovering Open Source and Drupal changed my mindset. Besides not having to maintain a custom CMS, I am still in awe of the roles and responsibilities that people take on in the Drupal community.

Understanding the roles in open source

My son Ben, who you met in a recent blog post, and I recently listened to Command Line Heroes: OS Wars_part 1. Besides comparing Linus Torvalds to Luke Skywalker, which immediately hooks any twelve-year-old, the host, Saron Yitbarek, does a great job explaining how everyone thought the Open Source experiment, Linux, would fail. How could developers come together to build a free Operating System? Looking back now, the answer is that somehow developers took on different responsibilities and worked together to define new roles, including the concept of software maintainership and contribution.

The importance of the software maintainer

In free and Open Source software, a software maintainer or package maintainer is usually one or more people who build source code into a binary package for distribution, commit patches, or organize code in a source repository.

-- https://en.wikipedia.org/wiki/Software_maintainer

Wikipedia's description of a software maintainer is very intriguing because the role of a maintainer is being explicitly defined for Open Source software, however the rest of the description is very technical with no mention of mentoring or fostering a community around Open Source software.

In the Drupal community, we all understand and appreciate the value of core and contrib project maintainers. I think it’s pretty evident that I take the role and responsibility of being the maintainer of the Webform module very seriously. And though I receive a lot of appreciation, the reality is that the role of being a project maintainer can be exhausting. The role of maintaining a project is not just about writing code. I’ve probably earned most of my commit credits by just responding to general support questions and welcoming people in the Webform issue queue.

I really enjoyed Jeff Geerling’s (geerlingguy) presentation Just Keep Swimming: Don't drown in your open source project! because it explores, "the problems maintainers deal with on a daily basis, and equips you with tools to reduce the number of problems in the first place!"

I particularly appreciated Geerling’s dissection of the different types of contributors. I am continually discovering new types of contributors, and I never cease to be amazed how someone can glance at something as complex as the Webform module and solve bugs that have dumbfounded me for months.

Everyone is a contributor

Conceptually, everyone in Open Source is a contributor, they just operate at different levels. As a project maintainer, I am contributing to Drupal's module ecosystem. Someone speaking at an event about Drupal is contributing to the general awareness and education of people in our community.

If an Open Source project does not have contributors, it’s just code that is freely available. The notion that everyone is able to contribute is the force that binds our community together. We should never forget that contributors may one day become maintainers.

Mentorship is what grows our community

So I have to confess: I have never attended a code sprint. And my comfort zone of working independently means I am very uncomfortable with the notion of sitting in a room with other people writing code. For lack of a better phrase, I get "code sprint fright."

Code Sprints - DrupalCon Boston

Code Sprints - DrupalCon Boston

Drupal Sprints - DrupalCon Baltimore 2017 - Michael Cannon

I now see the importance of code sprints. They bring our community together and strengthen our collaboration. If I really want the Webform module to grow, there is a limit to how much code I can write and maintain, however, there is an unlimited number of people available to help me write and maintain this code. If I ever want to step away from maintaining the Webform module in a responsible way, I need to mentor contributors who can take over the reins. I need to conquer my "code sprint fright."

When Leslie Glynn (leslieg), who is organizing the Design4Drupal (June 27 - 29), asked me if was going to attend the code sprints, I explained my fear of coding in public and she pointed out that I don't have to code at a sprint; rather, I can share ideas and help people solve their coding problems. It seemed like a great suggestion to ease me in. She made me optimistic that I can overcome this major personal hurdle.

I know mentorship and collaboration is the key to Open Source's success and it’s the most important thing we need to protect while working to make Open Source sustainable. The most important and underacknowledged role that makes Open Source happen is the project manager.

The most important and underacknowledged role: the project manager

Like most developers, I’m guilty of only seeing and discussing our process and community through the lens of someone who writes code. After this examination of roles, maintainers, contributors, mentoring, and process, I’ve realized that I have ignored what might be the most important and under acknowledged role in our community: the project manager.

When I look back at the problems and challenges I have discussed including on-boarding, contributing, and off-boarding, the role that is going to have the biggest impact is the project manager. It’s the project manager who can coordinate everyone’s efforts while also ensuring that everyone is successful and happy. It is important to acknowledge that project management is a distinct and important role, which most maintainers do while also reviewing patches and wrangling an issue queue.

Final thoughts

I knew when I began writing this blog post that mentorship is key to improving Open Source sustainability. I did not expect to conclude that the role of project manager is what makes everyone's journey in Open Source possible, healthy and sustainable.

We need to reevaluate the simple notion that adding more developers to an Open Source project will improve its productivity and sustainability. At the same time, we need to realize that the role of a project manager is what coordinates and defines the process that builds successful and sustainable Open Source projects and communities.

Almost done…

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

OKSubscriptions powered by Strikingly

May 07 2018
May 07

People come and go from open source projects and communities

Most people would agree that everyone should contribute something back to Open Source at some point in their careers. We have to realize that an ongoing Open Source contribution to a project can't be sustained forever. We might graduate from college, get a new job, need a break to travel, have kids, help raise grandkids, retire and even get bored with a project. While we need to improve open source sustainability, we also need to accept the reality that people continually come and go from open source projects.

Developer burnout should not be part of open source

Up until recently, I felt that 'burnout' was the only talked about method when people left the Drupal community. Up until DrupalCon, I thought that once I committed to supporting something, like a module, I was obligated indefinitely or at least until I burned-out from supporting it.

In my new year blog post title, Webform, Drupal, and Open Source...Where are we going?, I stated…

I am destined to burnout

...and I don't think I am the only one.

Are we expecting too much?

Jeff Eaton's presentation titled "You Matter More Than The Cause" addresses burnout and how it impacts the sustainability of teams and he says…

"Everyone was expected to give a 110% and one-hundred and ten percent is not a real number."

I think we need to stomp out the concept of developer burnout in Open Source and equate developer burnout to poorly-managed companies and organizations.

Planning an exit strategy can prevent burnout

One of many valuable lessons I learned at Adam Goodman's Teamwork and Leadership Workshop at DrupalCon Nashville was that it’s okay to plan an exit strategy, it’s even something that can ultimately help the community and potentially prevent burnout.

"Planning an exit strategy" means defining specific limitations around your responsibilities and commitments to complete a task. This helps everyone plan for the succession of duties. Adam's personal example was that before he took on the role of being the Chair of the Drupal Association Board of Directors he wanted the commitment to be for a defined amount time.

Personally, I have decided that every task that I do in the Drupal community should include an exit strategy before I commit. When offering to help get an 'About Drupal' content section in core, I have committed myself to getting the initial content and section built while needing to get more people involved to help iterate and improve the content moving forward.

Growing our tribes can create sustainable and healthy micro-communities

For Open Source communities to be a healthy ecosystem, we need to acknowledge the life cycle of our projects and people. New people join our community every day while other people regularly leave our community for new challenges. Since our community and ecosystem is built on people's commitment and passion, we need to think about how we grow and sustain our 'tribal' community.

Shannon Vettes’ presentation titled "Growing Our Tribes: Creating Sustainable Micro-Communities in Drupal and how you can help" about DrupalCon Nashville succeeds in defining a tangible approach to improving how our community works together and collaborates. Shannon is applying the concepts behind tribal communities to build more sustainable 'micro-communities' in Drupal and open source. Simply put, Drupal is huge and daunting to everyone involved. No one can understand or contribute to every aspect of Drupal, which is why we need to recognize that different aspects of Drupal like committees, project initiatives, contributed modules & themes can be thought of as micro-communities and tribes.

Shannon's project management perspective is essential to helping us solve the sustainability problems around open source software. I have concluded that technology alone is not going to solve the challenge of ongoing sustainability for open source projects. I feel that content and process is what will make open source projects more sustainable. I have begun to talk about Content First, Technology Second, seeking to add some messaging about the Drupal community into Drupal the software's user experience. For me, Shannon's presentation gets to the heart of what defines a successful open source community, the connections between people and how they collectively work together.

I love that she emphasizes the need to acknowledge what I want to call the three phases of contributing to open source.

  • Onboarding: The process of getting involved.

  • Contributing: The process of productively contributing.

  • Off-boarding: The process of winding down one's involvement.

I feel as a community we have always thought about how people contribute and we are re-addressing onboarding process by improving our evaluator experience, but we are not fully addressing the off-boarding process. And we need to because how we off-board people can have a positive or negative impact on the overall health of our community.

Each one of these phases requires a dedicated blog post, DrupalCon presentation, and maybe even a dedicated core initiative and team. For now, I want to talk about how we say goodbye.

What are we communicating about offboarding on Drupal.org?

Finding new maintainer or co-maintainer for your project and dealing with unsupported (abandoned) projects are the only pages that I am aware of that begin to address what happens when people leave the community.

I am not sure we need a "How to abandon a project" page on Drupal.org but maybe we need to look at documenting the open source contributors journey from beginning to end and make this part of the user experience on Drupal.org and maybe even in Drupal's (the software) user experience.

Documenting the open source contributors journey

Chris Albrecht's presentation title "Managing Your Most Important Resource: You" from DrupalCon Nashville explores Albrecht’s journeys within the Drupal community. He tells his very personal story about getting involved in the Drupal community, experiencing burnout, attending DrupalCons, maintaining a module and even not maintaining a module. He concludes with offering really sound advice on how to adjust one's priorities when working in open source and life.

Before we ask someone to get involved in Drupal, we should talk to them about the overall journey into Drupal and open source software. This journey should be about being human, being part of our community, and highlight members of our tribes & micro-communities - not about fixing bugs and reviewing patches in an issue queue.

Along the way we should tell people..

It is okay to plan an exit strategy, we are here to help and listen if you need break, and it is fine to say goodbye.


There is some irony that my last two blogs posts were about saying "Hi" in Drupal (the software) and at my local Drupal NYC meetup and now this blog post is about saying "Goodbye". Saying hi and bye is about communication and if it is done right, with some empathy, we can strengthen and grow our tribes. Goodbyes should be built into the equation, viewed as something that could potentially have to or need to happen along the way, and not something someone does - or doesn’t do - as a result of burnout.

Almost done…

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

OKSubscriptions powered by Strikingly

Apr 30 2018
Apr 30

The importance of welcoming people to the Drupal community

Our meetups and in-person interactions are where we welcome and include new people in our community. Of course, people come and go from every community; new faces bring new ideas and innovations.

Everyone has a story about the first person they met in the Drupal community.

At the beginning of DrupalCon Nashville at the Community Summit, someone told a story of how they attended a meetup and literally no one talked to them or even really acknowledged their presence. As a result, the individual never returned to that meetup. Organizers of meetups absolutely need to make a concerted effort to make sure that everyone who attends is - minimally - welcomed and acknowledged - that is community-building 101. This story really sat with me because it made me question whether I’m doing enough at the local NYC Drupal Meetup to make people feel welcomed and included.

Remembering who welcomed me to the Drupal community

I ran into Robbie Holmes (robbiethegeek) at DrupalCon and standing in exhibition hall, we reminisced about how he was the first person who welcomed me to the Drupal community. An interesting fact about our relationship is that we grew up around the corner from each other in Brooklyn and knew the same people, but met for the first time in the Drupal community. For many years, Robbie, with the help of others in the community, would always offer to split off from the general, sometimes very technical discussion, to offer a newbie discussion where people new to Drupal can ask them anything and get help. To date, Alexander Ross (bleen) was initiating these discussions at the NYC Drupal Meetup, but it is not reasonable to expect one person to be responsible for welcoming people to the Drupal community.

We all need to start welcoming people to our community.

So, I am going to commit to helping ensure that our "Welcome to Drupal” discussion happens at every local NYC Drupal meetup and make sure that I am not doing it alone. Luckily, I have plenty of friends in the NYC Drupal community who would be okay missing one or two discussions to help me welcome people to our community.

What are three immediate things I can do at the NYC Drupal meetup to welcome people

As many people know, I have included the Contribute module's message into the Webform module and even have a few slides about "How can you contribute to the Webform module & Drupal?" in my DrupalCon Presentation titled "Webform: There is this for that". After my experience at the Community Summit and several great conversations with people at the conference, I decided to step back from the Contribute module's message and think about what is the most important thing that needs to be said to people new to Drupal. At 5 AM, the day of my presentation, I decided to include the below animated slide, which starts off with saying "Hi". BTW, please read my last blog to understand why I feel saying "Hi' is important.

Hi! Welcome to our diverse & inclusive community! How can we help you? Here is how you can get involved.

Hi! Welcome to our diverse & inclusive community! How can we help you? Here is how you can get involved.

Welcome to our diverse & inclusive community!

In addition to saying the oh-so-important “hi”, including the words, diverse and inclusive, when we welcome people and in our software's user experience could have a profound impact. It will definitely distinguish us from other communities. The reality is that these are just two extra words being added to our greeting, and we need to follow-up these words with real actions and meaning. We need to take it one step further.

How can we help you?

Saying "How can we help you?" is the easiest most direct way to break the ice and make someone feel comfortable and welcomed. It’s akin to saying, “hey, you matter and you have value.” Robbie and Alex are role models for the best approach to welcome people to a meetup, which is to say that we are hear to listen to the problems and challenges that you face and want to help you find solutions.

Here is how you can get involved

The 'Getting Involved' section on Drupal.org does a great job of welcoming people and directing them to all the different ways to get contribute.

As an open source project, we don’t have employees to provide Drupal improvements and support. We depend on our diverse community of passionate volunteers to move the project forward by working on not just web development and user support, but also many other contributions and interests (such as marketing, organizing user groups and camps, speaking at events, maintaining documentation and helping to review issues).

At Drupal meetups, I think there is specific opportunity to grow our communities diversity of speakers and presenters at local meetups, and even at DrupalCon by encouraging and helping people put together a presentation and practice public speaking. I really enjoy seeing people presenting what they are working on and/or what they love about Drupal. I personally remember that nervous shaky feeling of getting up in front of a group of people and giving my first case study presentation about Memorial Sloan Kettering Cancer Center. At the same time, I have seen the professional value of public speaking, and how valuable it is to have this noted on my resume and personal website. Including a bullet point on your resume that says you presented at local Drupal Meetup says so much to a potential employer, starting immediately with the fact that you are more than just a coder and you participate in the software community. The ability to communicate with others is key to growing and developing any community. Drupal is not an exception to this fundamental rule - no organization is. And it can only enhance what we have created to date.

Closing thoughts

Open Source has proven it can redefine how software is built and it has resulted in redefining how online communities collaborate. Now it’s time to make certain that everyone is invited, able, and comfortable enough to join our communities and even make them comfortable standing up and presenting in front of their fellow developers and get involved in our community.

Almost done…

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

OKSubscriptions powered by Strikingly

Apr 23 2018
Apr 23

Many years ago, I was going for a morning stroll in New Jersey with my dad. We walked past a complete stranger and my dad said, “Hello.” My parents are divorced and I lived (mostly) with my mom in Brooklyn, so I spent the majority of childhood in a place where no one says hello to strangers. I was bewildered so I asked him why did we just said hi to a complete stranger and he said...

Saying hello is easier than saying f*ck you.

That is truly what he said and I can honestly say, it is the one and only time I have ever heard Sheldon Rockowitz swear. He broke his polite demeanor to emphasize to me the importance of saying hi.

Fast forward 20 years. I am now a father and my four-year-old son is complaining that he has no one to play with. I point to the closest child his age and tell him to go up to the kid and say 'Hi, my name is Ben'. He did it and discovered the concept and value of initiating a greeting with a complete stranger. And he made a friend for the day at the playground.

Two years ago, we were on a summer trip in Montreal and hanging out in a playground. Like many parents, I was laying low on the sidelines, observing my child's interaction with other kids. Ben walks up to a kid on the swing set and says, "I am not sure what language to say ‘Hi’ in, but my name is Ben." Ben's natural ability to adjust his approach blew my mind because he not only found a way to communicate with a complete stranger who might not be comfortable speaking his language, but he also shifted his method based on what he knew - and this is equally important - what he didn’t know. Kids are the future, and they teach us valuable lessons all the time.

Ben taught me..

No matter how difficult or challenging it is to approach someone, you should still find a way to say to hi, to be the first one to launch a connection. And you should do that even if you’re not sure of what the outcome will be. Taking the risk means you’ll gain something; doing nothing adds nothing new.

The Drupal community and software needs to say "Hi" and make people feel comfortable

Improving the evaluator experience has become one of our communities initiatives. There are many approaches and plenty of awesome people contributing to improving this experience. Providing a single command to install & run Drupal is critical, however I feel that we the Drupal Community should not lose sight of the importance of saying "Hi" and making someone feel comfortable who is installing Drupal for their very first time. It’s something that only takes a moment but works wonders in easing barriers - it acknowledges your presence and opens the door, ushering you in. Helping someone feel comfortable with using the command line can be a make or break user experience. I have a huge amount of faith that the Documentation working group will collaborate and continue to provide a first-rate getting started guide. I hope after the initial patch is committed, we’ll aim to further improve the evaluator experience by congratulating someone on installing a piece of fantastic Open Source software for their first time using CLI, which by the way, means Command-line interface.

Hopefully, we can even take the time add some cool colors to the below message.

For anyone that is already a command-line ninja, the above message would only be seen once, but I would never expect a command-line ninja to be executing `drupal quick-start` because they have already progressed in their journey to installing Drupal using a recommended local server setup.

Making it easy for people to learn more about our community and our principles

Our community is massive, and Drupal.org is overwhelming. Many people have acknowledged the problem and Drupal Association's new Drupal.org homepage is now addressing personas to better direct visitors.

We have a great community and the below saying is part of Drupal's credo.

Come for the software, stay for the community

This was my experience ten years ago when I first downloaded and installed Drupal. I feel that we should recognize the comma between the "Come for the software" and "stay for the community" because it represents what I am going to call, "the journey from the code to the community." There is a problem in our code; it is not a technical one; it is content one. We need to value and think about every user experience and the messaging and content around every new feature we add to the software.

We are collaborating on creating the single most important piece of content in our community, it is our "Values & Principles" I want to ask you the community…

Where should our values & principles live?

We can learn a lot from other communities

Before DrupalCon Nashville, I blogged about the potential threat of WordPress. At DrupalCon Nashville, I attended the Community Summit, which was also attended by two amazing members of the WordPress community, Andrea Middleton and Jill Binder. They shared with the Drupal Community how WordPress organizes meetups and camps. Andrea and Jill demonstrated to me that Open Source communities should always collaborate and share ideas and solutions. Personally, in the Open Source world, I have come to view all competing projects as sibling projects.

WordPress has principles and they live in their code more specifically the software's admin user experience. Their approach is very straightforward and begins with a clickable logo in the upper right-hand toolbar which opens to a What's New, followed by Credits, Freedoms, and Privacy.

WordPress About Section

WordPress About Section

To use a Picasso’ism, we need to do more than copy this approach; we need to steal it (in a friendly way) and make it our own solution.

Community in Code

Before I even start discussing any possible approaches, I need to quote one of our values to help guide this discussion... 'embrace change'. In other words, here is my idea of how we get started: Let’s work together to make it better.

Personally, I feel that limiting this content to three key pillars of information is a better way to consolidate our information.

The three pillars I recommend are...

  • Getting involved in our community

  • Recognizing who is involved in our community

  • Discover our community’s values and principles

The Drupal logo should be the same drop logo as the one on Drupal.org. Wherever possible, we should pull content and design elements from Drupal.org.

Getting involved in our community

I am betting that aside from our values and principles, this going to be the most challenging content to create because it requires aggregating content from 100's of Drupal pages into a single page. Taking the new personas from Drupal.org's recently redesigned home page could help orient new and existing members of our community. For example, we should encourage developers to contribute code, marketers to help coordinate events and materials, and agencies to contribute and/or sponsor development.

Another feature we should learn from Wordpress is to promote upcoming Drupal events, especially DrupalCons, since we now know these dates so far in advance. Ideally, we should pull in a feed from Drupical but realistically we need to start with an MVP (Minimum viable product) approach and just link resources like Drupical, the Drupal Association newsletter, Drupal Planet, and Drupal Groups.

There is plenty of other content we can add to this page. We should focus on the immediate messaging and accept that creating and maintaining this type of content is an iterative process.

Who is involved in our community

I feel this could be a game-changing feature because we can visually give credit to core contributors and contributing organizations. We need to push ourselves on this page to give credit to everyone while inspiring new contributors and organizations to get involved.

We also need to highlight core initiatives; this will provide a clear statement that the "Drop is always moving" and we are continuously seeking to improve the software and grow our community.

Most people know that I am a passionate advocate of pushing people and organizations to support the Drupal Association. I also respect that some people have reservations about this. One thing I want to push for is that the Drupal Association staff deserves equal credit for their contributions to supporting Drupal.org and the Drupal community.

I am envisioning that each contributor has a card that says...

{name} does {work} for {project} and {works for company} and they like {something}.

Citing what someone is doing acknowledges their contribution. Recognizing their company (aka sponsor) helps improve sustainability. Allowing contributors to append something personal to their card adds a "being human" aspect to each profile. Further, recognition puts a name to the work, cultivates accountability and fosters a healthy sense of competition, it drives us all to do better and connects us in a way that anonymity never accomplishes.

For example, my card would say...

Jacob Rockowitz (jrockowitz) maintains the Webform module and likes Portuguese Water Dogs.

BTW, I wouldn't want my card to include a company because no one is currently sponsoring my work. Maybe in a (much) later iteration, we could add a 'sponsor my work' link to my card.

Let's admit that there is no better advertisement for a contributing organization than their company's name, logo, and URL in the software. BTW, I only want to see organizations that sponsor (aka pay or employ) an individual person contributing to Drupal, highlighted in core, hence why I want to call them a "contributing organization" instead of a "sponsoring organization".

I found it a little disconcerting that all the diamond sponsors of DrupalCon Nashville were hosting companies, but not all these hosting companies have an equivalent amount of developers contributing to Drupal core and contrib. If they have enough money to appear on stage at DrupalCon promoting their product, shouldn't they also be committing similar funds to writing the code?

Understanding and recognizing who is contributing to Drupal is a very challenging subject matter.

For now, I would like to clearly distinguish that "sponsoring organizations" are giving money to Drupal to get their name recognized and help to fund the Drupal Association ongoing work maintaining Drupal.org and the community, while "contributing organizations" are contributing resources, money and people to help support the ongoing development of Drupal. It is important to note that many companies sponsor and contribute to Drupal.

The question is not should they contribute, but how they contribute.

Discover our community’s principles and values

Our value and principles are still in alpha releases and they will be ready when they are ready.

I look forward to helping add our value and principles to this new user experience to Drupal core. At the same, it’s important that we don't rush the finalization of our values and principles.

I don’t have any strong opinions about our values and principles except to keep it simple. My friend, Kaleem Clarkson, made me realize that our written values and principles are just words on a piece of paper or a computer screen, which are meant to guide our community. Ultimately, it is what we do and how we interact within our community that make these words a reality. Our behavior is the true barometer of our values.

How can I help make this happen

The actual technical implementation of a clickable logo linking to three tabs is definitely a lot easier than any core initiative. I am 100% committed to making this happen. I know it is going to require several discussions and few iterations.

One of many valuable lessons I learned at Adam Goodman's Teamwork and Leadership Workshop was that it’s okay in Open Source to have an exit strategy, and it’s something that can even help the community. My exit strategy for this proposed "micro-initiative" is that I am committed to seeing a stable implementation in core while clearly stating that people will need to contribute and take over future iterations.

Getting some initial feedback

Please post comments below. Hopefully, everyone’s feedback can help me better define the problem, solutions, goals, and even the implementation. Once I have enough information, I will follow up by creating the needed ticket on Drupal.org.


I want to sell this idea to our community, and yes this may sound cliche, but our values and principles statement should be our Statue of Liberty; what followed the gift of the statue was finding a place to put it and an equally monumental effort to fund a pedestal. The most important part of this analogy is the Statue of Liberty represents freedom and is always saying "Hi" to new people entering into a safe harbor in a new place. Regardless of what language you speak, she’s greeting you, ushering you in, letting you know you are welcome and you have value. I’ve lived in New York City my whole life - her presence never ceases to inspire.

Statue of Liberty

Statue of Liberty

Finally, the one thing we, the Drupal community, should always seek to improve is how we...

Say “Hi” and welcome everyone to our diverse and inclusive community.

Thank you, everyone, for your feedback.

I have created a Google Doc scoping out the overall idea and have begun working on figuring out how best to proceed in adding this to the 'Drupal core ideas' issue queue.

Almost done…

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

OKSubscriptions powered by Strikingly

Apr 02 2018
Apr 02

Recently I read Why is Drupal now the second most-hated platform behind SharePoint? followed by the predictable Reddit discussion trashing Drupal. Every time I read someone's negative, yet reasonable, criticism of Drupal, I can't help but rephrase Winston Churchill's famous quote about democracy in the context of Drupal and Open Source.

Many forms of Content Management Systems have been tried, and will be tried in this world of sin and woe. No one pretends that Drupal is perfect or all-wise. Indeed it has been said that Drupal is the worst Content Management System except for all those other solutions that have been tried from time to time…

Churchill's defense of democracy came at a time when the notion of democracy was under a direct threat. Drupal and Open Source are not imperil in the same way, but the lesson Drupal and Open Source can learn from history is that it is essential to recognize, respond, and adapt to potential threats. Ignoring problems is the worst thing anyone can do.

Introspection and discussion is a significant part of our process to improve and affect change within Drupal. I am looking forward to Owen Lansbury's DrupalCon Nashville presentation called Have We Reached Peak Drupal?. I have seen a preview of his presentation and it puts Drupal’s current state into perspective while also looking at its future. If you want to learn more about the discussion around "peak drupal" you should also check out Dave Hall's blog post, "Drupal, We Need To Talk."

While building and maintaining the Webform module for Drupal 8, I have thought a lot about the future of Drupal and the Webform module.

How do we increase Drupal's adoption?

I no longer feel adoption is a Drupal 8 specific issue but rather it’s a general recognition that the CMS market is shifting and Drupal is adapting to it.

Drupal is no longer for blogs. I myself moved my website from Drupal to a SAAS based page builder solution, called Strikingly. Drupal is for more ambitious digital experiences and for every small Drupal 7 website that moves away from Drupal, we hopefully gain a more substantial and ambitious Drupal 8 website. Still, in this day and age, the fact that Drupal's usage statistics have been relatively flat for the past few years is troubling. Content Management Systems is a competitive market, and if a CMS's stats are not growing, it is essentially viewed as dying.

I don't feel Drupal is dying but I do know it needs attention. And considering how much passion and energy I have put into the Webform module for Drupal 8, I feel adequately informed to say that I do see some writing on the wall, and it says that...

Drupal needs to significantly up its game and adapt.

Yes, I have experimented with promotions and encouraging people to contribute back to Drupal within the Webform module. Before I started any of these experiments, I put a lot of energy into upping the Webform module's game by making sure that Drupal's Webform module competes directly with the other big proprietary and Open Source form builders. The Webform module strives to provide an out-of-the-box experience that is welcoming and demonstrates the real power behind the Webform module which are Drupal's API's and community. For example, including a list of community provided Webform add-ons helps people know there is a community contributing code and ideas. Webform might be the only module that includes help videos within the user experience. To me, the most important aspect of these videos is that I am able to put a voice and person behind the code which assures someone that there is a maintainer and a community that support this project.

Drupal needs to start showing the people behind to code.

Yes, Drupal is targeting enterprise website and organizations, but people are writing the code. Every person and organization contributing to a project should have their profile picture displayed on the project page. Right now, all I can do is beg that we figure out how to support videos on a project page so that our code can finally have a voice. The best example of why video is important is sitting on Drupal.org homepage and you can watch it below.

When it comes to Open Source Content Management Systems and form builders, WordPress is our most direct open source competitor, and we should look at the WordPress community to see what approaches work and what approaches don’t.

WordPress' growth is huge

WordPress' usage stats have skyrocketed and WordPress now powers 30% of websites. I feel that it's possible to boil down the success of most Open Source software to three things, people, code, and money. Simply put, successful Open Source projects are built by a community of people who write good code while having the resources to maintain and improve the project. "Resources" is a nice way of saying "money" which translates into people being able to make a living while contributing to a project. Money should not be considered a dirty word in our community. Just as the "Free Software" had to rebranded as "Open Source Software," we have settled on using the word "sustainability" instead of "money." We have to be realistic - people, code and money are all important elements and they all benefit and depend on each other to function best. Without any one of those elements, the other two suffer - each one is dependent and essential to the other.

WordPress has proven that they have a sustainable ecosystem because people are allowed to charge for plugin support. Before I go any further, I must emphasize that I am against charging for Drupal modules, yet I am open to any other approach to making Drupal more sustainable.

So WordPress has money and community, but frankly, some of their code is getting a little stale and needs to be reworked. This similar problem led to the Drupal community's major rearchitecting of Drupal's underlying codebase and the release of Drupal 8. WordPress currently has a considerable amount of technical debt, but they have to community and resources available to fix it.

Good code requires developers with resources

WordPress is becoming more ambitious

The most immediate example of the WordPress community fixing and significantly improving their product is the soon to be released Gutenberg page builder, which I was able to test drive in three clicks. The experience was nothing short of amazing. WordPress' Gutenberg page building experience is nothing new but every major plugin installed on my test site was immediately integrated into the user experience; adding a form to a page was two clicks. Gutenberg has the potential to dominate online page builders. At DrupalCon I look forward to learning more about what's possible with WordPress 5.0. I am willing to bet that form builders and fieldable entities are next.

WordPress has several powerful form builder plugins available, and few of them are earning serious revenue. I have spent some time looking under the hood at WordPress' form builders, and each implements its own Form API and data storage API. WordPress does not have anything like a Field API or Views, which is the backbone of Drupal's ambitious digital experiences. It seems fairly obvious that if a few WordPress form builder plugins combined their duplicate efforts, they would be able to create something similar to and as powerful as Drupal's Field API and Views. They have the people and money to do it - they just need to write code.

Drupal is no longer intended to be scaled down for small blog sites, but WordPress has the momentum to scale up to larger enterprise sites.

Drupal is already ambitious

Drupal is the market leader when it comes to building digital experiences for large websites. Every single Drupal core strategic initiative which includes API-first, Media, and Workflow are working to make Drupal even more ambitious. The only thing that is slowing these initiatives is resources (aka money, which should not have a negative connotation).

I met with several of the coordinators behind these initiatives. Across the board, they identified the need for faster feedback from Core Committers, citing that a lack of Committer time was often a barrier to the initiative's progress.

-- Dries Buytaert

Drupal has a huge community of developers striving to make it better. Most people are contributing in their spare time or as a secondary task to their job (which pays them money). Most people value and understand the need to contribute to Open Source, but the bottom line is that there is a finite amount of energy that can be committed when you can't be paid to do it. And yes, Open Source has to still contend with the mindset "why pay for something that you can get for free." Changing this mindset is a much broader and challenging discussion.

My experience with clients that value Open Source is that they have no problem paying for tangible features and improvements to Drupal. The challenge that I have seen is hiring and paying someone to contribute back Open Source can be awkward...

Paying Open Source developers is an awkward transaction

Frankly, I’m at a loss when someone is trying to pay for feature enhancement to the Webform module. From my perspective, as a module maintainer, it’s hard to assess the potential client's seriousness. Here are some of the questions I find myself asking:

  • How much do I charge?

  • Are they assuming that my hourly rate is less because I like working on Open Source projects?

  • Are they okay paying for automated tests?

  • What does the agreement look like?

  • How do I phrase all work completed will be considered Open Source?

Keep in mind hiring anyone is a little awkward, not to mention time-consuming, and this why freelancer sites like Upwork are trying to make this a little more comfortable. One very personal issue I have with sites like Upwork and BountySource is that these sites have a process that can create bidding wars which can become a race to the bottom vs. the merits and value of the provided services.

The gold standard for dealing with awkward transactions has to be Airbnb because they figured out how to make people comfortable sleeping on other people's couches. Before Airbnb, my experience staying at bed and breakfasts was a disaster - one particularly nightmarish stay resulted in me having an asthma attack because the proprietor forgot to mention that they have cats.

The most immediate lessons we can learn from Airbnb are:

  • A middle man can make an awkward transaction more comfortable for both parties.

  • Presentation is key - Airbnb did not start taking off until they helped improve the overall photography of their listings.

  • Rating and comments can make both parties more comfortable and remind people that they need to be kind to each other.

If you are curious to learn more about the not-so-secret sauce of Airbnb, you should check out the How I Built This podcast with Airbnb: Joe Gebbia.

Improving the sustainability and figuring how to handle awkward transactions is going to take a lot of experimentation. The most immediate thing we do need to do is accept that these discussions are going to be uncomfortable. And when we accept that about both ourselves and the other parties, when we realize that we’re all fallible, we can shift a bit at a time, learning as we grow and always trying to keep our eye on the prize - we’re trying to make something great even better. When we lay the groundwork as a safe place where the overarching goal is attempting success, over time discomfort wanes and growth can take its rightful place - the front seat.

We need to step outside our comfort zone

The general reaction I saw from my brief attempt to make the Contribute module a dependency of the Webform module made me realize that people are uncomfortable with change and yes, the dependency became awkward. The concept of finding one's comfort zone with Open Source is a tricky challenge. The Open Source community is vast, and every project or even the code base requires a different approach; every single issue queue is a different experience.

The moment we can acknowledge that something is uncomfortable we can get past it.

I am going to keep making myself uncomfortable

My approach is just to keep pushing myself into more situations that make me uncomfortable and to just work through them. Because the only way to get through something is to go through it, to experience it - not avoid it, not go around it but to go through it. In the last year, I have found my groove for speaking at Drupal events, and I do my best to attend any Drupal camp and meetup in my area. It didn’t start out that way, but over time and through actual experiencing, I’ve become more comfortable and confident. I am invested in the Webform module because forms are the gateway to user interaction and engagement on a website. I built the Webform module to compete with enterprise form builders while providing the flexibility and openness for Drupal.

If I genuinely want the Webform module to compete outside the Drupal ecosystem, I have to start reaching outside Drupal and maybe even the Open Source community, and begin to use the Webform module as a way to introduce people to the Drupal community and Open Source.

Growth and diversity in the Drupal Community and Open Source is not going to happen in the code; it requires outreach.

Reaching outside our community to increase growth

If we want to see Drupal grow in the enterprise market, we have to seek out new opportunities and clients. There is no question that Drupal is being used by organizations to build ambitious digital experience. There are always more untapped opportunities out there.

A few weeks ago, the team at Nextide (www.nextide.ca) gave me a demo of their workflow engine/solution module called Maestro which leveraged the Webform module. There is a core initiative for improving Drupal's content moderation and workflow which is going to make it easier for content authors, reviewers, and publishers to manage content - Maestro's workflow engine/solution is for managing complex business processes. It was hard for me to fully understand these differences until Nextide walked me through their "Insurance Quote Request" demo site. A webform is being used to collect insurance quote requests, which triggers the complex business workflow of connecting with underwriters and allowing applicants to select an insurance quote. Besides just seeing another example of an excellent module available for Drupal 8, their demo showed me how Drupal with Webform and Maestro could tap into an entirely new market/sector… insurance rate quotes.

Drupal, the Webform module, and our community are building tools that can solve challenging problems, and we just need to get out there a demonstrate to people its potential. My post-DrupalCon resolution is to try to speak and present outside the regular Drupal camp/event circuit and see what happens when I use the Webform module to introduce new organizations to the potential of Drupal and Open Source.

For Open Source developers, we are in a fantastic time because everyone who has a general understanding of technology can appreciate Open Source.

Open Source equals opportunity; with a responsibility to share it and inspire others.

Reaching outside our community to increase diversity

If we want to improve Drupal's adoption, we need to start talking to new markets and sectors. At the same time, if we're going to grow our community we need to start talking and including new people. We need to create an environment that fosters and encourages speculation, ideas as well as mistakes and wrong answers. If we don’t have a place where that can happen, we can’t uncover the solutions and the right answers.

Palantir’s recent blog post Making Inclusion Happen Through Mentoring is completely inspiring because they are trying to solve one of the biggest challenges in the tech industry.

Palantir's Inclusion Initiative is an effort to make the Drupal community more diverse and inclusive by mentoring students and introducing them to everything Drupal has to offer.

If I am going to advocate for more people to contribute, for contributors to have a voice within Drupal the software, and pushing for us to starting targeting other markets, inclusion and appreciation of the need for diversity, than that is something that I need to think about and include as part of this process.


This blog post started out with a recognition for what we have and my sincere desire that we keep pushing ourselves to improve it. I am going to keep experimenting and trying new approaches. It’s what I do - I don’t know any other way. While writing this blog post, I have discovered what the first slide for my Webform presentation is going to be for people who are new to Drupal and Open Source.

Open source is not just about writing and using free code; it is about the right to share and change ​code. And change has a reputation for bringing about some amazing things.

Case in point: You. Here. Now.

Mar 14 2018
Mar 14

The Contribute module left a bitter taste in some people's mouths, and some people comments were a little a bitter.

Figuring out how to improve the sustainability of Drupal needs to be an ongoing discussion with a gradually evolving approach. It is important that Drupal and every Open Source project has an ongoing discussion about sustainability where everyone can share their views and experiment with new ideas and approaches.

The Contribute module is an experiment that ignited a discussion. It is important to recognize what works and what doesn’t, acknowledge and learn from mistakes, and continue to have this discussion. Sure, there will be varying opinions and results, but the discussion must always be permitted to happen.

My first mistake: The Contribute module is definitely not a technical dependency

The Webform module doesn't depend on the Contribute module to function properly. Honestly, I did not expect that adding this dependency would be so disruptive. This was my first mistake... adding any new dependency is disruptive especially if someone is managing a large multisite installation.

Conceptually, the Contribute module's message is for the broader Drupal community. This message is originating from my work on the Webform module, therefore it should have stayed in the Webform module. In time, I hope this message gradually works its way through the Drupal core issue queue and reaches the entire Drupal community.

My second mistake: Not fully thinking through my approach

How people interact and communicate in online communities is interesting (to say the least). The truth is people say and act in ways that they would never do in person. I am a born and raised New Yorker, which requires a thick skin to defend yourself, yet at the same time you need empathy to get along with so many different groups of people.

My first mistake was adding the dependency; my second mistake was including people's Drupal.org user profile pictures without explicit permission. Once this was brought to my attention, I immediately removed this feature and apologized.

My approach to highlighting core contributors was copied directly from WordPress. I would guess that WordPress gradually evolved this concept and implicitly got permission as they added contributor profiles. There is a lot that the Drupal community can learn from the Wordpress community. We should look outside the Drupal community to see how other communities are working to solve the challenge of sustainability.

People are going to make mistakes along the way

During this journey, there was a comment about being 'horrified' to have it implied that someone would support the Drupal Association (and the Contribute module). I am not active in the Drupal Association, but I can't watch people continually criticize the Drupal Association. The Drupal Association is a team of people whose sole purpose is to support and grow the Drupal community. They are going to make mistakes along the way. At the same time, everyone in the Drupal Association is approachable and genuinely cares about Drupal. Every month at the NYC Drupal meetup, I share a 'Drupal' beer (or two) with Neil Drumm ( drumm). It seems very extreme to be 'horrified' to support an organization that someone as awesome as Neil is working for; which is ultimately us… the Drupal community.

I think the biggest challenge for the Drupal community and the Drupal Association is evolving Drupal's governance and sustainability.

Who, what, where, and when should we be talking about governance, sustainability, and community

Governance and sustainability are critical to a healthy community. How a community works and supports itself needs to be open, transparent, and welcoming to people outside the community.

Yes, I think this conversation begins in the software. The message within Drupal should be concise and direct. A secondary but fantastic benefit to starting this conversation in the software is that Drupal's user interface would then allow us to translate this message into every language in the world.

Some people argue that they should be responsible for having this conversation with their clients and not the software. This is the current approach in our community; where Agency A pitches Drupal to Company B and Agency A is responsible for Company B's engagement in the community. In many cases, Company B's participation stops at Agency A, and Company B has limited or minimal involvement with the Drupal community, even though in many instances Company B will use Drupal longer than it works with Agency A.

My third mistake: Not talking about supporting the Drupal community with my client

Personally, I did limit Memorial Sloan Kettering Cancer Center's (MSKCC) initial involvement with the Drupal community. I was new to the concept of Open Source and Drupal; I said to MSKCC, "Hey look at this amazing 'free' software, you should use it". It took me six years to finally ask them to them to create an organization profile on Drupal.org and another two years to ask them to become an organization member of the Drupal Association. Not immediately understanding and explaining the importance of being a member of the Drupal community when I introduced MSKCC to Drupal is my third mistake.

We need to collectively start asking our clients to be contributing members of the community.

As an experiment, I went through a bunch of the top Drupal agency's client list and case studies, and a large majority of agency clients that are using Drupal are not organization members of the community or the Drupal Association. Some companies are not ready to contribute code to Open Source, but every company has some fundamental appreciation for Open Source because they are relying on it for their website. But a basic understanding of its value vs. participating and in a sense, owning its growth - i.e. contributing - are two potentially vastly different matters. Most companies would have no problem creating an organization profile on Drupal.org which would also help them recruit Drupal developers. The problem is that as a community we are not asking our clients to be active contributing members of the community.

Everyone should encourage their clients to be a member of the Drupal Association because it strengthens the community and gradually makes it possible for these companies contribute something back to Drupal. At the very least we can have all the Fortune 500 companies that use Drupal listed on Drupal.org with a Drupal Association membership badge that says they support Drupal.

Who should be contributing to Drupal?

The answer is everyone. One person reasonably commented that 90% of the people using Drupal would never contribute anything back. Right now, I think this is completely true. It seems absurd that only 10% of our virtual community is contributing code or are members of the Drupal Association. I can't imagine a physical community surviving with only 10% participation. If, as a community, we can get another 10% involved, it would significantly change Drupal’s trajectory and velocity. And that’s only an additional 10%.

If we want to grow our community, we need to examine it.

Is Drupal written by developers for developers?

Drupal is a developer-centric application. This is our biggest strength and weakness. Drupal has so many passionate eyeballs looking at the code and our security team is top notch. At the same time, developers can lose sight of the end users/clients.

The developer-centric mentality around Drupal drove most of the criticism around the Contribute module not being a technical dependency. Someone went as far as stating that the Webform module should also not congratulate and offer people help when getting started using the Webform module. I disagree - making sure that a new user has a positive experience and feel that they are part of a community where everyone is here to help and contribute is essential to the growth and sustainability of Open Source and Drupal. This most basic approach can’t possibly be viewed as negative - think of when you enter a store and someone says, ‘Hi, welcome to (fill in the blank). Can I help you find anything today?’ or when you enroll in college and you’re in the admissions office - someone says, we’re so glad you chose our university, let’s get you started - what are you thinking about majoring in?’ It’s a fundamental way to bring people in and let them know their presence, needs and input (and output) are a desirable thing.

Drupal is for everyone

We need to say 'Hi' and always welcome new users. I welcome new users to the Drupal community every week in the Webform module’s issue queue. Saying 'Hi' to someone for the first time is hard, and we are as a community need to discuss how we should be doing this. Every welcome contains a new potential opportunity to see growth.

Having a discussion without controversy

I believe the Contribute module's message, "The question is not should you contribute, but how can you contribute" should be part of core but it will take a major discussion, followed by a lot of work with some time and bits of patience to make it happen.

For me, the most immediate place to communicate with people using the Webform module is within the actual software.

The Webform module currently includes an optional 'About' section. I have decided the Contribute module’s message is more important than promoting the Webform module or myself. The Contribute module dependency has been removed and its message moved into the Webform module. Developers can easily disable the Contribute section via the UI (/admin/structure/webform/config/advanced). The Contribute section of the Webform module will give us an opportunity to evolve this message, get feedback, and continue to discuss this message in the Webform module's and Drupal core's issue queue.

Webform: Contribute

Webform: Contribute

For the individual responsible for the 200 multi-site installation, I am genuinely sorry that the Contribute module was more than a brief or straightforward discussion.

The ongoing discussion about sustainability is not a simple one, and I look forward to talking about this with everyone at DrupalCon Nashville.

Almost done…

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

OKSubscriptions powered by Strikingly

Feb 12 2018
Feb 12

Yes, I am a listening to everyone's feedback and second guessing my decision to make the Contribute module a dependency of the Webform module.

I was explaining to my 12 year old, Ben, the pushback I am getting around making the Contribute module a dependency of the Webform module and how most people agree with the Contribute module's general concept and message but are unhappy about how and where I placed it. Ben shrugged and says "So basically you are holding up a protest sign, people are agreeing with it but because it is inconveniencing them and they are upset at you and want you to remove it".

So the Contribute module is a protest/political statement; I am okay with admitting that. Many of the expressed concerns are immediately addressed by the fact that there are three different mechanisms to remove the dependency. The beauty of open source is that, if you don't like something, you have the freedom to change it.

For anyone truly worried that the Webform module will indefinitely depend on the Contribute module, it’s worth noting that all protests, political statements, revolts, and revolutions have to end at some point (aka release).

For the time being, however, I am going to keep maintaining the Webform module as well as working on (and defending) the Contribute module.

The Contribute module is not going bring down your website

A few people have expressed concerns about the Contribute module being unneeded and fear it is posing a security risk. Considering people are trusting my 10000+ lines of code in Webform module on production websites to build forms and securely collect data, this seems a bit extreme. To my mind, what seems like the biggest security risk in the Drupal community is unmaintained and unstable modules running on 100,000's of websites. The Rules module is a great example of key Drupal module that is still in alpha releases while being used on a production website. People need to contribute and help get out a stable release of the Rules module. Yes, I think challenges like this needs to be communicated directly in Drupal (the software), especially when people are running alpha releases of software on a production website.

Getting people involved to produce a stable release of the Rules module should be communicated directly in Drupal (the software).

Adding this dependency is going to destroy Drupal's ecosystem.

I thought some people above brought up some really good points about everyone in Drupal wanting to do something like this, but everyone choosing a different message (module) and how that would really destroy the ecosystem.

-- http://dgo.to/2936020#comment-12472445

Yes, if every modules maintainer started to include different messages in their module things could get out of hand - I get that. It’s why I decided to build a dedicated module that conveys this extremely important message, "The question is not should you contribute, but how can you contribute." This message will hopefully strengthen Drupal's ecosystem.

The Webform for Drupal 8, which I have built from scratch on my own time, is currently one of the most well-maintained, well-thought out modules that provides a user experience welcoming new users to our community. The energy and passion that I have committed to this module does nothing but strengthen Drupal's ecosystem

Not everyone can/should support the Drupal Association

It seems silly that I have to continue arguing that everyone should support the Drupal Association. Every Drupal Association individual and organization membership, helps Drupal reach more people and communities. Improving diversity in the Drupal and Open Source community is only going to happen with outreach to underrepresented groups and communities...this requires money and people getting involved.

The argument that not everyone can afford to pay the membership fee is a reasonable one. Hopefully those of us who can afford to pay the membership fee will pay it and the DA can help poorer communities through outreach and scholarships.

Finally, acknowledging people's hard work and amazing contributions

One my key goals with the Contribute module is to remove the notion that Drupal is built and maintained by large organizations. Drupal and Open Source is built by individuals who may work for large organizations, but at the end of the day it is developers who write the software. The Contribute module is an effort to get individual Drupal users (and their organizations) involved in our community. Acknowledging core and project contributors as well as the Drupal.org staff is great way to showcase who is building and maintaining Drupal. It’s one step closer to accessing who we are - it gives it a name and a face, it invites us to get to know what’s possible, and who we’re working with.

The initial release of the Contribute module was simply meant to communicate the message that people should get involved by joining the Drupal community, becoming a member of the Drupal Association and contributing back to Drupal. Besides inspiring people to get involved, it’s important to acknowledge the people who are involved. Personally, I want to the say thanks to all of Drupal's core and project contributors. I know first-hand how important and valuable they and their work is to me and what I do.

Below are screenshots of the three new callouts in the Contribute module, which highlights Drupal core maintainers and coordinators, the Drupal Association staff and board of directors, and installed Drupal modules and theme contributors.

Status Report: Community Information

Status Report: Community Information

Status Report: Community Information: Drupal Core Maintainer & Coordinators

Status Report: Community Information: Drupal Core Maintainer & Coordinators

Status Report: Community Information: Drupal Association Staff & Board of Directors

Status Report: Community Information: Drupal Association Staff & Board of Directors

Should other module maintainers add the Contribute module as a dependency

This is a very tricky decision because some people reasonably disagree with this approach. At the same time, as contributors to Drupal we all struggle with the simple fact that we are part of a very small percentage of the community who is doing most of the work. The entire open source community is struggling with these challenges and change almost never happens without a strong push/statement. We can’t get answers if we don’t ask the questions.

Making the Contribute module a dependency is a statement.

If one or two key modules in the community were to even temporarily make the Contribute module a dependency for a release or two, it would help push our community to improve the messaging within our software and give visible credit to the people who are helping to build and maintain our software and community. And acknowledgment and understanding are key to growth. Not to sound totally preachy here, but the only thing we can say for sure is that change is inevitable, nothing can stay the same.

Personally, I am going to stick to my guns until DrupalCon Nashville. After DrupalCon Nashville, I look forward to tagging a stable release of the Webform module for Drupal 8, which won't include the Contribute module dependency.

The discussion will continue on Drupal.org

Even though some people disagree about how I have communicated this message; most agree with the message. I hope everyone can see that our code and software has the ability to communicate with every user and organization and it can be used to change people's mindset around contributing to Open Source. In the next week or so, I will be creating a core issue about the Contribute module and look forward to a productive and reasonable discussion. I care deeply about the work I’m doing here. I see it grow and change and want it to continue to do so. Each day gives us new opportunities to make it better and further its reach - it’s exciting stuff that warrants our attention and devotion. Call it protest if you will, but I like to think of it as opportunity.

Almost done…

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

OKSubscriptions powered by Strikingly

Jan 30 2018
Jan 30

Half of the people can be part right all of the time
Some of the people can be all right part of the time
But all of the people can’t be all right all of the time
I think Abraham Lincoln said that
-- Bob Dylan

I love these lyrics from "Talkin’ World War III Blues" because it reminds us that it’s impossible to get all of the people to agree on what is “right”. The best we can hope for is a fair and reasonable discussion followed by a compromise.

Two weeks ago, I published a blog post that stated the Webform module now depends on the Contribute module with a reasonable explanation as to why I was making the change. Some people aggressively pushed back about this approach, especially in the Webform module's issue queue. I completely agree that long-term change on what message is communicated as well as how the Drupal community presents itself in the actual software is going to happen in the issue queue on Drupal.org and at DrupalCon. The fact that people consider me promoting the concept of joining Drupal.org, becoming a member of the Drupal Association, and contributing back to Drupal an "ad" or "SPAM" is troubling. I view "code as content". I feel that the Drupal community and Open Source needs a push in a more sustainable direction and I’ve used the Webform module and my two years of hard work as a 'soapbox' to make an important statement, which is "WTF: What's The Future Drupal?

"WTF?: What's the Future and Why It's Up to Us

So I just finished Tim O'Reilly's book titled "WTF?: What's the Future and Why It's Up to Us" and in his book, he passionately talks about how Open Source has shaped the world we see today and the future we see before us. O’Reilly says that Facebook and Google would not exist at the scale they are today without Open Source because both platforms are built on an open source stack of software. To me, that’s huge. O’Reilly’s book explores the key defining technology moments in our past, and how technology in the future is going to impact the workforce, government, healthcare, and politics. We, the Drupal community, are defining a key moment in the evolution of technology and society - definitions that will impact our future and our kids’ future.

Drupal is defining the future

We are the largest open source community building the most tangible and accessible piece of technology available in the world. When I explain to people that Drupal builds websites and anyone has the freedom to use it - they begin to appreciate Open Source. Anyone in the world can use Drupal - they don't need to know how to code, there’s no credit card needed to buy an add-on. becoming a member of our community is the only requirement - and all are welcome. And when you consider all of the vital and useful things out there in our daily lives, most of which are hardly free, that’s pretty amazing.

Of all the Open Source projects out there, Drupal is the only place a completely non-technical person is welcomed with open arms. Everything we do comes with the GPL Freedom. There‘s no competition between projects or "paywalls" in our code. Anyone can use it. We are defining what a global universal collaboration looks like and every single person who has access to a computer understands that we make it possible for anyone to have the freedom to build any type of website or application. In this sense, when the Drupal community calls itself a community, it lives up to the broadest definition of the word.

The Drupal community needs to take the challenge of sustainability head-on

Sustainability has to be the biggest challenge facing the Open Source software community. We have proven the GPL and Open Source works. At the same time, we have seen developers burn out and projects become neglected. It all comes down people being able to make a living writing Open Source Software. There are amazing resources about getting paid for open source work and incredible collaborations discussing the challenges of sustainability.

So many of the approaches for funding open source have relied on a tech company/organization or even a fellow developer helping to crowdfund a project - it simply results in developers who appreciate open source paying other developers. Open source benefits everyone in the world and we need to communicate to all users, big and small, how important it is to contribute something back.

Drupal has potential to educate people about Open Source and change the world’s mindset regarding supporting Open Source software.

It may come as a surprise to many that everyone in the world is already holding Open Source software in their hand when they pick up their phone to make a call. Sure, it would be amazing if every Android and iOS device said "Built with Open Source" on the startup screen. And yet, not everyone can contribute to Android or WebKit. On the other hand, everyone can (and should) contribute to Drupal. Open Source is integral to so many resources in our daily lives but functions quietly in the background.

Changing the world's mindset about Open Source

Recently, my really smart nephew applied to college seeking a computer science degree and has no real appreciation of Open Source, which is both mind-blowing and troubling to me. To my mind, any potential computer science student should feel a responsibility to be involved in open source projects because Open Source is part of their education, craft, and profession. Also, students have the time and passion to make amazing things happen like Drupal.

Dries Buytaert's software powers a million important websites — and he built it from his couch (in college)

-- businessinsider.com

I can name a few others that come to mind but I think we’re all fully aware of students contributions to the tech world over the past 20 years.

Honestly, my nephew is still so obsessed with his video games that I’m not sure he would be motivated to go to a software meetup. If we began to change the world's mindset, his mom and dad might be the ones saying to him, "if you want to get into a good computer science program, you need to get involved in the open source software community". Drupal and most open source communities would welcome him with open arms and maybe even give him a slice of pizza and his first beer. But if we truly succeeded in changing the way the world views Open Source, my nephew would call this useful bit of advice not from not just his parents, but also his advisors, his friends and his daily interactions with technology. Ultimately, it would no longer be an issue - my nephew (and other computer science major/college-bound applicants) would already be informed because it would be integrated into his life from a variety of platforms and people

Everyone needs to be pushed in the "right" direction

Yep, I pushed my message in front of everyone in the immediate Drupal community of developers in the hopes that we can see the importance and need to push the entire world in the "right" direction. I apologize to people who are offended. My intentions have been, and remain, good. Of the many lessons, I have learned while contributing to open source is to “respond to criticism with kindness" which is I am saying "WTF Drupal?"

I like to summarize What's the Future Drupal by stating three key points that I hope we keep in mind while we change the world's mindset when it comes to Open Source.

  • Everyone in the world can understand, appreciate, and contribute to Drupal, which means we are the welcoming wagon to people learning about Open Source.

  • Everyone is here for Drupal "the software" and "the software" is our most important piece of content.

  • Drupal needs to communicate and represent the Open Source movement and challenges in its entire user experience.

For the person who just joined Drupal.org, or became a member of Drupal Association, or submitted a patch to the Webform module's issue queue...

You Rock!!!

What's Next for Me & Drupal

Well, I am done for now, and I’d like to go back doing what I do best, which is writing open source code, welcoming new members to the Drupal community, occasionally being preachy, and getting ready to present at upcoming Drupal Camps and conferences. All of these things are my ways of saying not What’s the Future Drupal (WTF) but rather, Drupal is the Future (DTF).

DTF? Drupal is the Future

Yes, I said it and I believe it. It’s why I’m writing this post and it’s why I work as hard as I do writing code, welcoming new members to the Drupal community, occasionally being preachy...okay, I think you see where I’m going.

Drupal is an amazing community with great leaders and passionate contributors who build and maintain software that is changing the world. We need to also change the world's mindset and commitment to Open Source software. The people we need to reach is not the developer sitting next to you and probably not even your boss, it’s everyone and it’s right now. More importantly, it is the future generation and their parents, maybe even their grandmas.

Finally, if your kid tells you they want to go college for computer science, please encourage them​ to go to a Drupal or a software meetup because they are always welcome and we look forward to meeting them. And if they’re not convinced, remember beer and pizza is an easy sell - most of the people will probably agree. The contribution part? I’m hoping we can make that one a no-brainer too.

Almost done…

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

OKSubscriptions powered by Strikingly

Jan 15 2018
Jan 15

After spending the past year experimenting with promoting paid services, talking about sponsored features, and adding an about section to the Webform module, I learned a lot, from my experiments, including not asking for forgiveness.

"If it's a good idea, go ahead and do it. It is much easier to apologize than it is to get permission."

-- Grace Hopper

Importance of contributing to the Drupal community

Not enough people understand and/or realize the importance of contributing to the Drupal community. My last blog post discussed my hope of finding ways to help sustain my commitment and contribution to the Drupal community and ended by stating…

The question is not should you contribute to open source but how can you contribute.

Convincing people that they need to contribute

The challenge is convincing people and organizations that they need to contribute to Open Source. Funding is an ongoing challenge for the Drupal community The problem could be that people don't understand the importance and value of contributing back to Open Source.

Nowhere in Drupal's user interface/experience is our community and Drupal Association promoted and/or acknowledged. Core maintainers are only included in the MAINTAINERS.txt file, which only fellow developers can access. Drupal is not a product that can to be sold but we are a community with an association that needs recognition, support, and contributions.

The Drupal Association is the backbone of the community and everyone needs to be member.

Everyone needs to be a member of the Drupal Association

It’s surprising how many people and organizations are asking for support in the Webform module's issue queue who are not members of the Drupal Association. As another experiment, I thought of my top 10 list of showcase Drupal websites and most of them are not members of the Drupal Association. These are large enterprise websites that are not paying a few hundred dollars annual membership fee to help maintain the software and community that they depend on. And if we can't get a developer or company to pay a small membership fee, how are we going to show them the value of contributing to Drupal and/or funding core or contrib development?

Encouraging individuals and organizations to join the Drupal community

The Webform module now depends on the Contribute module.

Contribute module

Contribute module

Introducing the Contribute module

The Contribute module’s project page provides a complete explanation of the module’s goals and purpose. I wanted to isolate the concept of everyone contributing back to Drupal into a dedicated module because this is not just a Webform specific challenge. I think it’s important to emphasize that other modules can also depend on the Contribute module. Frankly, if some of Drupal's top 40 modules were to add the Contribute module as a dependency, it would clearly acknowledge the overall desire to change the Drupal user's mindset when it comes to contributing back to Drupal. It’s very important for me to point out that the Drupal community is not the few thousand developers and companies who contribute and value Drupal; our community is the one million sites using Drupal.

Preaching to the choir

This blog post is "preaching to the choir" because we are all active and caring members of the Drupal and Open Source community. However, we need to take it a step further. We must look beyond our code and talk to the people who are actually using our software. For Drupal and Open Source to succeed, everyone needs to contribute back to the community - we need to reach out to these users and organizations and communicate that their participation is not only welcomed, but vital and necessary.

Creating code before the discussion

Instead of discussing this idea extensively, I decided to just go for it. At the same time, I have been asking every single person I know to provide feedback. The general consensus is that the Contribute module is not going to offend anyone, but nobody can say if it can succeed in changing our community’s mindset. I don’t know the answer either but I do know that I want to ask the question, that I do want hear what others have to say and so I started this discussion using my best tool; thought out, clean, and simple open source Drupal project called the "Contribute module."

Learn more about the Contribute module

I look forward to hearing your thoughts.

Almost done…

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

OKSubscriptions powered by Strikingly

Jan 04 2018
Jan 04

Tagged the first release candidate on Christmas Day

On the one year anniversary of the first beta release of the Webform module for Drupal 8, I tagged the first release candidate. The most significant aspect of moving the Webform module into the release candidate phase is the stabilization of key APIs and plugins. Moving forward, most new features that are not tightly coupled to the Webform module's core functionality will be developed in dedicated experimental or contrib modules.

What’s next?

My first goal is to start focusing on the recording of Webform-related training materials and my upcoming presentations at Drupal Camps and conferences. I also want to encourage and help more people get involved and contribute to the Webform module and Drupal.

Contributing to the Webform module and Drupal

People are continually commenting on my dedication to the Webform module. As such, I think it’s important to explain why I am so committed to the success of the Webform module and Drupal. The two most important factors that have allowed me to contribute so much time to the Webform module are as follows: I have the time available and I have a desire to improve my professional profile. I’m fortunate to have steady and reliable consulting income. For many years, I was a passive member of the Drupal community. But then my schedule freed up a bit, and I found that I had some extra time on my hands, so I decided to experiment and see what would happen if I fully committed myself to an open source project.

What I learned about maintaining an open source project

The role of being an open source project maintainer is daunting. I was surprised to learn that I am doing 95% of the work with limited quality assurance processes and minimal code review. At the same time, I truly love the role of mentoring new developers and working with the Drupal community. Welcoming new members to the Drupal community is something I take a huge amount of pride in and believe it is vital to the continued success of Drupal.

Mentoring others is a role I never imagined for myself - I’m not even sure if I’m particularly good at it. And yet, mentoring is the key to a successful open source project growing beyond being freely available good code. Currently I’m working with Michael Feranda (mferanda) to complete Issue #2888862: Provide a mechanism to lock a webform submission. Sharing the experience of the work and feeling the collaborative accomplishment of contributing a new feature to Webform module is rewarding - it is now and it has been, regardless of the project. Dedicating myself in this way - giving 100% - has proved fruitful in ways I never imagined.

Still, I am the driver behind the Webform module and I am destined to burnout.

Destined to burnout

Burnout is when someone has contributed so much to a project that they physically and mentally exhaust themselves. Burnout is a common problem for most open source projects.

To prevent burnout, I’ve decided to focus my open source contributions solely on one project: the Webform module for Drupal 8. I admittedly avoid making contributions to Drupal core because I find the level of effort required to fix a core issue draining, especially because I am working for free. I want to emphasize that I am not advocating against contributing to Drupal core, but it’s important that open source contributors understand what works for them.

Realizing and feeling the potential for burnout made me look at some of the Drupal community’s key contributors that have "burned out". I don’t personally know Earl Miles (merlinofchaos), but like everyone in the community, I too, respect his contributions to Drupal especially his work on Views and Panels. A full-time employer sponsored Earl's Drupal work and once this sponsorship ended, he gradually slowed his contributions. Some people conjectured that he left the community but Earl explained his experience and position. For me the two most telling quotes are...

"But let's be honest: I am and always was an exception to the way things really work, and an unsustainable exception at that."

"But Drupal is what it is today because there is money to be made. And that money needs to flow back into the project, where it can, and the people who actually do the really heavy work can be rewarded."

Earl Miles (merlinofchaos)

Frankly, I respect and understand Earl's decision to step back from contributing to Drupal. At the same time, our community's inability to sustainably fund his contributions allowed one of our brightest stars to burnout.

My conclusion is that for unpaid valued contributors, including myself, burnout is inevitable. Figuring out how to fund contributions is the only solution

Drawing lines in the sand

I need to draw two lines in the sand explaining how I feel about funding open source projects and contributions.

Open Source is not free software, and everyone should contribute.

On the polar opposite of this concept that "Open source is not free software", we can’t just charge for open source code. I have a problem with even the appearance of charging for code. When money is tied to the resulting product of an open source collaboration, it creates duplicate code and project silos. Paid modules will muddle Drupal's ecosystem because projects start to compete for funds, which then discourages the collaboration of ideas, code, and support.

My most concrete example of how charging for modules/add-on creates duplicate code and effort is the simple fact that WordPress has dozens of form builders that provide the same functionality without any reusable form API, combined with the fact that each form builder has varying levels of security. Yes, I think the Drupal's much more collaborative ecosystem provides a more secure and reliable Form API, and the Webform module has more potential than most of Wordpress' form builders and we are not charging X dollars for each minor feature and add-on.

I am against charging for the final product. However, I believe more people need to start contributing time and/or money towards Drupal and open source for it to be sustainable.

Everyone needs to contribute and still have the have freedom & rights guaranteed by the GPL.

Beginning to see open source communities as co-operatives

There has been a lot of thought about funding and growing open source communities. Dries Buytaert, Drupal's project lead, dedicated his DrupalCon Amsterdam keynote to the topic. Nadia Eghbal maintains what most consider the canonical and handy guide to financial support for open source. I also recommend checking out Nadia's podcast which explores different perspectives in open source sustainability called Request for Commit. I am still reading and learning about open source. The term "open source" is a direct result of the software community trying to move away from the connotation that the GPL creates "free software". The fact that open source still results in the creation of "free software" has created the major challenge of sustainability. At the same time, no one could have foreseen how strong and viable open source communities would become. No one saw the changes that would come about and now we, too, need to change our thought process regarding what it means, its value, and how/where we want to go.

I’ve started to view the collaboration and community that builds open source software as a loosely, and somewhat undefined, cooperative.

A cooperative (also known as co-operative, co-op, or coop) is "an autonomous association of persons united voluntarily to meet their common economic, social, and cultural needs and aspirations through a jointly-owned and democratically-controlled enterprise".


I find it interesting that no one is drawing any strong correlation and discussion between open source and cooperatives. The most intriguing thing I want to point out about cooperatives is that they are generally considered sustainable. My best example of a successful cooperative is the Park Slope Food Coop which is largest food coop in the United State and they were founded in 1973.

"Only members may shop at the PSFC, and membership is open to all."

"As a member of the Coop you share ownership of the Coop with 17,000+ fellow Coop members. You have a voice in the decision-making process and can participate in planning and discussions of the organization’s future. Work, shop, learn, participate—be a part of a unique and rewarding community here in Brooklyn."


The Drupal community does not operate exactly like a food coop but maybe the simple concept that everyone participates would benefit our community. Every project maintainer and core contributor talks about how people should contribute. I feel it is to time to explore strongly conveying the message that people need to participate and contribute. Contributions can come in all shapes and sizes and ​clearly companies need to fund and sponsor open source contributions.

Commitment, Mentoring, Contributions, Community & Success!

I am committed to the Webform module and look forward to growing and mentoring new contributors… I don’t want to burnout - I want to stick around. I enjoy being part of this community and collaboration and have benefited from doing so. The work, the commitment, the relationships, the growth - it’s all been amazing! I consider myself both proud and lucky to be here. Open source and Drupal is not going fail but I want to continue to be part of its ongoing success. We need to find other ways to strengthen and frankly sustain our community with contributions and funding.

I am going to start to encourage people and organizations to contribute by simply stating...

The question is not should you contribute to open source but how can you contribute.

Finally, we should explore lessons that we can learn from cooperatives. At least we already know that everyone is welcome to our community.

Almost done…

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


Dec 19 2017
Dec 19

My family and I got to see Mayor Bill de Blasio sign the online voter registration bill into law which Ben Kallos, a New York City councilman and true fan of Open Source, sponsored. Kallos used the Webform module to demonstrate how easy it easy it is to capture a digital signature. The most ironic thing about watching the mayor sign the online voter registration bill, which is driven by the concept of digital signatures, into law, was the fact that he used used multiple pens to sign the bill. My daughter Lili and I both received pens that the mayor used to sign the bill. Everyone, myself included, has Kallos to thank for making this bill and experience happen. I guess - and this is a good thing - we’ll have to find other uses for our pens.

Last month, Kallos did a presentation at the NYC Drupal Meetup about how he used the Webform module to help get legislation passed to allow online voter registration for New Yorkers.

We all know that we can’t vote online yet, but I was surprised to realize that people can’t even register to vote online! Sure governments and municipalities move slowly, but how hard should it be to set up an online voter registration application? There is even an online HTML form that generates a filled-out PDF form that you have to print out, sign, and mail in. Next, someone manually re-enters your information, with no typos…duh. Kallos gets technology, which is why he sponsored this legislation and tackled the real challenge of showing his fellow council members how to capture a digital signature, which is essential for registering...Read More

Dec 12 2017
Dec 12

As the Webform module progresses towards a stable release and developers are getting familiar with Drupal 8, some developers are starting to contribute some very cool add-ons to the Webform module’s ecosystem.

Drupal is about collaboratively creating robust, stable, and extendable APIs that developers can use to improve and customize Drupal's functionality. Drupal's core Form API (FAPI) is the backbone of the Webform module for Drupal 8. The Webform module would not exist without FAPI, so here is a shout out to all the past maintainers of Drupal FAPI and its current maintainers, Alex Bronstein (effulgentsia) and Tim Plunkett (tim.plunkett).

I am a dwarf standing on the shoulders of giants.

Because the Webform module Drupal 8 is an entirely new code base, the entire Webform related project ecosystem must be rebuilt from scratch. I see this as a challenge and an opportunity to rethink the functionality that the core Webform module provides and how it is extended.

I strongly feel that the Webform module must be a complete form building solution, which inspires the Drupal community to do what it does best, extend the heck out of powerful APIs

The Webform module for Drupal 8 builds incredible forms, but it is up to the Drupal community to develop the tools and features needed to handle submissions and integrate with third-party applications.

To encourage people to extend the Webform module I decided to track contributed modules within the Webform UI and on Drupal.org in a section that I am calling "Add-Ons."

Webform: Add-ons

Webform: Add-ons

The Add-ons page lists Drupal modules and projects that extend and provide additional functionality to the Webform module and Drupal's Form API.​​

Laurent is making it possible to analyze webform submissions

Laurent BARAN (lbaran)

Laurent BARAN (lbaran)

Laurent BARAN (lbaran)

Analysis and charts are one of the few features that were available in Webform module for Drupal 7, however it was removed from Drupal 8 version. The Webform module is about collecting data, and there should be a variety of tools built for displaying this data.

A few weeks ago, Laurent created the Webform Analysis module. I was excited to see his first release posted on Twitter, and I immediately download his code. I was delighted to see that it worked as expected. I was surprised how easily he was able to create this functionality. A closer look revealed he was smartly using Google’s Chart API to do the heavy lifting.

Reading someone's code tells you a lot about their level of experience. How someone handles feedback tells you about their real potential.​​

Laurent is new to the Drupal community. His code reflected a lot of programming experience but I felt it needed to be Drupalized and Symphonized a little bit. So I posted an issue in his queue and he started to improve his module immediately.

Laurent is on his way to building a module that is going to be used by most Webform projects, including my own. It’s great to see a new developer to the Drupal community contribute something back that will make such a significant impact.

Webform Analysis

Webform Analysis

Try the Webform Analysis module

Rich is building a user interface for reusable composite element

Rich Gerdes (richgerdes)

Rich Gerdes (richgerdes)

Rich Gerdes (richgerdes)

Composite elements are a completely new feature to the Webform module for Drupal 8. Composites are groups of elements working together to collect information like addresses and names. Webform composites are similar to Drupal’s Field collection module.

Last month, I managed to implement custom composite elements in the UI, but this feature was not reusable across multiple forms.

A few people, including Rich, requested reusable composites, but I don’t have the bandwidth to support this feature in the core Webform module. Rich and I talked about this problem, and he was up for the task of taking out the Webform composite module. Since the Webform module is still in beta, we were able to make a few API tweaks to core Webform module that have paved the way for him to create and maintain the Webform Composite Tools module.

Webform Composite Tools

Webform Composite Tools

Start creating reusable composite elements

Alexander continues to be a ​Webform Ninja throwing out a few patches and disappearing back into the shadows.

Alexander Trotsenko (bucefal9)

Alexander Trotsenko (bucefal9)

Alexander Trotsenko (bucefal9)

Like many developers, Alexander had a project that needed Webforms and required Views integration. I was finding setting up Views integration to be a daunting task and Alexander just threw together a patch and posted it. I suggested that he take over the Webform Views Integration namespace and he took me up on it. Alexander did such an amazing job that I was happy to praise his recent contribution to the Webform module.

He admittedly does not have a lot of time to contribute back to Drupal, but he periodically reviews the issue queue and applies some patches. I am calling Alexander a "Webform Ninja" because he got the 'mad skillz' and and randomly appears to do his impressive work and then disappears.

Webform View Integration

Webform View Integration

Download Webform Views Integration


Laurent, Rich, Alexander, and myself have different skill levels and experience with each one of us contributing to Drupal in different ways. While contributing to Drupal helps build our resumes and professional profiles, I think it is very important that Drupal recognizes who is contributing back. Recognition is key to motivation and motivation is an essential ingredient to contribution, especially in an open-source community. Hopefully, our work inspires more people to contribute something back to the Drupal. For now, everyone should take our work for a spin, post an issue in our issue queue, and even tweet a thank you.

Community community community.

Thank you.

Almost done…

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

OKSubscriptions powered by Strikingly

Nov 28 2017
Nov 28

I have decided to remove paid promotions from the Webform module to focus on promoting the Drupal Community as a whole, the Drupal Association, and Webform module, I am also comfortable stating that I am not asking for forgiveness for my decision.

It is important that the Drupal community understand that I reached out to Lingotek and chose to promote their services within the Webform module's UX. Lingotek has made and continues to make amazing contributions to Drupal and the community. I want to thank them for allowing me to promote their services in such an experimental way.

Removing the paid promotion

I documented my original intentions in a blog post about promoting paid services within the Drupal community. I have come to fully agree with lslinnet's comment...

"I do not agree, promotions of third-party services does not belong anywhere in the site"

The Drupal community needs to explore ways to help support and fund core contributors and project maintainers. The goal of the paid promotion experiment was to see how everyone, including myself, felt about this concept.

The Discussion

MortenDK's (mortendk) very upset and direct tweet triggered the largest debate...

A few responses resonated with me, including one by kevinquillen and this one by tedbow:

Yes, the promotions of third-party services within a module's UX could open some floodgates that could create a horrendous user experience and first impression of Drupal. First impressions are very important, Drupal and the Webform module need to make a good one.

Without a doubt, it would be great if Acquia fully funded the Webform module, but this would not solve the larger problem of how to support and fund contributions to Drupal and Open Source projects. Even if they were to fund it, there is only so much that Acquia can do. Drupal's 100,000+ active contributors have, and will always be able to, contribute more than any single organization.

A tweet by Ted Bowman (tedbow) calls for a "broader solution" and that is what we need to start thinking about:

A Broader Solution

At the moment, I don't have any solutions. I am focusing on getting a stable release of the Webform module out in 2018. For me, removing the promotion before tagging a release candidate (RC) pre-Christmas is a necessity. And now, I just have a few end-of-the-year thoughts and feelings I’d like to share.

Open Source and Free Software Are Not the Same

Over time, I've come to realize that most people don't fully understand that Open Source software is not equal to "Free Software". In many ​cases people assume that I am being paid to contribute to Drupal. The truth is that I didn’t make any money from my partnership with Lingotek. The only nominal income I have ever received from the Webform module came from a few small one-off feature requests.

Contributing Helps Us All

From the moment someone downloads and installs Drupal, they should take the time to become a member of the Drupal Association and to educate themselves about the Drupal Community and how they can contribute back to Drupal - it’s time well-spent for everyone and an investment that reaps benefits for all of us. And being part of a community requires - and thrives on - give and take from all of its members.

People come for the software, but stay for the community

Every Drupal relationship begins with the installing and using the software. Many people, including myself, install Drupal and use it for years and don’t look back. They fail to see the value of contributing anything back to the community. That needs to change. We need to raise awareness regarding the importance of contributing back to​ the community, to make it easier to contribute, and ultimately change everyone's long-term mindset when using Open Source software. A natural byproduct of contribution is feeling as if you’re part of something. You become invested and the investment means you see the value - both your own and that of others. Drupal, its community, and its association are no exceptions.

I am going to continue to plug away and experiment with the Webform ​module however, I do feel it is important to explain my approach and why I am "not asking for forgiveness".

Not asking for forgiveness

"It's easier to ask forgiveness than it is to get permission."

I first heard the above quote in reference to Uber's aggressive expansion policy, which made me assume that this quote originated from a business giant, assumingly male. Well, I was wrong and what a wonderful feeling to be wrong. Turns out, the quote is attributed to Grace Hopper, one of the pioneers of computer programming.

Another variant of Grace's quote is...

"If it's a good idea, go ahead and do it. It is much easier to apologize than it is to get permission."

I like this version even better because the concept of a "good idea" can be interpreted in many ways. Open Source is a good idea, driven by good people who are hoping to do some good in the world.

I am not seeking permission or forgiveness. Rather, I sincerely want to solve the challenging problem of funding Open Source development and hopefully, make the lives of Open Source developers, including myself, easier. I want the next generation of developers and business owners to feel that contributing to Open Source projects is part of their professional life - that it will further their career and/or business and help them financially succeed in the world. Ultimately, the Webform module may not support my family and me. Minimally, I do feel Open Source should be able to generate enough revenue that some student in college can pay their tuition.


This is easily my favorite personal blog post to date because my original subject matter "removing paid promotions" shifted from acknowledging a failed experiment to including great quotes from an amazing person. I’d like to end with another one of Grace Hooper's quotes.

“Humans are allergic to change. They love to say, ‘We've always done it this way.’ I try to fight that. That's why I have a clock on my wall that runs counter-clockwise.”

Tock-tick. Tock-tick.

Image: Alice in Wonderland Caterpillar Clock (thewhiterabbitcom)

Almost done…

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

OKSubscriptions powered by Strikingly

Nov 20 2017
Nov 20

DrupalCamp Atlanta was such a great experience -- I can't decide if it was a great end to a good year or the beginning of even a better year. My last blog post was about organizing and presenting the Webform training materials, which was in preparation for my three-hour Webform training at DrupalCamp Atlanta. Suffice it to say, it was an enlightening experience. Not to mention I learned a few things...

First off, I am in awe of all the people in the Drupal community that are 'professional trainers'. The ability to understand and explain something as complex as Drupal is no easy task. The 14 attendees at my Webform training had various skill levels. Because my leg did not nervously shake at all during my three hours at the podium, I can finally say my comfort level with public speaking is increasing. I also came away with some invaluable, practical information. Prior to attending DrupalCampAtlanta, I had completely underestimated how hard it is to coordinate people to do hands-on exercises, like installing and building a webform. After the first hour of the training, I took a break and decided that the hands-on exercises were going to be impossible to accomplish in the remaining two hours, and that the training should instead focus on walking through all the material while answering any questions. I haven’t given up hope on being able to do hands-on exercises, however, I do need to rethink my approach. Fortunately, I was able to attend other sessions, watch some 'profession trainers' in action, and learn a few things.

Michael Anello (ultimike) at DrupalEasy is a 'professional trainer'. He knows how to talk Drupal to people that don't yet "grok" Drupal. I attended Mike's Drupal 8 Configuration System Basics presentation and it was a perfect example of how to do a K.I.S.S. (Keep It Simple Stupid) presentation. My understanding of Drupal's Configuration System is pretty solid yet, Mike managed to convey the most important aspect to working with Drupal's Configuration System, which is that the development team needs to define a clear agreed-upon process for exporting, importing and updating a Drupal site's configuration. Knowledge is one thing; being able to relate that knowledge is the real stuff.

Over one of many 'Drupal' beers, I told Mike that I want to sit in on his training so that I could learn from a 'master'. I’m specifically intrigued by his Drupal Career Online for individuals; It's a 12-week, instructor-led online course that goes deep and broad into the technology, community engagement, and hands-on exercises to give you a rock-solid foundation for a successful Drupal career.

Mike's helping Drupal newbies become Drupal rockstars. He’s helping to grow the Drupal community by inspiring and helping individual developers to join our community. "He is helping the little guy in our community."

I am 6'3" and still feel like the little guy in the Drupal Community. This was especially true during the Keynote Contrib Panel discussion that I was part of with Ryan Szrama and Damien McKenna. Ryan and Damien are both passionate Drupal contributors, who as part of their jobs get paid to contribute to Drupal. Ryan is the CEO of CommerceGuys, Damien is the community lead for MediaCurrent. And then there is me; the guy who created the Webform module for Drupal 8. I admire both Ryan's and Damien's role in the Drupal community and when you watch the video, you can see me hunched over, listening and deciding, nodding and shaking my head in accordance with what points I agree with or see differently. Please understand, I don't disagree with anything talked about in our panel discussion; I just have a disparate perspective which I can sum up and explain as "don't forget the little guy."

During the panel discussion, Ryan and Damien talked about their contributions to Drupal as part of their current employment. However, all three of us started out in the Drupal community as individuals making contributions to Drupal after hours. Drupal's community is changing and many aspects of Drupal is being built and maintained by paid contributors working for companies and organizations. You should read Who sponsors Drupal development? (2016-2017 edition) to get a better understanding of the Drupal community. Yes, I was surprised that I was the number 1 individual contributor in the Drupal community and one of the few people who is not making "paid contributions" to the Drupal community.

Right now, I have the time available and experience to be able to make a sizeable contribution to Drupal. Early on my Drupal career, Dries Buytaert (the guy who started Drupal) discussed how the Drupal community is a "do-ocracy"; where individuals and groups of people decide what needs to be done and then they just do it. As an individual, as well as in many ways a little guy in the Drupal community, I decided to do ‘something,’ which became the Webform module for Drupal 8. It’s something that has, in turn, become something that I’m passionate about, that I’m eager to see grow and change. And not just personally - it’s a passion that extends to the Drupal community and everyone involved.

I feel that the Drupal community might be forgetting about the little guy, which we can't afford to do. Little guys (aka individuals) have started and built out most of Drupal key modules and themes. Most Open Source projects started out with an individual writing and sharing their code and dreams. Dries, who is ironically very tall, started Drupal as a little guy. He was a college kid in a dorm room, and now he is the project lead to the largest Open Source community and CTO of Acquia.

Drupal is a major project with a massive community built by individuals, including myself. Our community definitely needs corporate sponsorship to support events and major initiatives. At the same time, we need to remember that our community is built one developer at a time. Maintaining the proper balance between individuals and organizations within the Drupal community is an ongoing challenge. Since I am a "little guy', I am interested in seeing more individual developers become part of the Drupal community.

As a follow up to Promoting paid services within the Drupal community and What "About" the Webform module and the Drupal Community? I have decided to start encouraging individual developers to join the Drupal Association with a simple banner in the Webform module's UX that says…

The Drupal Association brings value to Drupal and to you. Join today

The Drupal Association brings value to Drupal and to you. Join today

My hope is that individual developers (aka little guys) will join the Drupal Association and the Drupal community.

I strongly feel that Drupal Association is the backbone of the Drupal Community. As the Drupal Association grows, it needs to remember and help the little guy. Who knows? Maybe even provide scholarships to Michael Anello's Drupal Career Online for individuals.

For now, I am going to embrace my "little guy" status in the Drupal community and just keep plugging away at the Webform module for Drupal 8.

Well, that and focus on keeping my leg from shaking whenever I speak in public.

In closing, I want to encourage you to join the Drupal Association as an individual while reviewing and/or writing a patch for the Drupal community.

Every little bit helps.

Photo by: Utzu Logigan (https://www.recallact.com)

Almost done…

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

OKSubscriptions powered by Strikingly

Oct 30 2017
Oct 30

Now that the post-DrupalCon Vienna events are in full swing and next year's pre-DrupalCon Nashville events are in the works, I’ve started organizing and creating next year’s Webform related presentations. I find presenting at DrupalCamps challenging and rewarding. The challenge is getting up in front of a large group of developers and talking about my work, but the reward is I get to meet people who use my work to build awesome forms.

Attending Drupal Camps & Events

In the past, I’ve managed to attend a bunch of events including DrupalCamp NJ, NYCCamp, DrupalCon Baltimore, Design4Drupal, and Drupal GovCon. My last camp of the year is going to be DrupalCamp Atlanta on November 2-4, 2017. I decided to go to DrupalCamp Atlanta because they are offering me the opportunity to do my first training session called Learn how to build awesome webforms and a keynote panel discussion. Yes, I am uncomfortable with public speaking, however I’ve committed myself to doing it for longer and in front of more people; this conference is pushing me to up my game. The hope is that it will prove to be a good thing for me, and hopefully will, in turn, be a good thing for others too.

Overcoming Challenges

One technique I’ve learned to overcome my weaknesses is to leverage my strengths. My biggest strength is organizing information and the requisite tasks to get something completed. So I’ve committed to three hours of training; now it’s time to get organized.

Organizing Training Materials

I have done a lot of experimenting with the Webform module - the most successful outcome has been my video screencasts/presentations related to using the Webform module. A looming task for the stable release of the Webform module is modifying all these videos. Putting together three hours of training materials for DrupalCamp Atlanta is also becoming a daunting task. So I’ve decided to merge the redoing of my videos and training into a single project.

For the past few months, I have been cleaning up the Webform modules information architecture by moving and renaming tabs, sections, forms and elements. My goal is to create a fluid, intuitive workflow and user experience for a feature rich and admittedly complex module. For example, I realized that having a global 'Settings' tab and a Webform specific 'Settings' tab was confusing. The solution? I changed global 'Settings' to be labeled 'Configuration.' I can comfortably say the Webform module’s UI/UX is very close to stable.

My next task was improving the inline help text, which links to the existing video tutorials.

Managing the Webform Module’s Editorial

I am a bit dyslexic and work with a copy editor, Liz Berntson. She reviews all my blogs post and documentation. The challenge with editing a module’s documentation is everything is embedded in the code; Liz is not about to start learning how to write and contribute patches to the Webform module. I resolved this problem with a hidden module that exports all the Webform module’s editorial into simple HTML document that can be cut-n-pasted into a Google Doc, which supports comments and revisioning. Liz has done her editorial review but anyone should feel free to provide feedback and comments.

Getting Feedback from the Drupal Community

Getting feedback brings me to the goal of this blog post, which is to publish all my training materials online. My hope is that I will get feedback on my slides from the Drupal community and from all of the people attending my training at DrupalCamp Atlanta before I re-record hours of training videos. Everyone is invited to review and comment on all my new training presentations, the existing videos and documents on Drupal.org.

Feel free to comment on the slides and post suggestions below. Hopefully, in 2018 you can attend one of my Webform related presentations or training sessions.

Review the Webform Training Slides

Almost done…

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

OKSubscriptions powered by Strikingly

Sep 28 2017
Sep 28

For the past year, I’ve been experimenting with how to integrate content within the user interface of the Webform module with a goal of improving the overall user experience. These experiments include adding inline videos, help documentation, a "How can we help you?" menu, and promotions. As I work towards a stable release, it’s time to document the lessons that I’ve learned from these experiments and decide on a final approach.

The Webform module makes it easy to build feature-rich, powerful, and flexible forms. Within this user interface, I’m aiming to provide users with user experience that helps them understand the Webform module and the Drupal community.

Providing help and documentation is a requirement for all software, including Open Source. The open source nature of Drupal led me to have three primary requirements:

  • Make users feel comfortable and supported when using the Webform module.
  • Promote the Drupal community to new and existing members. 
  • Raise awareness of my work. 

Making users comfortable

The most immediate way to make someone comfortable is to start a conversation - to talk to them, to ask questions and to listen. Early on, as part of the Webform modules development, I started producing video tutorials and demos to provide a show-n-tell experience. At the end of more recent videos, I promote myself using the question, "How can I help you?".

Overall, I’m happy with how the videos have been received by the Drupal community and I think this feature is going to remain AS-IS. Once the Webform module has a release candidate, I’m going to redo all the screencasts and apply some of the Drupal community's recommendations, one of which is talk slower.

Promoting Webform, the Drupal community, and myself

Promoting the Drupal community, third-party services, and myself has posed an interesting challenge. Though I did get some negative feedback, the simple fact that all promotions can be disabled calmed a lot of nerves. I’ve realized the best way to promote something is to just tell people about it. Storytelling is a meaningful way to relay information to others - additionally, it also serves as an invaluable tool when it comes to teaching. I’ve come to the realization that my experimental "How can we help you?" menu, dialogs, banner, and videos just need to be consolidated into an "About" section.

Most organization websites have an "About" section and even software includes an "About" dialog or page. Wordpress, the other CMS, has a dedicated "About" page. I think the time has come for the Webform module and even Drupal to start including an "About" section within the software's user interface/experience.

I don't think I am alone in feeling that Drupal needs to promote more information about an installed project. There’s even a ticket to "add links to Drupal.org contrib project (and issue) pages to module listings". I’ve decided to go one step further and move content from the project page into the Webform module user interface and experience. Aside from modules needing better promotions, I feel that the Drupal Association would benefit from being able to promote itself more directly with end users and developers.

The simple fact that most users who are posting issues in the Webform issue queue are not members of the Drupal Association indicates that people are not aware of, or do not understand, the importance of the Drupal Association. Personally, the Drupal Association maintains the infrastructure that we rely on to support the Webform module and our community. I don't think membership fees will solve the DA's financial challenges, however, it’s membership that increases awareness and grows the Drupal community.

Creating an "About" page within the Webform module admin page allows me to contribute and share more than code and help build our community. And yes, I’m also able to promote the Drupal Association and myself directly to people using our software.

So here is a screencast about the new 'About' tab.

Next Steps

For now, the Webform's "About" tab will contain very static content, along with some videos and links to external resources. Ideally, this "About" tab could evolve to include an RSS Feed that highlights recent releases, features, issues, and general information. I’m also seeking an easy and appropriate way to give credit to people and organizations that help to support the Webform module.


Please provide any feedback below. If you don't like the "About" section, please disable it. If anyone wants to contribute content, particularly to the "About Drupal" tab, please create a ticket. Finally, if you want to sponsor a feature or hire me, feel free contact me.

Almost done…

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

OKSubscriptions powered by Strikingly

Sep 11 2017
Sep 11

Providing a fancy and slick user interface is the quickest way to wow and sell software. Drupal doesn’t provide you with a slick wowing user interface, but once you start to understand Drupal's site builder and developer experience, you’ll find yourself having continual "Aha" moments.

Wow and Sell vs. Understand and Aha...

Proprietary software needs to sell something. Open Source software needs to do something.

Proprietary Content Management Systems (CMS) and online form builders have a lot of immediate wow, including snazzy marketing and very fancy user interfaces. I admit it: I like wowing people and the Webform module's user experience with video tutorials and it's very slick-looking elements like signatures and likert are meant to impress you. The Webform module's "Aha" moment happens when you grasp the software's full potential. Suddenly you understand the Drupal mantras, "There is a module for that; There is a hook for this; Anything and everything is customizable." Aha indeed.

Wow is cool. Aha promotes understanding and growth.

The Webform User Interface/Experience

Circling back to Webform module's user interface and experience, there’s a limit to how much wow I can build. On the flip side, there is unlimited aha available. The latest releases of the Webform module includes a significantly improved UI with Ajax, element previews, tabbed dialogs, and more. The Webform module may never have a slick WYSIWYG drag-n-drop user interface... I’m okay with that. I’d like to share with you the current state of the Webform UI/UX and talk about some key concepts.

The current user interface for the Webform module leverages existing UX patterns from Drupal core. For example, using a modal dialog for creating new elements was inspired by the Blocks UI. The Webform module also includes support for core's experiment system tray. My goal is to provide "fluid user experience" that is logical and works for all users while providing an incredible amount of configurability and flexibility.

Here is latest and relatively final Webform UI/UX.

It’s not how you build the webform but what you do with the webform submission.

The actual form builder is not the most important feature of the Webform module. Without a doubt, generating form and submission handling is by far the most important aspect of the Webform module. The 1000's of end-users filling out and submitting forms are more important than the one person building the form. A webform submission, also known as a lead in the land of CRMs, is why organizations build websites; to connect with new and existing customers.

We need to build awesome forms that encourage users to complete the form and create submissions which we can routed to our CRMs, internal, and external applications.

So what is both awesome and aha worthy about Webforms?

Webforms are just an extension of Drupal's Form API. Webform elements are literally and programmatically wrappers around Drupal's form elements. Drupal's Form API is a mature subsystem that has excellent accessibility, it protects and validates against malicious submissions, and is very easy to alter and customize.

What is next for Webform 8.x-5.x?

The general UI/UX for the Webform is close to done but there are plenty of little things that still need polishing, including inline help and settings management.

I’m almost ready, albeit nervous, to tag a release candidate. Why nervous? Because I’m continually packing new features into every monthly release. Sadly, every beta release also includes a few too many regressions and bugs. Prior to tagging an RC, a full audit of the Webform module's code base and functionality so that @todo are fully accounted for and API are relatively solidified would serve all parties well.

Please join the Drupal community and start helping out with the Webform module's issue queue and ask your questions at Drupal Answers.


The Webform UI/UX leverages Drupal 8 UI/UX design pattern and contains a lot of wow potential, however our focus needs to be on the more important aha moments. Building awesome forms and applications that connect with our customers and constituents is where our aha moments lie, and it's these aha moments that are among our biggest strengths.

Almost done…

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

OKSubscriptions powered by Strikingly

Aug 08 2017
Aug 08

Drupal: Getting Paid to Do What I Love

I’ve been planning and working toward this moment for long time. The latest Webform feature is not for the community, it is for me. This new feature, which I’m calling "Promotions," provides me with compensation to do what I love: collaborate and build free software that is used by 1000's of websites.

Getting paid to write open source software is a known challenge. I’ve been exploring many options and researching how other open source projects promote and charge for add-ons, support, and additional services.

Promise: Free of Charge

Please understand I have no intention of ever charging for add-ons. That said, if people in the Drupal community started sponsoring features, I’d be completely on board. Is offering paid support a viable option? I’m not sure. I think promoting additional services is a proven approach. Many companies provide SaaS solutions and hosting services for Drupal. I’ve spent the past year learning how to promote myself via my website, blog posts, and presentations at conferences. Promoting myself in all these ways led me to recognize that my best opportunity lies directly within the Webform module's user experience.

Research: Promotional Banner

Ninja Forms for Wordpress has an amazing user experience. When installing Ninja Forms, there is a "Ninja banner" which promotes the plugin's latest features. I have never seen a Drupal module display a promotional banner or ​callout within the actual module. Project pages rarely contain promotional callouts. Banners and splash screens are part of the typical software experience. I realized I needed to sell the Drupal community on having a promotional banner within the Webform module's user experience.

Challenge: Selling Value

So I embarked on the challenge of adding a promotional banner to the Webform module. A good way to sell someone something is to show its value. My concept is that if I provide enough value to the Webform module, people will be more comfortable with seeing a promotional callout. I’ve worked really hard to improve the overall quality and value of the Webform module by adding better support, documentation, and training.

Support: Answering Questions

All community interactions with a Drupal module begin in the module's issue queue. On a daily basis, I try to answer support questions, fix bugs, and implement new features. Besides providing daily support, I’ve decided to have monthly releases.

As I started answering support questions, a natural and beneficial progression emerged: I began moving the questions and answers into the Webform's document as recipes.

Document: Collecting Recipes

The Webform Cookbook helps keep track of custom code snippets and tricks in recipes. Most recipes begin with issues of Drupal.org or question on Drupal Answers. I’m better at writing code than I am writing words. Still, I’m trying my best to provide documentation and code examples.

My discomfort with writing led me to experiment with creating screencasts.

Train: Creating Screencasts

Learning a Drupal module can be overwhelming. It seems to me that video tutorials and walkthroughs help people relax so they can start the process. Researching other form builders, I noticed other organizations were using inline contextual videos within the software's user interface. I began recording screencasts and placing them throughout the Webform module. It’s a feature that has received a lot of positive feedback and has successfully heightened the Webform module’s value.

Add-Ons: Organizing Related Projects

The Webform module for Drupal 8 can do many things, but the truly amazing stuff happens when Drupal's army of the developers built additional contrib module's that extend and enhance the Webform module. There are hundreds of Webform-related projects for Drupal 7 available and I decided to try to organize and categories Webform-related projects for Drupal 8 within an Add-ons section.

The Add-ons page in the Webform module and on Drupal.org provide an organized and maintained list of modules. Having dedicated page-to-list related projects has provided me with the opportunity to start exploring promotions.

Donations: Why I Don’t Ask For Money

Early on in the development of YAML Form, which became the Webform module, I thought about adding a "Donate Now" message to the Webform module's release notes and user interface. After talking to other module maintainers, I realized soliciting donations is not my best approach.

Most people are not going to pay or donate to software that they can get for free.

Promotions: Partnering with Lingotek to Integrate Translation

Knowing that people are willing to pay for a service, I decided I’d have to either create a service or find a service that people would be willing to pay for.

Around the same time, my client Memorial Sloan Kettering (MSK) was exploring translating their Patient Education materials. At DrupalCon New Orleans, MSK and I starting to talking to Lingotek at their booth. Within a few months, MSK became a Lingotek customer. As a result, I started integrating Lingotek's module and services into MSK's Drupal 8 website.

The Lingotek-Inside Drupal Translation Module integrates a Translation Management System directly into Drupal, allowing the Drupal community to use professional-grade translation technologies (e.g. machine translation, translation memory, CAT tool) without ever having to leave the comfort of the Drupal environment.

I have first-hand experience working with multiple members of Lingotek's team during their onboarding, implementation, and support process. I even contributed a few patches back to the Lingotek-Inside Drupal Translation Module. MSK's initial engagement with Lingotek only involved translated documents, a process that got me thinking. I started to experiment with translating Webforms via Lingotek. In a matter of seconds, I was able to fully translate every aspect of a Webform, including backend error messages and confirmation emails. A lightbulb went off in my head: Translations via Lingotek are a service--a valuable service.

I can say with confidence that valuable services, in any language, are a good thing.​

At DrupalCon Baltimore, I showed Lingotek how easy it was to demo their services by translating a Webform in less than a minute. This summer I became a Lingotek partner.

Referrals: Lingotek’s Multilingual Module Adds Real Value to the Drupal Community

Partnering with Lingotek is exciting because their paid service adds real value to the Drupal community. It is easy for me talk about Lingotek's services and it only takes a few second to show you how to translate a webform.

Now, I’d like to refer you to Lingotek.

Lingotek pays a software referral fee to partners who engage potential clients. My goal is to have these software referral fees fund my ongoing effort to improving and making the Webform for Drupal 8 module awesome - in multiple languages!!!.

Sign up and try Lingotek

Feedback: How can we get paid to write Open Source software?

I have been as transparent as possible. I am not asking for permission, but I am looking for feedback

Anyone in the Webform issue queue can see that I like to get things done. I aim to iron out one issue at a time and quickly move on to the next problem. Currently, I’m trying to solve the predicament, "How can we get paid to write Open Source software?" Open Source software is about the freedom of creating and sharing software. What I’d like to try is a new way to promote and market services within an installed Drupal module. Instead of discussing this concept, I decided to just implement this feature and fully document the work in the Webform issue queue and thought process here.

As always, my intention is to expand the horizons and reach of the Webform module and Drupal

I sincerely hope that no one is offended by these promotions, which can be disabled in the Webform admin settings page. I’m optimistic that other module maintainers can follow my lead, while I respect that the community may want to discuss and define the best practices and recommendations for promoting paid services within the Drupal community. With an open mind and a high esteem for the invaluable collaboration forever present in our community, I welcome all suggestions and thoughts.

Thank you for reading.

Almost done…

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

OKSubscriptions powered by Strikingly

Jun 29 2017
Jun 29

Webform 8.x-5.x-beta14 has become a significant release because it addresses several important features and milestones listed on the Webform roadmap, including support for multiple drafts, Ajax-enhancing submission forms and the administrative UI.

Before I start to "show-n-telling" you about these cool new features, wanted to announce that I am targeting monthly releases and explain my goals for each release of the Webform module.

Monthly Releases

Initially,I was reluctant to publically commit to regular releases for software that I am maintaining for free. Turns out my public commitment is a good thing. Targeting regular releases motivates me to organize the Webform's roadmap and issue queue while iteratively working on fixing bugs and adding new features. I’m trying to take an agile approach with maintaining the Webform module that seeks to iteratively implement working features knowing that features and functionality can and should evolve over time.

The Webform for Drupal 8 (formerly known as YAML Form module) is a completely new codebase striving to reach reasonable feature parity with the Webform 7.x-4.x module, which is used by a half million Drupal 7 websites. I've also looked at the Webform ecosystem for Drupal 7 - gradually I’m integrating key Webform add-on modules into the core Webform module for Drupal 8.

Ajaxifying Webform Forms and User Interface

The Webform Ajax module is a perfect example of a contrib module for Drupal 7 that I wanted to add to the core Webform module. Personally, similar to the Views module's Ajax support, I anticipated there’d be a simple checkbox to Ajaxify a webform. Ultimately, the Drupal community's discussion about porting the Webform Ajax module and AndyF's very well thought out starting point, helped me get this work done.

Another benefit of figuring out how to Ajaxify a webform, was abstracting the Ajax callbacks and behaviors into a reusable PHP traits, which then could be used to add the Ajax support to the Webform admin UI. The performance of the Webform UI was, and still is, a pain point for me. Reloading the entire page after every element update seems kludgy in this day and age of rich front-end applications. When combined with experimental system tray, the Ajax-enabled Webform UI is not merely cool - the Webform module's user experience starts to feel fluid and easy to use.

It is time for the "show" part of this "show-n-tell" blog post.

User Submission Management

Aside from improving the overall user experience, I also feel it’s important to continually broaden the Webform module's comprehensive capabilities. For the past decade, the Webform module has been used to quickly build forms and surveys. Some developers have also built custom application systems, using a variety of add-on modules and custom code. A key aspect to building custom applications using the Webform module is managing user submissions. The Webform module includes the ability to allow users to save a draft and view previous submissions. A few months ago, ptsimard posted a feature request with a patch to allow multiple drafts per users, leading me to contemplate additional user submission management improvements. Along with supporting multiple drafts, I concluded that users need to also be able to quickly review their drafts and previous submissions using customized user submission listing pages that link to submissions with customized submission page titles.

Once again, it is time for me to show the new and improved user draft and submission user experience.

What’s ironic about the improved user submission management experience is that even though it can address some of a project's requirement with these new features, limitations still exist. It’s starting to become clear that the Webform module's Views integration is going to be the next feature that needs some love and support. Please checkout the Webform Views module and hopefully we can get it moving forward.

So what’s next?

I just presented Designing and Theme Webforms for Drupal 8 at Design4Drupal. While there, Ethan Marcotte's "Responsive Design: Beyond Our Devices" presentation completely blew me away. Component-based design patterns are being implemented in most Drupal 8 themes and designs. Ethan's presentation made me realize that the Webform module needs to provide a style guide so that designers can fully understand how to design and customize forms and element in Drupal 8.

It’s also time to start thinking about providing a supported Webform migration from D6/D7 to Drupal 8. No migration in Drupal is 100% perfect, but we need to provide developers with a solid starting pointing for migrating webforms and submissions.

Finally, I’ll be doing a Webform 8-x.5.x presentation at Drupal GovCon, which focuses on building rich applications, like event registrations, petitions, and job applications using the Webform module.

For now, I hope you enjoy the latest release of the Webform module for Drupal 8.

Download Webform 8.x-5.x-beta14/beta15

Almost done…

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

OKSubscriptions powered by Strikingly

Jun 14 2017
Jun 14

Hi, my name is Jacob Rockowitz and I'm the individual responsible for maintaining the Webform module for Drupal 8. Two weeks ago, I posted Where Do We Come From? What Are We? Where Are We Going? documenting my journey and experience building and maintaining the the Webform module for Drupal 8. My goal was to document the current state of the Webform module, while simultaneously planning for the project’s future growth and sustainability. One of the steps toward accomplishing this is an idea I put together called "Sponsor a Feature".

"Sponsor a Feature" is a process encouraging organizations to hire Open-source software maintainers and contributors to build features and fix issues that directly impact a company's project. Two key concepts behind "Sponsor a Feature": all work would be open source and the sponsoring organization would pay for tangible and immediate results directly to the working individuals.

I feel that selling "Sponsor a Feature" to the Drupal community is going to be an uphill climb, especially because no one can technically sell Drupal. In other words, no one is used to paying directly for open source work. For now, I am going to tread lightly when talking about "Sponsor a Feature". For example, last week, I wrote about how Crowdfunding does not help grow Drupal's community to explore the different ways people are currently funding open source development. On Twitter, Adam Bergstein‏ (@n3rdstein) and I began a conversation about how an organization might pay a project maintain/developer.

Putting together an agreement that pays a developer to deliver tangible results is going to be one of the key challenges to "Sponsor a Feature". We need to make it easy for a sponsoring organizations and maintainers to sign a legally-binding agreement attached to a SOW (Statement of Work). Protecting both parties and the open source nature of the work is essential.

"Signing the agreement" is a major milestone and challenge for projects. Kennesaw State University recently sponsored adding three new features to the Webform module. Signing the agreement required some back-and-forth, despite the fact that the agreement was pretty much a standard "Work-for-Hire" with a Open-source addendum. This case got me wondering - would it be possible to collaboratively create a reusable agreement/template for "Sponsor a Feature" that could be open sourced, more specifically, assign a Creative Commons license?

Would a reusable and free-to-use agreement template make it easier for organizations to sponsor Open-source development?

There can't be a one-size fits all agreement template that works for every project, however key clauses that respect Drupal's GPL, a sponsor's confidentiality, and a developer's liability could be defined. Keep in mind, if successful, a Creative Commons "Sponsor a Feature" agreement would become a living document - one that would be subject to continual improvements and tweaks.

A core agreement could streamline the process of "Sponsor a Feature" for the Webform module and other projects for organizations and maintainers. Providing a "Sponsor a Feature" agreement template, says we mean business - a good thing for a developers like me, who want to write and maintain Open source software and to be compensated for it. Another key concept for "Sponsor a Feature" is going to be "transparency", which is part of Open-source and the Drupal community. It is also precisely why I am writing this blog post.

My next step involves reaching out to lawyers within the Open-source community - to explore the possibilities and realities. For any lawyers, inspired by this blog post, please note names and practices can and should attributed to this agreement, similar to how sponsoring organizations are listed on a Drupal project's page.

For now, I wanted to reach out and share this idea with the Drupal community. I welcome your feedback in the comments below. My blog posts and questions about "Sponsor a Feature" will continue with the hope that a future blog post will result, including a Creative Commons "Sponsor a Feature" agreement template for the Drupal community. And from there? We’ll work openly to collaborate and improve - the same way the Drupal community has always done.

It’s gotten us this far, which I think is fair to say (and know many who would agree), it’s nothing to sniff at.

I look forward to hearing from you.

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

Almost done…

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

OKSubscriptions powered by Strikingly

Jun 07 2017
Jun 07

First off, I want emphasize that the below blog post is my opinion and personal feelings as someone who has spent the past year building the Webform 8.x-5.x module for the Drupal community. Now I want to see it continue to grow and flourish. There are many thought leaders, including Dries, that have contemplated and publicly discussed the concept and benefits of crowdfunding and have used this approach to fund Drupal 8 core and module development.

"Crowdfunding is the practice of funding a project or venture by raising monetary contributions from a large number of people."


Drupal 8 was, and still is, a monolithic accomplishment - one that continues to be an ambitious undertaking to maintain and improve. The Drupal community might still be waiting for Drupal 8 to be released if organizations did not crowdfund and accelerate D8. It is our togetherness, our pooling of our resources, that allows us to accomplish great things, like Drupal. At the same time, the Drupal community is made up of a network of relationships and collaborations. Drupal and Open-source’s success depends on its collaborative community, which is driven by relationships. Crowdfunding solves a big problem, pooling resources to fund open source, but it does not build relationships. Drupal's strength lies in its community, bonded together by healthy and productive relationships.

"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."

I feel that crowdfunding, especially within the Drupal contributed project space, is just handing out fish without teaching project maintainers how to fish or even companies how to properly hand out fish. Crowdfunding Drupal projects does not build relationships between project maintainers and organizations/companies. The most obvious issue is that crowdfunding typically has a limited number of fish. Conversely, dozens of companies are throwing fish, aka money, into a pool that is drained by project maintainers, who don't even know the origin of this particular fish. Finally, the most significant word in the above quote is "teach." Teaching involves the interaction and relationship between a teacher and student. Crowdfunding provides no such interaction. Basically, crowdfunding is providing funds to just try and complete the job. Hopefully, I’ve illustrated that although crowdfunding has obvious benefits, it can inherently diminish the potential to build relationships within the Drupal community.

Relationships and mentoring is vital to the Drupal community. Drupal.org user profiles highlight mentors and every core sprint includes a mentoring track. Drupal.org business profiles highlight employees and supported projects. Prioritizing the value and importance of strong and lasting relationships in the Drupal community needs to continue. And in order to grow and evolve, those strong and lasting relationships require consistent and constant care. Connecting developers with the companies that use their product should become a primary goal. I strongly feel an evolution in this direction will undoubtedly serve to strengthen everyone and every project.

Attending the business summit at DrupalCon Baltimore, one of the most common pain points I observed is that companies have difficulty finding talent. One of the most concrete solutions was growing it; by hiring a smart junior developer and growing them into a senior developer. The Drupal community has tens of thousands eager active developers looking to be appreciated, mentored, and compensated. Maybe the best way for a company to find talent in the Drupal community is to directly engage and grow the talent that currently exists.

Picture this: you’re a college student who created a Drupal project that caught the attention of a talented software architect who works for respected Drupal company. S/he contacts you and say "Hey, we really like what you did with module X, but our client needs this specific accessibility issue fixed ASAP. We can give you $600 to fix the problem, and I’ll also look over your patch and see if I can help you out. BTW, we sponsor drinks at the local Drupal meetup. You should feel to stop by and say hi."

The potential benefits of this interaction are beyond positive for a student - it exhibits a sense of appreciation and value. Maybe you’re too busy with your studies to do some side work. But let’s say you’re not. You do the work, you actually get some money to pay for school and you have a new bullet point to add to your resume under ‘Experience’. Not to mention, during this process you get to be mentored by an experienced software architect.

The software architect, who is the teacher, feels the sense of accomplishment that comes from helping someone learn and complete a task. The company who provided the $600, may have just vetted and recruited their next junior developer. At the very least, the college student now has a story to relate (there’s that crucial word again) about when they worked for X company during their college studies. A win-win? An invaluable exchange for all concerned? No question.

My goal is to ponder this: Is crowdfunding within the Drupal contributed project space potentially limiting important relationships within our community? I strongly feel that building healthy relationships is extremely worthwhile, yet I also understand the task of doing so is rife with challenges

I’d like to close with this notion - paying someone to do Drupal work is just another type of relationship that benefits the Drupal community. And it’s one that could lead you to discovering your company's next Drupal rockstar.

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

Almost done…

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

OKSubscriptions powered by Strikingly

May 30 2017
May 30

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.

Webform Past

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 Present
(Formerly known as YAML Form)

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.

True story

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.

Webform Future

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:

Open-source empowers communities to build collaborative software, which is completely free to share and use; Open-source never intended to have developers continually working for free.


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.

Almost done…

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

OKSubscriptions powered by Strikingly

May 16 2017
May 16

I’m afraid of the Webform module's issue queue. I see the Webform 8,x-5.x module's usage stats growing and with it, duplicate bug reports are increasing. The webform_update_8025() update hook is going to haunt me for months. Now I’m afraid to write any update hook that touches an existing field definition. I’ve realized that it is time to push back on the Webform module's issue queue before it’s too late.

Hear me out: I’m not looking for a fight - just a solution to a very simple problem. People don't know how to write proper bug reports and feature requests, and they don't like to read the issue queue handbook. The solution could be equally simple, which would be to require them write good tickets.

Plenty of documentation and videos about writing good issues exist. My goal is to make it easier for people to write complete and useful tickets so I can better assist them.

Help us Help you

For now, I have three goals for improving the Webform issue queue process:

  • Provide easy-to-use bug and features templates.
  • Encourage users to employ these bug and feature templates.
  • Show users how to create a good issue.

Provide bug and feature templates

GitHub allows a maintainer to create an issue template and pull request for their repository. I have decided to do the same thing for the Webform module. Drupal.org does not really support issue templates, however I can recommend that people use them by prepopulating the issues' body field

Prepopulate the "Create issue" form

Drupal.org allows an issue's body field to be prepopulated using a querystring parameter, and I’ve been experimenting using this feature with the Webform module's "How can we help you?" menu, which provides a link to 'Report a bug/issue" or "Request a feature." For now, I can only prepopulate the create an issue form with a link to the full template and the key headers.

Teach users how to create "good" issues

This is the biggest challenge and simplest answer to show-and-tell. I think videos are the best means to teaching someone how to do something, and direct messaging is the optimum channel to communicate what you want. All the below code snippets are available here.

First, I’ve updated the Webform Issue queue "Submission guidelines" to include the warning below:

Here is the video about helping up help you.

That said and done, we all know some people are going to ignore the documentation and video. In anticipation of that, I’m going to cut-and-paste the below message into the first comment. This way, when someone creates a “bad” issue, they’ll be presented with the video a second time. Hopefully this will motivate them to update the ticket.

Finally, if the user is new to Drupal, I’m going to give them a pass, restructure their Issue summary, and say "Welcome to the Drupal Community," using the below greeting block:


My solution for wrangling the Webform issue queue isn’t revolutionary - I’m simply trying to improve the look-and-feel, as well as the user experience for onboarding new members of the Drupal community and educating existing ones.

Or as I like to think of it, “Helping Us, Help You.”

Almost done…

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

OKSubscriptions powered by Strikingly


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web