The Growstuff Project

Originally published at Growstuff Blog. You can comment here or there.

Does your company have a corporate social responsibility (CSR) program? Do your staff volunteer on community projects as part of it? Do your software engineers or other technical staff offer their skills to community organisations or other good causes?

If you run an open source project, especially one related to a social cause, have you ever invited companies to participate in your project as part of their CSR efforts? How do you make it easy for CSR volunteers to help out?

I’ve had the opportunity to work with a few different organisations that encourage their staff to contribute to open source as part of their CSR efforts, some more successfully than others. Growstuff also works extensively with volunteers with various background and experience, through in-person coding events and through our distributed online community. Here are some of my tips for successfully matching corporate volunteers with open source projects, and working productively together.

For open source projects

Much of the infrastructure to support CSR volunteers is the same as to support any volunteer developer. Consider whether you have:

• A “get involved” document explaining how to join the project.
• A “getting started” document for developers, to help them set up their development environment.
• An issue tracker, preferably with “bite-sized” or beginner-suitable tasks identified in some way, and with as much information as is needed to implement the features described.
• A “how to contribute” document explaining how to submit patches or pull requests, your coding style guide, etc.
• A list of tasks that can be done without setting up a development environment, eg. testing, documentation, wireframing, tool-building, making standalone apps or widgets. (You may also have a list of purely non-technical tasks, but that’s outside the scope of this post.)
• The ability to promptly review and integrate any work that is done by volunteers.

There are endless resources out there about how to make your project easy to contribute to; any project that hasn’t taken significant steps in this direction is probably not a suitable one for corporate CSR volunteering.

Emma Irwin, Community Education Manager at Mozilla and formerly a Participant Architect at Benetech, working on SocialCoding4Good, points out the importance of open source projects sharing the impact of their work.

I think when employees are engaged in the impact of what they are contributing to, then there is already an investment in being successful when they turn up. If employees don’t understand why, then ‘what’ becomes less compelling. For example, volunteering with the Red Cross is obviously a valuable thing to do because most of us grow up learning the impact and scope of of their work. For software projects the challenge is to bridge the disconnect between the software, and the potential enormity for impact. Mifos is an example of a seemingly small project having large-scale impact in the world, and sharing their story is a very powerful way to engage contributors.

Emma also suggests that if open source projects want to find corporate volunteers, they should seek out companies whose CSR mission is aligned with the project’s. She also recommends sharing stories of what CSR volunteers have accomplished for your project in the past.

On a more logistical note, if you’re hosting volunteers for a fixed period, like a one-day volunteering event, you will need:

• A list of priorities or goals for the event. You could tag issues in your issue tracker, or prepare a separate document listing these.
• A mentor or mentors available to provide orientation and to assist developers with any problems. The number of mentors you need will depend on the number of volunteers and their level of experience.
• If you have a “product owner” separate from your technical team, make sure that they are also available during the CSR volunteering time to answer questions about project goals and priorities.
• If your CSR volunteers will be working remotely, you will need a communication channel that is convenient for them to use. (An IRC channel may be fine for volunteers from an open-source-centric company, but may not suit others.)
• After the event, you should report back to the volunteers’ company to let them know what was achieved, and thank them for their time.

For companies

It’s important for companies to make sure they can offer useful assistance, and not just a veneer of good works. Short-term volunteers who need extensive training cost an open source project time, and don’t return much benefit.

• Find a project with a good technology match. If you’re a Ruby on Rails shop, look for Ruby on Rails projects that need help, and so on. CSR efforts are often organised by non-technical staff, so make sure you get a technical staff member’s advice on this!
• Make sure your volunteers are familiar with version control (eg. Github) and other open source practices. You may need to provide training ahead of time, or give them time and resources for self-paced learning.
• Give plenty of notice. If you are arranging a specific CSR volunteering event, I would suggest arranging it at least a month in advance, to allow the project to get ready for your volunteers.
• Be flexible about time. Many projects are run by volunteers who have other responsibilities during business hours, or are run by geographically distributed teams in different timezones. Evenings or weekends may work better than weekdays. However, this may be a problem for your employees’ work-life balance; please don’t expect or require them to work unpaid overtime!
• Be flexible about numbers. Ask the project how many volunteers they can handle, and follow their guidance. Too few may not be worth the overhead, or too many may overwhelm the open source project team to the point where they can’t provide mentoring or oversight.
• Offer a venue. The open source project team may be able to come join you in person. You might also like to offer to cover travel and incidental expenses.
• Provide a list of volunteers and their roles/skills to the project well in advance. This will help the project plan work that will productively make use of your people’s skills.
• Put your volunteers in touch with the project team directly, at least a week ahead of time, so that the project leaders can help them get ready.

