Drupal Community Involvement Study, Part 2: Defining "Contribution

Introduction: Over the course of the summer, I've been working on a Master's Thesis focused on the experiences of Drupal contributors, and the roadblocks they face when they try to contribute their talents to the Drupal project. Over the next week or two, I'll be blogging the results from this survey here.

Defining "Contribution"

Of 176 total responses, 150 (85%) said that they had contributed to Drupal in some way. Of the 26 who did not contribute, only a single respondent said that they had not considered contributing. This result is interesting given many models of OSS contribution, in which the majority of users simply use the software, and occasionally report bugs or discuss changes, but only a few participate in actively changing the software, e.g. {Barcellini:2014cr}’s core-periphery model. This finding could also indicate self-selection bias in the participant pool—that is, most of the respondents were highly motivated to answer this particular survey. As the focus of the study is on engaging members of the community that are already highly motivated, but are either not contributing or don’t know how to contribute, this bias was deemed acceptable by the researcher.

Another potential reason for the high number of respondents answering the question positively lies in the definition of “contribute” itself. Early in this research, comments were made about the pilot survey that the word “contribute” had not been clearly defined, so it was difficult to say whether one actually did contribute or not. For example, if one has never contributed code, but organizes local meetups, is that a contribution? If they contribute at sprints, but not generally otherwise, is that a contribution? The interview process and ethnography has revealed a perceived bias in the community towards code contributors, and particularly towards those who contribute code to core; would that same bias be seen here?

As a result of this feedback, the second version of the survey focused on allowing the broadest definition of “contribute” possible, and the list of potential contributions was expanded. The additional items came from survey and interview feedback on the types of individual contributions, as well as feedback from Drupal community members who helpfully reviewed the survey prior to launch. The pilot survey question “Have you ever contributed code or other volunteer work to the Drupal project” was reworded to: “Have you ever contributed to Drupal? This may include writing code or documentation, providing support to new users, providing feedback or bug reports, running Drupal events, performing research related to Drupal, or other related volunteer work.” In addition, the original list of 8 potential contributions was expanded to 18 potential contributions (see Appendix B), including and expansion of community and education-oriented roles, such as “presenting at Drupal Camps and Drupalcons” and “moderating comments in issue queues and forums.”

Contribution Types

Figure 1 below shows the breakdown of reported contributions. Note that the highest number of contributions relates to discussion or community activities, e.g. Reporting bugs and providing support. This is consistent with Barcellini’s (2014) conclusions about discussion vs. Implementation spaces. While the majority of contributors were involved in discussions about issues or functionality, fewer respondents were directly involved in coding issues.

Figure 1. Breakdown of Drupal contributions selected by survey respondents.

Also of interest is the overlap in what was chosen. Participants, on average, listed 7 activities that they participated in as contributors of the 18 possibilities. Breaking these activities into categories, we see a higher number of discussion and education-related activities than activities that directly involve writing code. Table 1 shows the breakdown.


Activities involved

# Respondents


  • Reporting bugs and feature requests
  • Providing code review or issue cleanup
  • Participating in discussions on groups.drupal or forums


Education and Support

  • Providing Support to new users
  • Writing Documentation
  • Writing books, podcasts or other educational materials
  • Writing and moderating content on Drupal.org



  • Writing and maintaining modules, themes or installation profiles
  • Writing patches
  • Core development
  • Providing Drupal translations
  • Creating or running automated tests



  • Helping organize Drupal events and user groups
  • Moderating comments in issue queues or forums
  • Removing spam on Drupal.org
  • Presenting at Drupal Camps and Drupalcons



  • UX/UI Design
  • User Research


Table 1. Breakdown of activities by category.

This finding suggests that metrics such as code commits, that are used to gauge community contribution by the majority of Open Source literature and by Drupal.org itself, paint an incomplete picture of the types of contributions that actually happen in the Drupal project.

When and Where

In addition to the type of contributions made, respondents were also asked to report when and where they performed activities related to contribution. While over half of the contributors (n = 78) reported that they contribute during sprints, a clear majority of respondents reported that they did contrib work at home or work, at various points during the day.

Figure 2. Breakdown of when and where contribution happens.

These data, along with some qualitative feedback from respondents, suggest that contributing to Drupal is not necessarily something one does during a set time of day. For some, it’s something they do when they are at a conference, and they want to help out during a sprint. For others, it’s something they do as part of their regular work, e.g. Maintaining a module. For still others, the boundary between work and home time is fluid, e.g. Freelancers. The following quote from P178 illustrates this tension:

Comment on the next question: There's no way of answering that as a freelancer, working at home, switching from paid to unpaid work (incl. contributing to Drupal) several times a day. (Survey, P178)

Contribution Tools

Finally, the survey wanted to uncover the different tools used by contributors during the course of their work. This was both in order to support the observations made during the ethnography process, and to help create a larger picture of Drupal contrib as a whole. Figure 3 shows these results.

Figure 3. A breakdown of tools used by contributors.

As expected, Code editors and the Drupal.org Issue Queue topped the list of tools, along with IRC (Internet Relay Chat), which was used by over half (n = 83) of contributors. Interestingly, however, Google Docs and Google Hangouts/Skype were also popular choices, used by just over a third (n = 52 and n = 54, respectively). This supports an offhand comment made to the researcher during NYCCamp, when discussing the researcher’s recent appointment to the Community Tools Team: “so, you’re still in the Google Docs phase? (personal communication, 4/22/14)”

Another interesting finding is the relatively low rate of contributors who report using groups.drupal.org. Only 45% of contributors (n = 68) report using this tool as a means to contribute. Of these, it appears that the Hybrid and Mostly Development roles most commonly use Groups for their work, while more design and project-management roles use it far less (see Figure 4). This supports feedback from interviews with UX contributors that, while Drupal Groups was previously used to have discussions among the UX team, “it all gets rehashed in the Issue Queue anyway” (Interviews, Designer), which has prompted them to start design discussions directly in the Issue Queue.

Figure 4. Breakdown of Groups.Drupal.org use by role category.

Next up

The next section of the survey focused on why people contribute, and the roadblocks faced by contributors. Those results will be coming in the next week or two.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <img> <h1> <h2> <h3> <h4>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.