Volunteer or Contractor? Help the Association Answer This Question

holly.ross.drupal's picture

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!

Comments

Hi Holly, My first impression

fizk's picture

Hi Holly,

My first impression from reading the paid vs. volunteer indicator list is that it's heavily in favour of hiring a contractor. It also seems like there's a strong demand for contractors due to, perhaps, a low supply of volunteers.

My assumption is that volunteers should be sought after first and foremost, and when that fails, the D.A. would turn to contractors - and this should apply in every situation, including urgent issues.

What is the estimated budget impact on using the indicator list as it is right now?

Among members of the D.A., what is the current demand for hiring contractors?

On average, how many critical issues could have been resolved much quicker, and more thoroughly, by hiring a contractor vs. waiting to find a volunteer, in the past 12 - 24 months?

Cheers,
Yonas

It's a little complicated....

holly.ross.drupal's picture

Hi Yonas -

First, thanks for reading and replying. I really appreciate the feedback.

I think the push for us not to strongly prefer one thing over the other - contractors over volunteers - but to match the right actor to the right job. For example, we don't think it's fair to ask a volunteer to perform routine tasks every week on the servers - indefinitely. But we wouldn't want to spend money hire contractors to code the low hanging fruit. We definitely do not want to ruin the project's rich history with volunteers, so we would absolutely have a volunteer first policy, per the post. If there's someone who wants the job, and is capable, we're going to figure out how to include them.

You are probably right that volunteer engagement on D.O is low (although I have not been here long enough to know how true that is, I've definitely heard that several times). If we are going to better use volunteers on the site, we have to prepare for volunteers in a few key ways:

1) We need to make it easier for volunteers to access fully featured dev environments, and we need those to be localized if possible. We're currently working on that very issue.

2) Once it's technically easier to involve volunteers, we need a staff person who can focus on volunteers more consistently, helping them to find the right issues and providing support as they navigate the very special ins and outs of Drupal.org.

3) We need to concentrate on items 1 and 2 and build up more volunteers who know about Drupal.org, especially Project module, so that more people can be more helpful consistently.

So to answer your questions:

1) I'm not sure what the budget impact would be. At this point, we've got poor systems for tracking this - but your question is important. I'm going to see if we can find a way to track volunteer hours and come up with some numbers for 2014.

2) We hire contractors now when we have an urgent or very large project that needs lots of hands., and where a volunteer is not readily available. Part of the reason we turn to contractors is lack of volunteers, but part of our lack of volunteers is our own issue to fix (see above).

3) Again, because we can't really help volunteers effectively right now, that's tough for us to measure.

In sum - know that we're not planning on abandoning volunteering. In fact, we are working hard to improve our ability to serve volunteers so that when they are generous enough to give us our time, we can respect that and make it a good experience.

Best,
Holly

I have read this twice now

greggles's picture

I have read this twice now and think it's solid.

Thanks for working on it. I think a lot of this transition has been happening for a while, but it seems great to formalize it.

Thanks Greg!

holly.ross.drupal's picture

For taking the time, and for the thumbs up!

community versus paid work

benvantende's picture

Hi Holly,

In the TYPO3 community we have these same things to think about. Let's call them things not issues ;) I am currently still working as a fully paid community manager on a budget I request every year. With some changes to the structure of our TYPO3 Association (voting by the members) most paid development has been stopped. The TYPO3 association does however grant budgets for the many code sprints we have, where time is not paid, but lodging, travel, food and the usual stuff. There is a lot of effort to get things done based on community effort, but that does not always work. We had an effort for some pressing topics that needed to be addressed as fundraising on www.workpackages.org. Quite interesting, because we also have some other private fundraisers that are quite successful, which do not directly involve the association. One thing that we have been able to solidly secure on a contract is maintenance of our community hub typo3.org. We have an SLA with the contractor and the contractor donates an amount of time as well. The reason we have this is obvious I would say. That website needs to be up at all times.

So you see there are a number of options how a community can contribute, but sometimes urgency or priority dictates the choice.

It is a big challenge to connect people fro your community to teams and open up the community and the infra structure as much as possible to be able to interact and contribute to the project. We both have quite big communities. The people are there and willing to do the job, but organising that all is a whole different ballgame.

On a side note: Having a contractor also does not always guarantee that the job gets done.

I hope my input is of some use. I already suggested to @mortendk to exchange knowledge and experience about this in some cross OS CMS panel (CMS Garden?)

Open and transparent

pcambra's picture

As Greg says, it's a solid start and I really like we're in a point where having this in the open it's OK.

