Removing the Biggest Barrier to Contribution

An open source project needs a steady intake of users who supply feedback and improvements, especially in the form of code. Project maintainers need support from other contributors. To make the flow of contribution, we need to help people over one of the biggest (and often overlooked) barriers to contribution: the local development environment. In many cases until now, it has taken hours to prepare and configure a new contributor’s system–just to get them to a point where they can look at the software they might want to contribute to. DDEV Local makes it easy and painless to get a consistent local environment up and running. I’m excited about this new open source tool!

If you’re organizing a contribution sprint for Drupal, Backdrop, WordPress, or TYPO3 CMS, the DRUD team is putting together a Sprint Kit to help run a great event, help contributors get set up quickly, and get the most out of your sprint. Sign up for the DRUD newsletter below!

Getting people into the Open Source Contributor Funnel

Over the last few years, Mike McQuaid, lead maintainer of Homebrew and GitHub employee, has been sharing what he’s learned about effective open source interactions. He’s used the language of sales and marketing to explain how to increase contribution with a model he describes as “The Open Source Contributor Funnel.” As in sales and marketing people move through a funnel. Every contributor starts as a user; every maintainer was once a contributor. The goal is conversion: Get users to make a pull request, and become a contributor.

Slide from Effective Open Source Interactions by Mike McQuaid, used with permission.

What can you do to encourage users to become contributors? Mike’s suggestions all come down to this: Don’t make assumptions about your potential contributors. “Walk people through step by step,” he says. Don’t assume people even know how to use GitHub, or Git, much less write a decent bug report.

Make the steps and process for contribution clear.

Social guidelines are as important as technical guidelines

First-time contribution is a big hurdle to overcome. Matt Asay discovered that users are intimidated by the process and sometimes met with condescension. The maintainers and people already inside the project aren’t always helpful. “Sometimes we’re welcoming. Sometimes we’re specific about what to do. But rarely are we both. That’s a problem for new developers.”

GitHub’s 2017 Open Source Survey confirmed that behavior guidelines are as important as contribution guidelines. To help foster stronger communities, they developed Open Source Guides for project maintainers and contributors. Most of the recommendations are around establishing and documenting expectations and processes. Contribution guidelines, mentoring guidelines, code standards, codes of conduct, and social guidelines can all go hand-in-hand to improve the newcomer experience and sustainability of open source projects.

Make your social guidelines as clear as your technical guidelines.

The biggest barrier: getting a local workspace set up

A group of academic researchers have looked at the barriers that hinder newcomers from contributing to open source software projects. Their findings mirror GitHub’s survey results, in almost all ways but one. The issue with technical onboarding problem didn’t surface in the GitHub Open Source Survey, nor does it appear in their recommendations.

The researchers reported that the biggest problem most people encountered was “Setting up the local workspace was the most reported barrier in our study that demotivated and frustrated many newcomers.” Newcomers’ struggles with workspace setup led them to report feeling “irritated and frustrated.” The researchers also found evidence that this leads directly to demotivation. If you want to make it easy for newcomers to get involved with your project, it is your job to make it easy to get started.

The researchers drew their results from literature reviews of prior research of hundreds of open source projects, and also experimental research done with groups of students. The GitHub sample, on the other hand, was focused on people who were already actively contributing to open source. This included 70% of respondents in full or part-time employment and 85% of those contributing to software development in their main job.

It’s almost like once you’re in, you’ve already forgotten how hard it was to get there. It feels like we’ve got a blind spot in the development community. We have to solve this technical hurdle if we’re going to continue growing and getting contributions from a wider audience.

Overcoming the biggest technical hurdle to contribution

Open source CMS communities spend lots of time thinking about user experience and making the UI end-user friendly … once it’s up and running. Getting set up is not always so easy. There can be a dizzying number of options, depending on what operating system you use, whether and how you install the server stack directly on your machine, use a virtual machine or container-based solutions.

What’s often missing from open source contributor guidelines is getting over the technical onboarding hurdle and remove that final, critical barrier to contribution. People who develop with and contribute to WordPress, TYPO3 CMS, Backdrop, and Drupal don’t need to know how to manage a server stack. And they shouldn’t have to. Standardized container-based local development environments help. We can package entire stacks for DDEV so that contributors can get started with a quick, easy on-ramp, eliminating guesswork, lessening frustration, and reducing the number of variables when determining why something works or doesn’t work.

DDEV’s got your back. Go make your CMS awesome.

The exciting possibilities!

I think back to how much simpler even setting up a single site was for me 15 years ago. One version of PHP, one version of Drupal, one site at a time. While open source modularity has improved quality and technical capabilities, there are huge numbers of dependencies to setting up and managing for any particular site nowadays.

I love this before/after DRUD diagram that shows the … ahem … ridiculous complexity involved in setting up a local workspace that is reliable, durable, consistent, and shareable. And how much simpler and easier it can be with the container-based DDEV tool suite.

I had completed Docker tutorials about a year ago, they have excellent documentation. But I couldn’t get my head around where to get started with practical applications. I’m glad that the DRUD Tech Team are working on making this easy, making it simple, and getting it to a “just works” place for newcomers.

It’s all different with DDEV. If your system already meets the DDEV system requirements or use tools like Homebrew, installing DDEV is a trivial list of commands you can copy and paste. DDEV currently supports WordPress, Drupal, TYPO3 CMS, and Backdrop.

I think about my experience in co-organizing DrupalCamps, sprints, and running training. A tool like DDEV Local would have made it all much much easier.

Your new favorite thing to do will be changing to your working directory, typing `ddev start`, and you’re off!

Sign up for the DRUD Sprint Kit

If you’re organizing a contribution sprint for Drupal, Backdrop, WordPress, or TYPO3 CMS, the DRUD team is putting together a Sprint Kit to help run a great event, help contributors get set up quickly, and get the most out of your sprint. Check out the Sprint Guide, the first piece of the kit. DRUD would also love to talk with you about other ways they might be able to help make your open source community event a success. They’re also kind of suckers for conversations about containers, hosting and deployment stuff and more …