August 2023

What brings you to open source?

How can projects encourage sustainable open source participation?
Author: Sophia Vargas, Researcher, Open Source Programs Office

Forward:

In 2022, the research team within Google’s Open Source Programs Office launched a study to
better understand open source developers, contributors, and maintainers. Since Alphabet is a large
consumer of and contributor to open source, our primary goals were to investigate the evolving
needs and motivations of open source contributors, and to learn how we can best support the
communities we depend on. We also wanted to share our findings with the community in order to
further research efforts and our collective understanding of open source work.

In Q2 2022, we partnered with ClearPath Strategies1 to develop and field our questionnaire to a
panel of developers. Our sample of 1,108 respondents was spread across seven countries and four
continents, with quotas set for open source contributors, maintainers, and students, including a
small sample of open source users for a baseline comparison. We also reviewed third party
publications and research articles conducted by other institutions, researchers and organizations
to compare, validate and provide additional context to our findings.

Overview of Sample Demographics

The following charts describe subdivisions and demographics
of our sample of 1,108 international developers:

Regions - quotas set for each region represented - Roles - respondents were screened for technical backgrounds
Alt text: This chart shows the regional breakdown of respondents: 18% US, 19% India, 18% Alt text: This chart shows the role and title breakdown of respondents: 47%
Brazil, 16% Japan, 11% Germany, 9% UK and 11% France identified as developers or software engineers, 38% as managers of technical
teams, 6% data scientists or data analysts, 4% data engineers, 4% DevOps or
SREs, and 2% architects

1 Clearpath-strategies.com

 Contribution status - quotas set for contributors and maintainers:

We asked respondents to self-identify as one of the following: open source users Employment status - quota set for Students: Respondents were identified by
(including donors), contributors, or maintainers. employment status

Alt text: We asked respondents to describe their current and highest level of involvement Alt text: We asked respondents to share their employment status: 76% were employed full
and/or contribution to open source projects: 22% identified as maintainers of open source time, 16% were students, 4% employed part time, 3% identified as independent
projects, 45% as contributors to open source projects, 29% as users of open source, and contractors, and 1% were not employed but looking for work.
5% had donated to open source projects.

Open source contribution tenure: Screened out individuals with less than a year of
development and coding experience.

Alt text: For the 739 respondents that contributed to open source, we asked how long they have
been contributing: 3% contributed less than 3 months, 17% 3-12 months, 39% 1-3 years, 26% 4-6
years, 10% 7-9 years, and 5% 9 or more years.

What is included in open source “work”?

In our study, we did not attempt to define ‘open source work’ but instead asked respondents to share details

on contribution tasks they took on in the community and whether or not they were completed in personal or

professional time. Within the total sample, 18% contributed to open source in their personal time only, 30% in

their professional time only, and 52% contributed in both personal and professional time. Noting that our

sample screened for developers (self-identified here as people who write code), within this study:
 Writing code, reviewing code, Q/A and testing were top contribution activities.

However, many respondents also performed non-code related tasks in support of the community (see figure 1). Recognizing that

not all contributors have a background in coding, we also asked this question in the attendee survey for Open Source Summit

North America (June 2022) to compare results with a different sample. For the 140 attendees that completed the survey, writing

code was still the top ranked task, followed by writing/reviewing documentation and then reviewing code.

Activities did not vary significantly between personal and professional time.

We asked our respondents to answer this question in two ways: tasks completed in your personal time or professional time. As

seen in figure 1, there was little variability between responses in aggregate. Reviewing demographic subgroups and tracking

individual responses between both questions suggested that individuals tend to take on the same tasks in both contexts.

Our study did not detect significant gender disparity in OSS tasks.

Note that this study did not attempt to estimate gender representation across open source communities.2 Instead we tested if we

could identify differences between tasks completed by self-identified genders3. Within this sample, women were slightly more

likely to take on community management and event organization tasks.

Figure 1

What open source work do we choose? 


What are we tasked with?

Alt text: We asked respondents to describe the nature of their open source contribution in personal and

professional time: The top responses for both personal and professional time were: writing code, reviewing code

and quality assurance and testing.

Figure 1: Base: International OSS developers, contributors, and maintainers

2
For research that focuses on gender disparity in OSS see: Women’s Participation in Open Source Software: A Survey of the Literature https://dl.acm.org/

doi/10.1145/3510460

3
Respondents self-identified as: Male, Female, Non-binary, Prefer to self describe as (other), or Prefer not to say

 It’s challenging to separate ‘paid’ and ‘volunteer’ open source work.

In other research and analytical contexts (such as reviewing GitHub logs), we’ve struggled to accurately and aggregately separate

‘paid’ and ‘volunteer’ work within open source communities. We designed elements of this study to see if we could identify

patterns that would inform this exercise. However, we discovered that our respondents did not express identifiable boundaries,

choosing to perform similar tasks in work and personal time.

Why is this a problem?

This is a continual challenge within the research community, where there have been many efforts investigating these spaces

separately—such as ‘volunteers’ and their propensity to stay engaged[1], or why and how companies participate in open source