I'm exposing my 2 cents in no particular order

  • We need to stand very clear that this policy is for D.O or *.D.O sites and not the Drupal project itself. I know that the current text already says it, but the border is thin and it might drive to misunderstandings.

  • I'm not sure how we're going to cope with current or former volunteers, having an 'ecosystem' where some people are paid and some aren't when they're basically doing similar tasks is not easy to manage and probably not desirable.

  • Related with the point above, if someone has been doing volunteer work for some time and suddenly that work qualifies for a budget, we're creating some kind of expectations on who should get the contract and that's a risk of losing those volunteers.

  • And more related stuff, I really like the hint of the transparency, this needs to be a crystal-transparent process and the requirements and selection process must be open to everyone, otherwise same people/companies will get the contracts again and again (which has happened in the past) and that's no good for the DA or the community.

You make a great point about

holly.ross.drupal's picture

You make a great point about expectations Pedro. The last thing I want to do is alienate a volunteer by hiring a contractor to do work they've been doing for a long time. We're going to have to be very careful about that. I think the key thing is going to be communicating paid opportunities widely and having a clear process for choosing contractors. And of course just being open to discussing it all as we roll it out. We are inevitably going to bump into an issue that's uncomfortable, but we'll have to handle it well and find a resolution we can all live with.

++ too on making it very clear that this is for D.O - at least for right now. That's where we can focus. But eventually, we do need to address subsites.

Look at existing hybrid Non-Profits for your answer

jkealy's picture

I think this is a problem for many volunteer organizations once they reach a certain size. I'd recommend looking at an organization like the Sierra Club which has also moved from a purely volunteer group to a staff/volunteer hybrid.

The volunteers (the club) still run the organization. They elect the board, the president etc. The volunteers provide a great deal (if not most) of the Sierra Club's work. However staff work in many positions where needs are ongoing or where the job is not appealing to volunteers.

The National web site owner is a paid position. The system admins supporting the site are paid. Most of the content providers are volunteers, but Sierra magazine (the flag ship publication) is staffed. Most of the chapter web site owners are volunteers (etc)...

That kind of mixed model seems appealing and it appears that is what you are suggesting here.

And i think staff may be more appropriate that contractors so that continuity can be created...

Sierra Club is a great model,

holly.ross.drupal's picture

Sierra Club is a great model, and one we had in mind when first trying to sort the issues out. We are definitely trying to achieve balance in that way - paid staffers where it makes sense, but a vibrant and well-supported volunteer community as well.

Great clarification on policy

jwalpole's picture

Holly, great post. I think the transparency and clarification are appropriate and well defined. @pcambra's point about D.O. is good. We need to be clear this is for the things we dont really have volunteers for and not Drupal project contributions. Otherwise, thanks for your candor and pro-active communication.

Enable and support volunteers above all.

mallezie's picture

Hello there,

I really like the openness of this discussion. I think that's the first step in creating a balanced and clear process in paid contractors / volunteers collaboration.

I think the most difficult part of the discussion is the question if we want to invest in volunteer participation. Seeing the steps the DA is taking in https://drupal.org/node/2146967 I think the choice is made to encourage volunteer participation's, which is something i'm really glad and excited about.

Another crucial part is defining a clear path of what we wan't to achieve in the coming years. Which is also tackled according to me with the public DA plans for 2014 and further. See: https://association.drupal.org/node/18893

This defines clearly what tasks need to be achieved. If a volunteer wants to help with these, it's clear they have a deadline, and could be 'taken over' by a contractor if not ready on time. If this process is very clear, and communicated, i don't think this is really a problem.
On the other hand it could be very nice to define some 'non-critical' / 'non-time-bound' features, which are most interesting to take on by volunteers. Important in those tasks is, according to me, to use paid staff to help out and encourage volunteers, instead of tackling those self. a paid investment could be to invest paid staff in the task, help and encourage volunteers. For example some task could be tackled by DA staff in 5 hours, or tackled by a volunteer in 20 hours, with one hour of help form a DA staff / paid contractor. Which wins 4 paid hours. And gives satisfaction to the volunteers.

For most work, where a volunteer / contractor choice is needed, I think some sort of following process could tackle most issues / problems.

