Three years ago, I started to talk about "coming to an agreement within the Drupal community and sponsoring a Webform feature." In that blog post, I discussed creating a reusable and free-to-use agreement template with a defined process which could make it easier for organizations to sponsor feature requests. Now I want to share my current process for handling sponsored feature requests to the Webform module for Drupal 8.

For the past three years, organizations have reached out to me for paid support and feature requests. Adding the ability to import submissions was a feature request paid for by Kennesaw State University. Only two parts of my transaction with Kennesaw State University were publicly visible, the issue on Drupal.org (#2902977) and a blog post.

Sharing my process for handling paid feature requests will hopefully clarify how organizations can sponsor a feature for the Webform module and other Drupal and Open Source projects.

Steps for sponsoring a feature

Sponsoring a feature can be broken down into four key steps:

• Communication
• Documentation
• Agreement
• Payment

Communication

Good communication is one of the keys to the success of any Open Source project. Currently, there are several approaches to initiating the communication process for a sponsored feature.

The easiest and most immediate way to start a sponsored feature request is to create a user account on Drupal.org and then create a feature request in the Webform's issue queue. This feature request becomes that starting point for documentation. The act of creating this ticket begins a discussion, via comments, involving those interested in sponsoring the work and the initial requirements.

Sometimes, organizations are not exactly sure what the scope of work needs to be and may want to reach out to one of the project's maintainers or contributors via Drupal Slack or email using the maintainer or contributor's Drupal.org contact form. When reaching out to a maintainer/contributor, it helps to have written requirements in advance, even if it is a single paragraph or a one-page summary of the problem/challenge.

BTW, I am referring to the person doing the work as a maintainer/contributor because sponsored features don't have to be limited to only a project's maintainer. Open source software development relies on the maintainer-to-contributor relationship. Maintainers and contributors are entitled to be compensated for their contributions.

Once a method of communication is established, a sponsor and maintainer/contributor can begin to document the problem(s) that the feature request is intended to solve, the proposed solution, and the scope of work, all using an issue on Drupal.org.

Documentation

Using Drupal.org's issue queue to document a sponsored feature request allows us to leverage the community's standards and best practices for managing issues. The Drupal community has worked together to define and continually improve how we communicate within our issue queues. Creating a good issue is essential for paid and unpaid contributions. The issue summary template provides us with a starting point for documenting a feature request.

Aside from leveraging the Drupal's community's existing issue queue to collaboratively define the scope of work, there is another bonus to this public process: Transparency. Transparency makes it easier for everyone to collaborate - it provides the opportunity for various interested parties to weigh-in on a feature request's problem and solution.

Realistically, potential sponsors might decide not to pay for a feature. This frequently happens in private responses to proposals. When a publically-defined feature request is rejected, we do not have to throw it away into a digital trash bin. The hard work and collaboration between a sponsor, maintainers, and contributors can sit in the issue queue and be marked as postponed or even closed. In the future, it is not uncommon that another interested party or organization will have the same or a similar feature request. An individual or organization could review the postponed or closed feature request and decide to sponsor it or do the work themselves; ultimately sponsoring the feature.

Optimistically, a sponsor will agree to the scope of work and request a cost estimate with a timeline and agreement.

Agreement

With Open Source and Drupal, community collaboration is built on mutual trust and goodwill. This is reinforced by the GPL license. Further, once the stakeholders have communicated and documented the nature of the paid feature, once it is built there is an explicit understanding that it must be contributed directly back to its Open Source project. Therefore, the general protections from GPL remain inherently applicable. The GPL, along with transparency, helps us to overcome some of the challenges for coming to an agreement. Since the work is publically available, and ownership, intellectual property, and even confidentiality clauses are not needed for the signed agreement, this streamlines the legal process. All that is required for a signed agreement is the scope of work, timeline, and payment.

The simpler the terms are for an agreement, the more likely people are to sign it. I found the most straightforward approach is to paste the entire issue from Drupal.org into a Google Document, add a summary, estimated cost, notes, timeline, payment, and very basic sign-off. Here is an example of a basic template with an example issue.

This basic template makes some assumptions with limited legal protections for both parties, with a fair assumption that both the sponsor and maintainer/contributors are good citizens with good intent.

Good intent has made it easy for me to build a few sponsored features because frankly, I have limited the scope and cost of paid features to reduce risks. No one has not paid me for a sponsored feature, and so far the worst case possible scenario is that I don't get paid for a day or two of work. That all said, the work is at least contributed back to Open Source.

Nonetheless, we want to ensure that we are paid for the work. Any standardized agreement template needs to continually be reviewed and improved. Finding and paying for a professional review and recommendations for a reusable creative commons scope of work and agreement template could be a good use of the Webform module's Open Collective funds, which are intended to help sustain, support, and improve the code and community around the Webform module and Drupal.

Payment

I have found the most significant challenge and hurdle to getting paid by a client is going through their payment processing. Everyone has different workflows for processing and paying invoices. A common and recommended approach is to get 50% at the start of a project and 50% at the completion. This is the best way to build trust and reduce risk.

At sign-off to an agreement, a simple 50% invoice can be emailed and processed. Here is the invoice template that I am currently using for sponsored features.

How payment should be handled depends on the client and maintainer/contributor. There are two possible approaches for processing payments. The more traditional method is a direct payment from the sponsor to the maintainer/contribute. A more transparent approach would be to use the Webform module's Open Collective as an intermediary.

Using the Webform module's Open Collective as intermediary might make organizations feel more comfortable sponsoring a feature because the funds are being transparently exchanged. There is the inherent benefit to a public transaction, which is that it reinforces the need for trust and good faith between the sponsor and maintainer/contributor. Some of us, including myself, also cringe at the potential conflicts that can happen during a paid project, which could then be compounded by a public dispute.

The notion that "funds are being transparently exchanged" can feel awkward and also uncomfortable. We also should not dismiss the fact that Open Collective retains 14% of every transaction as overhead. Personally, I prefer private transactions via my personal S-corp in order to retain as much of the revenue from my work as possible. I have built a fair amount of trust in the Drupal community and organizations currently seem more comfortable paying an individual company vs. transferring funds to an Open Collective, which is a new and unknown entity. However, there are conditions where participants in a feature request may not know each other and the Open Collective method will be preferred by both parties.

Giving back to the community

The fact that the process and result of a sponsored feature are immediately contributed back to the project benefits all parties involved, including the community. Making it possible for an Open Source developer to be paid for their time makes their contribution more sustainable. Still, Open Source projects require infrastructure and money to succeed.

The process for sponsored features via a project's issue queue does rely on Drupal.org's infrastructure. Shouldn't the Drupal Association, which is responsible for Drupal.org's infrastructure, benefit from this transaction? Should both participants in this transaction be members of the Drupal Association? Should a small percentage of this transaction be contributed back to the Drupal Association? How we take paid transactions and properly give a share back to the community is not so simple.

Ideally, we should insist that anyone sponsoring a feature join the Drupal Association and back the Webform module's Open Collective. One concern with this approach is that requiring people and organizations - especially those new to the Drupal community -  to do something like register for and pay for organizational memberships can discourage them from getting involved. For now, we should nudge them to be good citizens and establish trust within their Open Source community by supporting the software and community that they rely on.

Addressing some hesitations and concerns

Sponsoring a feature is a paradigm shift; feedback is always welcomed. As I have talked about sponsored features and Open Collective with people, they have expressed a reasonable concern that Open Source is meant to be "free". The word "Free" in Open Source is open to many interpretations and I want to share my interpretations and thoughts.

Open Source software was never meant to be free software that’s built by developers working for free. Many people and organizations are paid to contribute to Open Source. Most of these transactions are happening behind closed doors with varying approaches. Many open source projects need to be supported and funded to succeed. Open Source started out, and still, is an evolving experiment and collaboration continuing to change the world. There is nothing wrong with paying people to do good work, especially if companies are benefiting from the use of that open source software.

Making it possible for anyone to be paid to contribute to an open source project will remove barriers and diversify our community. My goal is to strengthen our community and to make our collaboration more sustainable.

How do we get started?

The first step is figuring what you might need and then creating an issue on Drupal.org. From there we can start working through the process of documenting your requirements, coming to an agreement, and processing a payment using and improving these templates.

If you want to take a much larger, bolder, and significant first step that earns trust and shows good will, please join the Drupal Association and back the Webform module's Open Collective.