[2] [3]. Without a clean separation, this blended reality will continue to challenge our ability to isolate trends and observations at

scale.

Why did respondents participate in open source?

Within our study, we wanted to understand the respondents’ motivations and incentives for open source

participation. Within this sample:

The primary motivation for open source contribution was skill development, learning and enjoyment.

This finding aligns with a separate article focused entirely on contributor motivation [4]: even though the methodologies listed

distinct response options, skill building was ranked first in both studies. Our survey also suggested that ‘the importance of the

project’ and ‘interest in the project’ were stronger motivators to participate than social aspects like ‘networking’ or ‘supporting

the community’. (See figure 2) Respondents also indicated that they would continue to contribute to projects ‘as long as they

were still having fun’.

Payment (or lack of) was not a motivating factor to contribute.

In our study, lack of payment was not a leading reason to not contribute (figure 3), and in the article referenced above [4], paid

contribution was ranked last in ‘motivation to contribute’. However, some respondent subsegments placed more weight on

payment—specifically maintainers who indicated they ‘could do more if paid’.

Contributors prefer projects that have welcoming communities, clear onboarding paths, and a code

of conduct.

We asked respondents what was most important to them when considering projects to contribute to in their free time, and on

behalf of their employer. For contribution in personal time, respondents prioritized community attributes: a welcoming

community, clear onboarding path and code of conduct. In professional time, license compatibility was ranked first, but then the

top considerations were the same as considerations in their personal time.

 Figure 2

Why did respondents contribute to open source projects?

Alt text: We asked respondents to pick the top two reasons why they contributed to an open source project: the top response for professionals
and students was "skill development", while the top response for contributors was "networking and meeting other contributors" and maintainers
claimed it was "the importance of the project".

Figure 3

How do contributors select projects?

Alt text: We asked respondents to share their most important criteria when selecting an open source project to contribute to in their personal
time. the top responses were: welcoming community, clear onboarding path, and code of conduct.

Figure 3: Base: 517 International OSS developers, contributors, maintainers and students who worked on open source in their personal time.
Why did respondents leave communities?

Over the last year or so, reports of burnout in relation to work4 and open source5 have only increased. We wanted to
investigate the level of burnout within our sample, as well as test if burnout was a significant factor in departure
from open source. First, we wanted to understand what discouraged developers from contributing, and what
caused them to cease contribution:

Contributors just don’t have enough time.

Lack of time was cited as the leading reason ‘not to contribute’ as well as motivation to ‘leave a community’ (see figure 4). Other
discouraging factors included community dynamics: too crowded, not inclusive, or conflict within the community. Maintainers
also indicated that they stopped contributing to projects with legal or licensing issues, or if they disagreed with the technical
direction of the project.

Burnout is also encroaching:

In this respondent group, burnout was more prevalent in work vs open source contexts (see figure 5). As such, most respondents
in this sample found open source work more restorative6 than draining. However, maintainers were more likely than contributors
to experience burnout in open source work.

Figure 4a
Why are developers not contributing to open source?

Alt text: When we asked respondents for their top reasons to not contribute to an open source project, all
respondent groups said “it requires too much time commitment”.

4
A study funded by Haystack analytics https://www.usehaystack.io/blog/83-of-developers-suffer-from-burnout-haystack-analytics-study-finds

5
https://betterprogramming.pub/why-open-source-developers-are-burning-out-1a860854884c

6
For details on this question see https://chaoss.community/kb/metric-project-burnout/

 Figure 4b
Why are developers leaving open source projects?

Alt text: When we asked respondents for their top reasons they stopped contributed to open source project, most respondent groups said
“lack of time” while maintainers shared that “there were licensing or legal problems”.

Figure 5
Have respondents experienced burnout in open source work?

Alt text: We asked respondents to share if they had experienced burnout at work or in open source: 43% of open source contributors had experienced
burnout in their work, while only 21% of open source contributors felt burnout while working on open source projects.

While maintainers were most likely to have experienced burnout in open source work, within our entire sample
burnout was not the leading cause of reduced participation in open source. However, given a concerning number of
anecdotal reports of burnout, we wanted to gather and validate ideas on proactive measures to reduce burnout in
open source work:

Figure 4b and 5: Base: International OSS developers, contributors, maintainers and students

 Task variety, delegation, and onboarding new maintainers may help to reduce burnout in open source:

Responses did not show a clear consensus for how best to address burnout (See figure 6). Contributors indicated that the nature

of the project contributed to this feeling, suggesting that ‘working on projects that have more impact’ would reduce burnout.

They also suggested the ‘ability to take on a variety of work’ and ‘delegate tasks as needed’. Maintainers didn’t want to be

perpetually accountable—suggesting ‘onramp more maintainers’, and ‘offer leadership rotations or terms’. We showed the same

question in a 2023 event survey and the top response was ‘increase recognition of contribution’. This variance suggests that while

systematic approaches can be taken to reduce burnout, there is no one-size-fits-all approach.

Figure 6

What tactics can help reduce burnout?

Alt text: We asked respondents to share what could be done to mitigate burnout. The top response for contributors were “increased

variety in project cases”, while maintainers said “leadership rotation for open source projects”