Hey, we want to do this, anyone willing to help me out. We need someone to manage this project / issue. If managing this project needs great availability, it could be that this needs to be a contractor / staff, to ensue availability for helping out. (Not doing the task, but helping persons do the task).
If the project is critical / has a deadline, and no volunteers are stepping out, it could be that we need to get a contractor to develop / finish the task. (For example the d.o D7 upgrade, it started with the DA encouraging developers, bringing them together, and start the project, and needed contractors to make it to the finish line, which is not a bad process, only problem is that it takes time).
If a process should be taken over by a contractor, i think a clear independent and defined process for choosing someone is key. A volunteer working on this already, has off course some advantages, but sometimes is not the best choice. Communicating clearly, the why's and how's, which off course takes time, but cannot be underestimated is key in not loosing the volunteers, but instead encouraging them to keep helping.
Also to keep in mind is that some volunteers want to stay volunteer, to help out where they can, without the burden of the pressure and expectations. This is what makes Drupal great for volunteers, you can help on everything, in a welcoming environment, and can attract more volunteers for d.o.
Lots of organisation work with a paid staff / contractors / volunteers combination, and work well. If your staff / contractors first job is to work with and encourage volunteers for a project, and time is given to enable that, this works great. Supporting volunteers should be the first task of any paid contractor / staff.
If a task has a welcoming environment, and is challenging, a volunteer driven approach is really possible. Maintenance tasks, and other tasks which need a very defined availability are less volunteer suitable. Mostly because they don't bring value back to the person doing the job.
Volunteers are not paid, not because they are worthless, but because they are priceless.

See you in Szeged, to work on d.o!

Good ideas, some suggestions and questions

nedjo's picture

Important discussion to be having and some good ideas raised--thanks Holly and others for your work so far!

Some suggestions and questions re how we frame the discussion:

  • In the comments we've been making a common and important distinction between drupal.org on the one hand and the Drupal project on the other. But in terms of this policy, presumably we don't want to adopt policy just for one area of Drupal Association work (drupal.org or subsites) and having completely different policy (or no policy at all) in other areas. Rather, we're working to produce policy that provides consistency across all areas of DA work--drupal.org and all the other areas the DA works in. Does this sound right?
  • The current discussion is a bit murky in places as to whether on the paid side we're just talking about contractors or about staff as well. Let's stick to a clear distinction between volunteer on the one side and paid on the other. As Holly suggests, the nuances of when employees are appropriate vs. contractors can come later.
  • When in kind contributions are made, it can be hard to pin down just what if anything is being received in exchange. Are we limiting ourselves to explicit trades? Or does it make more sense to frame the policy around in kind contributions, with trades being a subset? More on this below.

Re volunteer vs. paid work.

  • A basic point that's probably understood by everyone but that we should make explicit is: volunteer work should support - and not supplant, replace, or threaten - existing paid work. See this document from the Hands On Network for related discussion.
  • Re "Is it time bound?", while I see the point, the more I think about it the less useful it seems. There's plenty of appropriate volunteer work that may be ongoing, and conversely we often need contractors or employees to carry out time bound deliverables. So I suggest dropping this point.

Re in kind contributions

  • In the past, companies often in practice have seconded staff to carry out Drupal Association work. These arrangements may have been viewed as a form of volunteering, yet clearly they differ in important ways from volunteer relationships: the employees are carrying out Drupal Association work on staff time and remain ultimately accountable not to the Drupal Association but to their employers. Is this form of work expected to continue? If so, what policy would it fit under--volunteering, in kind contributions, or both?
  • Companies may participate in and contribute to Drupal Association projects for a variety of reasons other than explicit and easily quantified benefits. For example, a Drupal Association project may be a strong fit with a company's current objectives or strategy. As well as the direct benefits of the project, a contributing company may receive fairly intangible but nonetheless valuable benefits--profile, contacts, business leads, and so on. Should a policy on in kind contributions attempt to valorize such benefits? Should this type of contribution be captured in recording of in kind contributions?
  • Similarly, companies may cover the expenses of their employees taking part in Drupal Association work. For example, companies may compensate staff serving on the Drupal Association board and/or cover their travel and accommodation expenses or may pay the costs of employees contributing to Drupal Association projects, like a drupal.org upgrade sprint. Are such expenditures considered in kind contributions that we should track and report on?

In the past, companies often

catch's picture

In the past, companies often in practice have seconded staff to carry out Drupal Association work. These arrangements may have been viewed as a form of volunteering, yet clearly they differ in important ways from volunteer relationships: the employees are carrying out Drupal Association work on staff time and remain ultimately accountable not to the Drupal Association but to their employers. Is this form of work expected to continue? If so, what policy would it fit under--volunteering, in kind contributions, or both?

This is very important to delineate. There's both secondment and some people who use 20% time or similar arrangements to work on *.d.o patches (although the latter is likely impossible to track vs. an individual working on stuff in their own time).

Belatedly, wanted to address

holly.ross.drupal's picture

