For the past two months, I have openly discussed my career-changing decision, to Drupal or not to Drupal. My employment with my current organization remains stable for the foreseeable future, but they will no longer be using Drupal in a year. My open discussion has led to some interesting thoughts, feedback, assumptions, and an overwhelming amount of appreciation for the work I have contributed to Drupal, and the understanding that I can no longer continue to contribute to Drupal in my “free-time.”

Not surprisingly, my posts triggered some discussion about possibly monetizing some aspects of the Webform modules. I need to state that…

The best way to clarify my stance on “paid” modules is to define what I feel a module is in the Drupal community.

I use the term “module” in this post, but I am talking about any collection or package of code in the Drupal community that accomplishes a task. A package of code in the Drupal community can be anything from module, theme and could even be a complex patch.

Our “tasks” are not simply developing modules or themes in the Drupal community but the whole “kit and caboodle” around the software and community. The Webform module’s success as we know it would not exist without people’s feedback, testing, documentation, and general contributions. Likewise, the Webform module wouldn’t exist without Drupal core’s Form API. The hosting and testing infrastructure that the Drupal Association provides for the Webform module is part of this collaboration. The community-run events help inspire people to get involved. A Drupal module, like Webform, is a massive collaboration. We are all linked and interdependent on each other to produce something massive.

Society would be nowhere without the ability to share our ideas and collaborate. People with great ideas deserve to be paid for them. At the same time, there is a benefit to sharing ideas, as public goods, for the greater good. The value of open source software is we are sharing our ideas and giving people the freedom to use and improve upon them.

My experience with proprietary software included every feature costing extra, and simply learning the software costs money. The cost of ownership for this proprietary makes using the software inaccessible to people and organizations with fewer means. Besides being financially inaccessible, most aspects of the software were inaccessible to people with disabilities. As a developer, there were black boxes of code in the proprietary software that I couldn’t access or find good documentation.

I strongly feel that having paid modules will hurt this accessibility and inclusivity. In the Drupal community, we care about our software and community. But caring does not pay the bills or keep the lights on at night.

Here’s my current pickle: I would not want someone to pay for the Webform module, but I want to be paid for my work. Adding money to the equation of our collaboration complicates things and has the potential to hurt it. It could discourage people from getting involved. And yet, organizations are making money from our collaboration.

I am a passionate developer and a mediocre salesperson. Still, I have accepted that our collaboration, Drupal, is about selling goods and services. At the end of the day, organizations need to earn a profit, and people want to be paid. My stepfather said to me once, “a nonprofit is not for profit; people working for the nonprofit need to be paid." This is a slightly cynical statement, but everyone needs money to survive.

I will briefly channel my repressed inner salesperson and state that the Drupal community needs to recognize that we are part of a massive sales funnel that leads to profits for most organizations. A sales funnel is the process of a potential customer becoming an actual customer. Our free code is at the top of the sales funnel.

In the Drupal community, our sales funnel (a.k.a. Purchase funnel) is leading to hosting, services, and consulting. Our awareness is massive in our sales funnel because anyone can install, try our product, use it, and join our community. Very few organizations are just installing Drupal and going at it with only their internal resources. Most organizations engage with a vendor at some point in their Drupal journey.

As I look back, I realize that my biggest mistake is not the contribution of my free time to Drupal, but rather it’s that I didn’t recognize the sales funnel I was creating with the Webform module. Until recently, I never sorted out how to make my contribution sustainable. It might be painful to hear, but we need to accept that salespeople are part of our collaboration and community.

As controversial as it might seem, Drupal.org could be the biggest lead generator for organizations in the Drupal community. Leveraging Drupal.org as a lead generator, possibly backed by some marketing tools like behavior tracking, personalization, and targeted email, could be the best way for the Drupal Association to grow and help strengthen the Drupal community.

Large enterprise software vendors spend tens of thousands of dollars acquiring new customers. Imagine if Drupal.org could better direct new consumers of Drupal to the appropriate vendors, thus lowering the cost of acquiring new customers.

For now, let’s return to discussing the sales funnel regarding modules and code and contributions.

Instead of charging for code, we need to encourage, and maybe force, organizations to contribute. As a maintainer, I could prioritize support to members of the Drupal Association or organizations with a certain amount of commit credits or simply showing some commitment to our collaboration.

I think Matt Glaman’s thoughts on gated release have merit. He is right to observe that...

I am blown away by the fact that nowhere in our free software user interface is that the software is free and built by people and organizations collaborating. You bet your bottom dollar that every piece of proprietary software includes terms and conditions, a license agreement, and a sense of ownership.

Right now, I am glad I am not a vendor or salesperson because I could not be so blunt. I am sick of those big digital agencies overcharging for half-baked Drupal services building broken Drupal sites. They are the biggest leeches in our community and industry, and their bad code hurts our collaboration.

When reviewing and editing this post, I realized that I want to emphasize the importance of requiring businesses and organizations to contribute while always encouraging individual people to use our software and contribute something back to the community.

The fact that anyone in the world can install our software and contribute to it is incredibly powerful. The reality that organizations are making money from our software needs to be addressed. The giant sales funnel that we have created with our free and open-source code and community has created more opportunities than any proprietary system. We should make sure not to mess it up. We should also make sure we don’t lose sight of its worth - its monetary worth, its worth in terms of meaningful collaboration, and very large (potential) position in sales funnels worldwide.

The pickle of a problem that I have created with the Webform module is a little unique due to the module’s size and complexity combined with its importance in the community. With everything I have just said about me being against paid modules, it is hard not to listen to people’s suggestions and think about monetizing certain aspects of the Webform module. I will try to address this challenge in my next blog post.

For now, are we ready to see our free code as part of a giant sales funnel? Are we prepared to start targeting potential customers on Drupal.org? Can we ostracize the leeching organizations while nurturing supporting organizations and still always welcome new people (a.k.a. potential contributors) to our community?

As stated earlier, I am not a salesperson and this post is more of a response and call to action with a small rant. If you want to read some very insightful thoughts about selling open source, check out these blog posts (Part 1, Part 2, and Part 3) by Henrik Ingo.