How can we apply these results to our communities?

People are the most valuable resource within open source projects and communities. With this effort and in future

research, we hope to continue to grow our collective knowledge of open source participants and how to promote

healthy and sustainable communities.

Value your time together and apart:

As lack of time is what drives people away from open source contribution, how can community leaders ensure that they are

making the most of the time they have together? What topics are better served in real time meetings, and what work can be

completed asynchronously? Some projects have planned breaks, no-meeting weeks, or official slowdowns during holidays or

popular conference weeks. Participants should also feel empowered to take breaks, vacations, and personal time away from open

source work

F
igure 6 : B :I
ase nternational O SS developers, contributors, maintainers and students.
 Invest in documentation:

This is one way to make individual knowledge accessible to the community. In addition to technical and procedural overviews,

documentation can also be used to clarify roles, tasks, expectations, and a path to leadership. If any contributor can review

documentation and learn how to complete a task, that should reduce the burden on any one individual who may currently own

that task. Providing milestones for maintainer and leadership roles can also help to encourage more participation from individuals

7
by providing concrete goals.

Communicate with care:

Communication is the primary way for community leaders to promote welcoming and inclusive communities and set norms

around language and behavior (as documented in a Code of Conduct). Communication is also how we build relationships, trust,

and respect for each other. Additionally, research efforts have shown that communication levels are “more determinant of

success and onboarding than coding activities” [5].

Create spaces for anonymous feedback:

Feedback is a valuable tool for any project to adjust to the evolving needs of the contributor and user communities. When

8
designed appropriately, surveys can serve as safe, anonymous, retaliation-free spaces for individuals to provide honest

feedback. For small samples, you may have to limit demographic questions that can inadvertently identify individuals and ALWAYS

9
include a ‘prefer not to answer’. This burnout metric designed by the CHAOSS community can be added to surveys to gauge how

your community is feeling about their open source work.

Questions sparked by this research

At the conclusion of this research effort, we were left with more questions that we hope to pursue within our team

as well as through partnerships with the broader research community:

Can we get more clarity on ‘open source work’?

With more granularity and nuance around roles and tasks, can we correlate speci fic activities to behavior, motivation, sentiments,

and burnout ? While our study focused on code-centric contributors and maintainers, there are many other roles and non-code

contribution types
10. In addition, our study did not venture into the context of any given task: for example, what kinds of code

work do contributors engage in ? Those working on novel features may have a different experience than those addressing bugs

and maintaining existing code.

H ow are emerging funding structures impacting pa rt

icipant behavior and motivation?

While this and other studies have indicated payment is not a motivating factor to contribute, recent work indicates that payment

can encourage maintainers to pick up more tasks and stick around longer [ 6 ]. With additional funding structures available, how will

this change open source work distribution, motivation, and durability ?

Can we get more clarity on who would bene fit from speci fi
c tactics to reduce burnout in open

source?

Our study focused on contributors and maintainers, but also indicated that the experience of burnout can be highly personal and

context-speci fi
c. Can we broaden and improve our methods of investigation to get more clarity on how best to support open

source participants in danger of burning out ?

7
For tips on how to grow your contributor base see h tt //
ps: /
www.youtube.com watch v?= rOs rf
xjhev 0

8
For tips on survey best practices see h tt //
ps: www.youtube.com watch v / ? =_ D Kz XBc

To c e

9
htt //
ps: / /
chaoss.community kb metric-project-burnout /

10
The ACR OSS project is working to A ttribute Contributor Roles in Open Source Software, see whodoesthe.de v

References:

[1] Brudney, J. L., & Meijs, L. C. (2013, May). Our common commons: Policies for sustaining volunteer energy. In
Nonprofit Policy Forum (Vol. 4, No. 1, pp. 29-45). De Gruyter. https://www.degruyter.com/document/doi/10.1515/
npf-2012-0004/html

[2] M. Guizani, A. A. Castro-Guzman, A. Sharma, I. Steimacher: Rules of Engagement: Why and How Companies
Participate in OSS, submitted to ICSE 2023 https://arxiv.org/pdf/2303.08266.pdf

[3] Why Do Enterprises Use and Contribute to Open Source Software, June 2022, Linux Foundation Research https://
www.linuxfoundation.org/blog/blog/why-do-enterprises-use-and-contribute-to-open-source-software

[4] M. Gerosa, I. Wiese, B. Trinkenreich, G. Link, G. Robles, C. Treude, I. Steinmacher, and A. Sarma, “The Shifting
Sands of Motivation: Revisiting What Drives Contributors in Open Source” in 43rd International Conference on
Software Engineering (ICSE), May 2021, pp. 1046–1058. https://arxiv.org/pdf/2101.10291.pdf

[5] L. Yin, Z. Chen, Q.i Xuan, V.r Filkov: Sustainability Forecasting for Apache Incubator Projects, ESEC/FSE 2021
arxiv.org/abs/2105.14252

[6] The 2023 Tidelift State of the Open Source Maintainer Report

https://explore.tidelift.com/050423?utm_medium=email&utm_content=256860118&utm_source=hs_email#page=1