Belatedly, wanted to address a couple of your questions Nedjo. I'm working this afternoon on synthesizing all this feedback into a draft policy, so to address some of your points:

  • Rather, we're working to produce policy that provides consistency across all areas of DA work. Yes, that's right. Though it should explicitly exclude the Drupal Project. (star).D.O seems to express this neatly for me.
  • Re "Is it time bound?", while I see the point, the more I think about it the less useful it seems. I see your point. I keep mulling on this one though. I am thinking of folks like nnewton who have worked tirelessly doing ongoing server work and basically being responsible for every infra hiccup. I want to make sure that we are not handcuffing volunteers to really laborious tasks AND that the knowledge for these critical ongoing tasks is not held solely outside of the Association. Maybe "Time Bound" is not the right short descriptor. Better ideas?
  • the employees are carrying out Drupal Association work on staff time and remain ultimately accountable not to the Drupal Association but to their employers. Is this form of work expected to continue? If so, what policy would it fit under--volunteering, in kind contributions, or both? Either. depends on the situation.
  • As well as the direct benefits of the project, a contributing company may receive fairly intangible but nonetheless valuable benefits--profile, contacts, business leads, and so on. Should a policy on in kind contributions attempt to valorize such benefits? Should this type of contribution be captured in recording of in kind contributions?Perhaps it SHOULD be, but CAN it? The FASB accounting principles (it's a thing I have to know about - it's like PHP for numbers people) are a little cloudy, but our approach will be to only value benefits that have a demonstrable monetary value. For example, if we trade ad space for a service, we can value the ad space because it's something we sell. We might be able to value exposure if it is quantified (as in, we wrote 3 blog posts about this project and your role). We can't however, value connections made. Does that make sense? If you're actually interested, see http://www.journalofaccountancy.com/Issues/2013/Aug/20137726.htm.
  • For example, companies may compensate staff serving on the Drupal Association board and/or cover their travel and accommodation expenses or may pay the costs of employees contributing to Drupal Association projects, like a drupal.org upgrade sprint. Are such expenditures considered in kind contributions that we should track and report on? That is an interesting question. We have no specific policy around this, and the board can set whatever they see fit, but my preference would be that all board time and expense is volunteered and/or contributed, not recognized as in-kind.
  • Free vs. Paid?

    Michael-Inet's picture

    Hello All,

    One thing that seems to be missing from the "Volunteer or Contractor?" question is, "What is the principal Drupal was founded on?"

    In light of that, I'll make these suggestions:

    • ALL work will be submitted first to the volunteer community.
    • Paid work will go first to past volunteers.
    • Ongoing work will only be handled by staff.

    With that in mind, these suggestions as well:

    And, detail elements to spark further discussion:

    • To bid on a job as a contractor, you must have had 20% (50%?) in prior hours as a volunteer.
    • Re: In kind trades. Take them all, use them to pay for other work.

    #

    volunteer work should support - and not supplant, replace, or threaten - existing paid work.

    I so strongly disagree with this statement. As much work as possible should be available to be done by volunteers. D.O. work should not be to provide someone with a paycheck. How is this statement in agreement with the principal Drupal is founded on?

    #

    And lastly, it is my opinion, that this discussion should be posted on the Jobs group now.

    Best Regards,
    Michael

    PS: Sorry for the bullet points, tired of reading walls of text...

    To bid on a job as a

    catch's picture

    To bid on a job as a contractor, you must have had 20% (50%?) in prior hours as a volunteer.
    Re: In kind trades. Take them all, use them to pay for other work.

    Requiring a percentage of time to be donated for free before you can get paid for it is telling people they have to work for free in the chance that they might possibly get some paid work later. That's like unpaid internships/spec work and would raise serious questions for me about the Drupal Association as an employer.

    With Drupal.org specifically that's also quite impractical. If you required contractors to have previously donated time to the Drupal Association, that would exclude something like hiring a core or contrib module developer to work on an area they have experience in, just because they haven't directly contributed time to the association itself. If you count core/contrib contributions then it becomes a relatively meaningless requirement (or part of a more general hiring criteria) and there's no way to know if that was 'donated' time or not.

    On the other side of this,

    catch's picture

    On the other side of this, people who are working on d.o-specific patches or contrib modules used on d.o aren't necessarily the same people who regularly scan job listings.

    So it may be worth adding a section which includes explicitly seeking out and contacting those people who've already worked on an area when paid work is advertised.

    Hoping for more discussion

    Michael-Inet's picture

    I was hoping for more discussion by the community. Obviously I didn't make my examples extreme enough :(

    So it may be worth adding a section which includes explicitly seeking out and contacting those people who've already worked on an area when paid work is advertised.

    This is more what I had envisioned. Offer paid work first to those that have already done [successful] 'volunteer' work.