Overview

The single biggest reason that the Drupal Association is such a great place to work is the Drupal community. You all dedicated your blood, sweat, and tears to make Drupal amazing, and that includes work on Drupal.org, our community’s home. As the organization charged with maintaining Drupal.org, we’ve relied on a pastiche of volunteer support, contractors (at various rate scales), and staff. One of the side effects is that there is a lot of confusion - what role should staff play? When do we hire contractors? When is it ok to ask someone to volunteer their time vs. pay them for it?

At the Association, we are going to spend a fair amount of time digging into these questions over the next few months. I want to kick that conversation off today with a request for feedback as we start to develop a Procurement Policy that the Board will vote to adopt. The Procurement Policy specifically addresses paid vs. volunteer work, and will not take into consideration the third part of this conversation, staff. We’ll tackle that in another time.

Please note that this is simply a draft, to get feedback, so none of this is considered final.

Is this paid work, or volunteer work?

In thinking about how we might create a Procurement Policy, we decided that there are probably no hard and fast rules for this conversation. Rather, we were able to draft some indicators - if, while considering if the work were paid or volunteer work, we could tick off several or most of these indicators, the answer would lean towards hiring a contractor, rather than looking for a volunteer.

For paid vs. volunteer work, the indicators we identified are:

• Responsiveness/Urgency: If an issue comes up that is urgent in nature or requires extreme responsiveness, we may consider a contractor for the role.
• Is it mission critical?: If the project is holding up Drupal core development or impacts Drupal.org severely, we may consider hiring a contractor rather than trying to find a volunteer.
• Is it time bound?: If the project has a beginning, a middle, and an end, it can be well suited for a volunteer. Ongoing projects with no end date might be better handled by a contractor (if staff are not available). Think ongoing security updates or server maintenance. In many cases, we might take this kind of work to a contractor, but still use volunteers in an advisory capacity (think Jeremy and Testbots or Narayan and servers). It's just not fair to ask these guys to labor on endlessly and burn them out.
• Unique skill set: If a project requires a very unique skill set - one not found broadly in the Drupal community - it may make more sense to hire a contractor or work on the project in-house. We DO want to broaden the knowledge of how D.O works in the community, so we will always seek new people to work with as volunteers, but especially if the project is urgent and the skill set is unique, we would seek a contractor to complete the work. It’s worth noting that we will include a requirement for documentation in all contracted work.
• Does it increase the velocity of contributors? If the project makes it easier for volunteers to contribute work to the project (core, D.O, or otherwise), then it may make sense just to pay for the work to ensure it gets done and makes everyone's life easier. To be clear - we are not suggesting we would hire people to write core code - but we may hire people to write code for D.O that increases the velocity of people who are writing core code, i.e. making their lives easier.
• Is there a volunteer waiting in the wings? Drupal and the Drupal Association value learning, and we want our community to grow and learn. Volunteer opportunities are a great way to do that. So, if we have a volunteer waiting in the wings, we need to strongly consider that, or find ways to involve the volunteer in a contractor’s work so that everybody wins.

If a project comes up that can check several of these boxes, we'd likely hire a contractor. This is the framework we would use, but we won't apply it rigidly.

In Kind Trades

For in-kind trades, we are looking to ensure that we are doing things with transparency and that we are filling actual needs here at the Association. Here, things are a little more rule-bound:

• We have a need: Lots of folks offer up products and services for the Association to use free of charge. However, we don't need a lot of them at the moment they are offered (though we may need them in the future. Come back and talk to us in the future!). We won't conduct an in-kind trade for a product or service that does not help us meet our mission.
• We can use it: There are lots of things we "need" at the Association that we simply don't have the capacity to use well. If we don't have the staff or the plan to use the tool or service, we will not conduct the trade.
• Public bidding process: As with our procurement policy, for any tool or service with a value of $25,000 or greater, we will conduct a public bidding process, making it clear that we are requesting an in-kind trade. The public bidding process gives other companies a chance to participate. The language would align with our current purchasing policy and be worded like this: Trades or gifts of services and/or products valued at $25,000 or more must demonstrate that a competitive bidding process had been undertaken. The Association must demonstrate that they have requested quotes from and evaluated at least three different vendors to demonstrate that value is being received for in-kind trade made and that the best possible price point has been achieved. Bids cannot be broken up to avoid the $25,000 mark. For needs less than $25,000, we will not need to conduct a public bidding process, but may choose to do so anyhow.
• Recording of In-Kind Income: All goods and services received and given as part of the in-kind trade will be recorded on our books as such, and will be made visible on our public financial statements. All trades will be documented with a Letter of Agreement that establishes the value of the product and the traded item for IRS records.

What Next?

Now we need to know what you think. Please share your comments with us so we can explore this issue more and come up with a policy that makes sense. Thanks in advance for your questions and ideas!

Cross posted on Drupal Association Group.

Flickr photo of DrupalCon Munich volunteers: pdjohnson