The time factor

Some companies do once-off annual volunteering days, while others have ongoing arrangements for their staff to work on open source and other community projects.

In my experience of running coding get-togethers for Growstuff’s mostly volunteer developers, here’s what I’ve learned about the amount of time volunteers, especially software developers, need to work productively on a project.

• About three hours seems like a “natural” time to work on a project in one hit. Any more and mental exhaustion sets in. This is the length of time we use for our in-person coding meetups, and tends to be the useful length of our remote pairing sessions.
• A new volunteer who knows the technology platform (in Growstuff’s case, Ruby on Rails), is familiar with Github, and has no trouble setting up their development environment can contribute one or two small features or bugfixes in their first three hour session. They will require about 30 minutes’ mentoring or close attention from a project member.
• That same experienced developer will generally progress to contributing medium-large features by their second or third session.
• A new volunteer who doesn’t know Rails, Github, or who has trouble setting up their development environment will require close mentoring for up to two hours of their first session. By the end of it they may be able to submit a tiny change, such as fixing a typo, and get started looking at a small feature/bugfix. They are unlikely to finish a feature/bugfix in their first three hour session.
• The progress of developers in this latter category depends enormously on their other experience (eg. do they know similar languages/technology stacks?) and their ability to pick things up by reading docs and googling. Good learners with previous experience will typically only take a session or two to catch up.
• You can productively hold multiple consecutive three hour coding sessions (eg. over a whole day or a weekend) if you take long breaks in between, have a good lunch, spend some time outdoors and/or moving around, or switch to entirely different types of thinking from time to time (eg. spend some time brainstorming at the whiteboard, rather than head-down in code). However, productivity — not to mention participant enjoyment! — diminishes with every subsequent three hour session, and diminishes more rapidly the less experienced the participants are, as they have to keep more new stuff in their heads.
• Volunteer developers need to revisit the project at least every month to maintain momentum and remember how to work productively on the project. Long gaps in between sessions means they will need to start over with many things: perhaps reinstalling their development environment, re-fetching the code, and re-familiarising themselves with the project’s layout and processes.

The upshot of this for CSR volunteering:

• If you want to set up a short, once-off volunteering session you will need developers who are experienced with the relevant technologies and with open source practices. They will be able to usefully contribute small features in one three hour volunteering session with minimal supervision/overhead. A well set up project (with “getting started” docs, detailed issue tracker, etc) will make this relatively straightforward.
• If volunteers want to spend a full day (or longer) working on a project, the project will need to make considerable effort to arrange a variety of activities for when the volunteers hit mental overload on the code. This will take time and overhead to plan.
• Inexperienced volunteers (who don’t know open source practices or the technology platform) are unlikely to achieve anything significant in their first session of volunteering, and will take a lot of overhead in supervision and mentoring. If an organisation wants to send inexperienced volunteers as part of their CSR efforts, they should consider committing to at least 3-6 volunteering sessions, no more than a month apart.
• Some open source projects (like Growstuff!) are happy to provide training and mentoring for inexperienced volunteers as part of their own community process: to spread awareness of open source and related collaborative software development processes, to build skills among under-served communities, or in the hope of recruiting some ongoing contributors to their projects. However, companies doing CSR should understand that in this situation their staff are receiving a service (training) while contributing to a fairly indirect and abstract benefit for the project, rather than contributing a direct and immediate benefit.

Emma Irwin pointed out two major problems she sees when it comes to organisations estimating the time their employees will spend volunteering:

Underestimating onboarding time, environment setup, these kinds of things that frustrate people. So a company planning a half day event around code-contribution isn’t realistic (in many cases). Design contribution is probably the exception.

Underestimating employees’ availability, or manager-buy-in. They need to make time for employees. This means clearing it with managers – that this person will be unavailable, and any milestones associated with their work need to be adjusted. Otherwise it’s just added stress, and that’s not rewarding – we have enough of that.

How to connect

The one piece missing here seems to be how find a suitable open source project (if you’re a company looking to volunteer), or how to find a company with a CSR volunteering program (if you’re an open source project).

Two organisations that may be able to help make this connection are OpenHatch, who are mostly focused on helping people develop skills to make their first open source contribution and whose website lists hundreds of projects looking for volunteers, and SocialCoding4Good, which connects volunteers with non-profit open source projects in areas such as civic engagement, crisis response, disaster relief, education, health, human rights, and poverty alleviation.

Unfortunately, most of the (many, many) blog posts and articles encouraging people to get involved in open source are aimed at individual contributors, rather than organisations. If you know of any other good resources discussing CSR volunteering, or connecting volunteers with suitable open source projects, please let us know!