Drupal Community Involvement Study, Part 3: Why People Contribute

Why People Contribute

There were two questions in the survey related to the reasons people contribute to Drupal. The first, shown on a separate screen before the second question, was an open ended question: “Please say, in your own words, why you chose to contribute to Drupal.” Qualitative responses to this question were coded using NVivo software for Mac ( and compared to responses from the second question, which asked participants to rate the importance of 11 separate factors in relation to their decision to contribute.

Key Motivations

Table 1 shows the breakdown of respondents’ key motivations for contributing. “Bottom 2” represents the percentage of respondents who chose “Not at all important” or “Very Unimportant;” “Top 2” represents the percentage of respondents who chose “Very Important” or “Extremely Important.” The Mean represents the average score for each statement, where 1 = “Not at all important” and 5 = “Extremely Important.”

Why do you contribute to Drupal?

Bottom 2

Top 2

# Responses

Mean (of 5)

I believe that Open Source is the best way to develop software





I needed to write or update a module for a particular project, and decided to contribute that code to the community





I wanted to give something back to the community





I thought it would help to attract employment opportunities





I have fun doing contrib work





I saw it as a way to increase my skills in a particular area of design/code, etc.





I wanted to learn more about how Drupal worked





My employer sponsors me to contribute to Drupal





A friend/colleague wanted me to contribute to Drupal





I wanted to interact with like-minded web developers and designers





I liked the challenge of contributing to a large software project





Table 1. Breakdown of answers to “Please Rate the Importance of the following factors in your decision to contribute to Drupal.”

As these data show, the two most common reasons respondents gave for their contribution was a desire to give back to the community (90%, n = 135), and a belief in Open Source (89%, n = 134). This was reinforced by the qualitative feedback; however, in the case of Open Source ideology, this motivation was rarely stated directly.

Desire to Reciprocate or "Give Back"

Another commonly cited factor was the ability to increase skills, learn more about Drupal, and generally have fun, all of which had over 70% of respondents in the Top 2. Interestingly, however, this motivation was not mentioned as often in qualitative feedback. When it was, it was often mentioned in terms of reciprocity and passing on knowledge that others helped them gain. The comments below are representative of this phenomenon:

“Give and take. Others help me, I help others. And contributing helps sharpening my skills by opening myself to constructive community criticism.” (Survey, P61)

“I have been working and learning with Drupal for some 4 years, I realise how hard it can be to learn how to use some techniques as the Drupal Learning curve can be quite steep. / So I decided to help newbies and my peers solve their own Drupal Problems using my own experience.” (Survey, P67)

“Originally I just wanted to give back what I had built because I thought others could make use of it but now it is mostly about learning Drupal 8 and making sure the project continues - it won't if people don't join in.” (Survey, P153)

From these comments, we see that, while learning Drupal and increasing one’s skills are certainly motivating, that motivation may actually stem from memories of others who helped them, and a desire to pay it forward.

This desire for reciprocity, and the idea of “giving back,” was a common theme among participants. In addition to being the most-cited reason for contributing in the quantitative feedback, it was also featured heavily in the qualitative comments. In many cases, it was mentioned in relation to others who had helped them, e.g. “The community was welcoming and Cathy did not give up on me (Survey, P54).” More commonly, respondents mentioned gratitude for Drupal itself as a product, and wanting to give back as a way of helping it continue improving, e.g.

“I love being part of an open-source community! I wanted to give back to a project that has done so much for me, and help make it even better.” (Survey, P75)

“If we all contribute when/how we can, it makes better software and a better community for everyone who's using Drupal.” (Survey, P18)

Overall, a love of Drupal, and the community that surrounds it, was pervasive in the comments.

Belief in Open Source Ideology

Belief in open source ideology was the second-highest theme participants; however, in comments, specific references to “open source” or “free software” were only made a total of 19 times. Rather, the belief in open source was most typically expressed in terms of a perceived obligation to give back to a community—and a product—that had given them so many personal and financial benefits. Some representative examples:

“Because it's the right thing to do. (Survey, P135; Survey, P121)”

“Come for the software, stay for the community. / Because Drupal is my working tool. / Because I profit from the work of others using free softwares, so I think it's natural to give back help. (Survey, P109)”

“Our company builds systems for customers with it. Of course I'm giving back to the OS community. (Survey, P128)”

“Because I felt it was important to give back since the community supplies us with so much. We are able to build solutions for our clients for reasonable amount of money due to everyone else's contribution.” (Survey, P101)

The fact that Drupal, as a framework, provides avenues for respondents to make their living, tackle interesting challenges, and do so with fewer resources than would be required for many bespoke software or website projects appears to be a more common motivator than direct belief in the Open Source development model. This finding could reflect a change in motivation over time; for example, Shah (Shah, 2006) found that own-use reasons (e.g. “I needed to fix something and contributed the fix back”) were often initial motivations for contribution, but the ability to have fun and increase skills became a primary motivator as a contributor continued working with the product. Fang and Neufeld (Fang & Neufeld, 2009) similarly found that, while use value is often a primary initial motivator for contribution, the learning and positive interactions with community members that contributors experience over time can give contributors a sense of identification with the community, spurring future participation.

Financial or Career Benefits

While the financial benefits of open source participation are often noted in the context of employer sponsorship, e.g. David, Waterman & Arora (2003), participants in this study generally listed that this factor was neutral or unimportant in terms of their motivation to contribute. This finding is supported by Shah (2006), who reported that financial benefits gained from open source were rarely mentioned as a primary motivation, but often mentioned in passing. Meanwhile, the concept of contributing as a result of fixing one’s own problem is a common motivator in several studies, e.g. (Fang & Neufeld, 2009; Krogh, Haefliger, Spaeth, & Wallin, 2012; Shah, 2006), and was reflected in the comments for this survey.

“I create, enhance and patch wherever I come across needs. / Mostly in the context of customer projects. / The philosophy behind this is to provide our customers and also ourselves sustainable solutions. / This is what makes open source great. /” (Survey, P66)

While employer sponsorship wasn’t mentioned often in the comments, for some respondents, it could make or break the person’s ability to contribute:

“Using Drupal at my job: so sometimes "contributing" bug reports is in my own best interest, but also contributing back patches to help the community. Also my employer has now sponsored some modules.” (Survey, P31)

“Most of the Drupal work I perform is on behalf of my employer, so I need their encouragement AND permission to release code to the public.” (Survey, P23)

Own-Use: Fixing a bug in the context of work

Participants’ financial ties to Drupal were also reflected in comments that discussed the own-use benefits of contributing, e.g. “add value to modules as a way of giving back, and to ensure I don't have to maintain separate sets of patches to modules to be managed when taking upgrades” (Survey, P71). 65% of respondents listed contributing fixes or patches they had to make to a particular module as an important motivator for contribution; qualitative comments from several contributors seemed to indicate that this was their primary means of contribution. For example:

“Had to fix things in contributed modules and it made sense to give the patches back to the maintainers.” (Survey, P14)

“I’ve recently started (only having worked with Drupal for just under 3 years) contributing on my own time, but that is still rather limited. I do very little core issue queue work, in stead, I choose to focus on issue queues for the modules which have benefitted me personally.” (Survey, P23)

Comments also seemed to indicate a shift in motivation, as participants began contributing:

“Eventually, I hit a roadblock in something I was doing for my day job (a bug or missing feature) and needed to modify the code for Drupal or one of its components. The feature I wanted (or bug I needed fixed) seemed generally useful, so I contributed the patch back up. / / Once you get the ball rolling, you can't really stop (you start to think, "Joe can I solve this problem in a way that benefits the most people?" Then build it and contribute it.” (Survey, P28)

Motivation is Multi-Faceted

While much of the findings in this survey seem to reinforce motivations that already exist in the open source literature, two interesting patterns were noticed in the comments:

  1. Motivation appears to change over time. While someone may start contributing because they need to fix a bug in a module or theme they use, their motivation can change over time, based on their experiences contributing, and with other community members.
  2. Motivation appears to be multifaceted. Most comments referenced more than one motivation for contributing. Most often, comments referenced a love of the Drupal community, as well as a perceived obligation to “give back” as a result of being able to use the Drupal software in their daily work for free.


Fang, Y., & Neufeld, D. (2009). Understanding sustained participation in open source software projects. Journal of Management Information Systems. doi:10.2753/MIS0742-1222250401

Krogh, von, G., Haefliger, S., Spaeth, S., & Wallin, M. W. (2012). Carrots and Rainbows: Motivation and Social Practice in Open Source Software Development. MIS Quarterly, 36(2), 649–676.

Shah, S. K. (2006). Motivation, governance, and the viability of hybrid forms in open source software development. Management Science. doi:10.1287/mnsc.1060.0553

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



  • 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
  • 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 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 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 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 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.

Drupal Community Involvement Survey, Part 1: Breakdown of Drupal Roles

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.


The overall survey received 178 complete responses. 2 responses were removed, as the respondents were not current users of Drupal, leaving a total of 176 responses that were chosen for analysis. Of these, the majority (58%, n = 102) of respondents were from the United States and Canada, with another 32% (n = 56) coming from countries around Europe. The remaining 23 respondents reporting their country of residence included individuals from Australia (n = 4), Brazil (n = 4), India (n = 3), New Zealand (n = 3), Japan (n = 1) and the Republic of Korea (n = 1). Of those who chose to list their gender, 60% (n = 106) identified as male, 28% (n = 50) identified as female. 3 participants listed another gender, e.g. “Genderawesome.” The majority of respondents were white.

Breakdown of Drupal "roles"

In the pilot survey, it was discovered that respondents could not easily fit themselves into a single Drupal “role.” As a typical Drupal project involves navigating between code and the Drupal GUI, performing database configurations, even a respondent who considers themselves a designer might spend time doing site building, front-end development, and layout sketches within the same day working on a Drupal project. Additionally, many Drupal users are also contract designers or developers, meaning that they might spend much of their time on activities such as project management, site building, and training documentation, among other things.

In an effort to gain a more accurate picture of how Drupal users split their time amongst various activities related to Drupal, the second version of the survey amended the question about Drupal roles to the following question:

“What percentage of your time would you estimate that you perform the following activities related to Drupal? Your total must add up to 100.”

With options including Site Building, Theming/Front-End Development, UX/Interaction/Visual Design, Project Management/Product Management, Training and Documentation, Development/Systems Architecture, User Research/Usability Testing, Coding/Module Development, and Other (please specify). Responses were coded by hand in Microsoft Excel and fell generally into the following categories, ordered by frequency (see Figure 1):

Figure 1. Breakdown of participants by Drupal Role Category.

Coding Strategy

Role categories were devised after looking at the data and seeing the patterns that emerged. As expected, the majority of respondents split their time among multiple activities, and most leaned towards development, design, or project management/training activities (see Table 1). Additionally, as expected, the respondents included significantly more developers (~53%) than designers or UX practitioners (~18%).

Role Category


Number of Respondents

Hybrid Development

Combined total for “Site Building,” “Coding/Module Development” and “Development/Systems Architecture” higher than 40; balance of activities leaned towards project management and training/documentation. Many of these participants also listed “Front-End Development/Theming” as a significant percentage of activities.


Mostly Development

Combined total for “Coding/Module Development” and “Development/Systems Architecture” 60 or higher; balance of activities leaned towards project management and training/documentation. Very little to no design or Front-end Development listed.


Mostly Site Building/Theming

Combined total for “Site Building” and “Front-End Development/Theming” 60 or higher; 1 response included because “other” was specified as “site admin/content”


Hybrid Design

Combined total for “Site Building,” “Front-End Development/Theming” and “UX/Interaction/Visual Design” higher than 40; balance of activities leaned towards project management and user research.


Mostly Project Management/Training


Combined total for “Project Management” and “Training/Documentation” 50 or higher; balance of activities tended towards either development or site building.


Mostly Site Building/Design

Combined total for “Site Building,” “UX/Interaction/Visual Design” and “User Research/Usability Testing” 50 or higher; balance of activities leaned towards project management or training/documentation. Very little to no development listed.


Mostly UX

Combined total for “UX/Interaction/Visual Design,” “User Research/Usability Testing” and “Project Management” higher than 80


Mostly Site Building

Total for “Site Building” = 75 or higher; no other activities listed higher than 10



Total for “Other” = 80, “Marketing Drupal Company” specified


Table 1. Breakdown of Drupal role categories along with coding rationale.

The most interesting finding, however, was the inclusion of “hybrid” roles, in which respondents listed that they do a little bit of all the activities. However, even these hybrid roles tended to lean towards being mostly design or mostly development oriented. For example, several respondents in the “Hybrid Development” category included both front-end and back-end development in their list of activities, while many in the “Hybrid Design” category also did theming and user research. Most respondents included some amount of project management in their total, with the exception of 3 respondents who chose Site Building as their sole activity.

Drupal Community Involvement Study: Your feedback needed!

Do you work with Drupal? Do you (or have you considered) doing Drupal contribution? I'm conducting a short survey to learn more about the experiences of Drupal contributors, and those who want to contribute, but haven't been able to figure out how or what they can contribute yet.

Please take a few minutes to fill out this brief survey. Your feedback will directly impact the work that we're doing on the Community Tools team to improve the user experience of and

A link can be found here: 


Drupal Community Pilot Survey

In fall 2013, me and Adi Meir, a colleague at the Bentley User Experience Center and classmate at Bentley, collaborated on a survey to study the motivations of Drupal contributors. Specifically, we were looking at a couple of fundamental research questions: 

  • What reasons do people have for contributing code to the Drupal project?
  • What other types of contributions do people make (e.g. design, documentation, running events, etc.) and why?
  • Are there people who want to contribute, but don’t? If so, what factors might be preventing them from making contributions?

To research these questions, we first looked at representative studies of open source contributors to find sample questions that could be adapted for our survey. After some deliberation on the nature of the data we wanted to collect, the FLOSS-US study (David, Waterman, & Arora, 2003), was chosen as a starting point. We also asked participants to report on their specific “role” within Drupal, e.g. developer, designer, themer, etc. 

Finally, additional questions were asked, in a separate part of the study shown only to those who indicated that they had not contributed, but would like to, to assess potential reasons for not contributing (e.g. “I don’t know how to write modules or code” or “It’s too difficult to collaborate on my type of work in Drupal). As a control, respondents in the non-contributor category were asked to explain, in their own words, what has prevented them from contributing. On a separate screen, they were asked to identify a list of factors related to their decision not to participate, and rate their importance. 

Overall distribution
The survey was distributed in fall of 2013 via my personal Twitter and Facebook accounts, and forwarded via social media by participants. In total, we received 100 valid responses within a period of approximately 1 week (proof of the awesome generosity that exists in the Drupal community, if you ask me).

As expected, the majority of respondents (68%) considered themselves developers or site builders, while themers, designers, usability professionals and “other” (documentation, community support/outreach, etc.) represented the other 32% (see Figure 1). 

Figure 1. Breakdown of survey participants by perceived Drupal role.

In terms of contributions, this sample represented 57 code contributors, and 21 non-code contributors, with most contributors providing both code and non-code contributions. Prior to analysis, contributions were coded into four categories. Code Creation refers to contributions that involve the actual writing of code, i.e. writing modules and patches, or contributing to core development. Code Health refers to providing support for increasing the quality of code, i.e. by writing documentation or reporting bugs. This represented the largest number of contributions (113 in total). Community Health refers to providing support, e.g. mentoring others, volunteering at events, or providing support in the forums and IRC. Lastly, UX/UI refers to design-related contributions, such as UX Design and usability testing.

While the number of contributions related to community and code were roughly similar in our study, the number of UX/UI contributions is relatively small. This result is interesting given the attention that UX and UI has received in the Drupal community. If the number of designers is expanding (as evidenced by the growing number of submissions in the design/UX tracks at Drupalcon, and the growth of attendance at Design 4 Drupal Camp last year), why are there comparatively few contributions of UX and usability work?

Figure 2. Breakdown of types of contributions provided by survey respondents.

Feedback from non-contributors
Aside from looking at the nature of contributions in the Drupal community, an additional goal of the pilot survey was to specifically look at Drupal users who wanted to contribute, but had either not been able to, or had chosen not to. To go a bit deeper into this population, we asked only those respondents who said that they had not "contributed code or other volunteer work” to the Drupal project, and that they had thought about contributing, the following question: 

Please say, in your own words, what has held you back from collaborating on Drupal.

The free text entry yielded a total of 19 responses, which varied in length from a single word to a full paragraph of commentary. Among these responses, 5 focused on not having time to contribute (e.g. “Don’t have a lot of free time”), and 8 centered on being put off by either the perceived complexity of the process (e.g. “Not sure how best to do so or where to get started”) or the perceived attitudes of Drupal developers (e.g. “my last impression was that it seems like everyone in the community speaks only in php”). Most importantly, however,  (12 of 19) respondents felt that they did not have the skills (i.e. coding skills) required to contribute to Drupal, and/or that skills unrelated to code were not valued by the community. Some examples: 

"Don't feel that my skill set is advanced enough yet to make a contribution.”

"I attend and financially support whatever I can, but have no interest in becoming a developer, so don't feel that my opinions are really considered particularly valuable.”

"Have no idea how I can contribute as not a developer"

As a secondary, quantitative check to balance the qualitative responses, we also asked respondents to rate the importance (on a scale of 1 to 100) of several factors that might relate to their decision not to contribute. These factors were chosen both from the literature on motivations of open source contributors, and from anecdotal reports from conversations I’ve had with others in the community. Figure 3 shows a breakdown of median ratings. 

Figure 3: median ratings per motivation answer

As shown in Figure 3, the lack of available time (i.e. “I am too busy with other commitments”) received the highest median rating (80/100) among respondents. However, the next highest median ratings were being unable to write code (72/100) and being unclear on how to contribute (60/100), reinforcing the insight from the qualitative findings that, at least to this sample, knowledge of code is seen as essential to Drupal contribution

Issues with survey design
As with most pilot surveys of this type, this survey is not without its challenges. First, the sample (as with all surveys) is largely self-selected from my social network, which makes it broad, but limited. Additionally, we found a couple of challenges for people who completed the survey: 

  • The rating system used for motivational factors (a slider from 0 to 100), while offering some precision, made analysis challenging.
  • Selection of a single Drupal “role” was difficult for many respondents, as they see themselves as having multiple roles within the community (e.g. a designer can also be a themer and a site builder). This may have contributed to the low number of “designers” in the survey.
  • Questions about respondents’ work life, taken directly from the FLOSS-US study, focused heavily on the assumption that Drupal contributors were full-time employees, which meant that independent consultants found it difficult to answer these questions. 

These issues will be addressed in the next version of the survey, which will be distributed again in summer. I’ll be promoting it both at Drupalcon and Design 4 Drupal, so please look out for it!


Subscribe to Blog