Open Source
Maintainers
Exploring the people, practices,and constraints facing theworld’s most critical open
source software projects
July 2023
Alex Salkever, Linux Foundation Research
Foreword by Shuah Khan, Fellow, The Linux Foundation

Open Source Maintainers
38%

Less than 1/3

75% of intervieweesof interviewees
say that they feel aof interviewees
say their project
has a formal
DEI program.

serve both as project

maintainers andcontributors of code.

34% ofinterviewees saytheir project has aformal mentorshipprogram.

Only 35% ofinterviewees say theirproject has a strong
new contributor
pipeline.

Interviewees recognizethat speciﬁc behaviors
discourage newcontributors, such as

not responding to pull
requests in a timely
manner.

Concerns about
code vulnerabilities
must be balanced
against critical operational
considerations, suchas recruiting newcontributors.

62% ofinterviewees are
employed to work
full-time on theirprojects.

Embrace
automation. While

it does not replace thehuman touch, it does
provide key beneﬁts suchas scale and instantresponse times.

high degree ofsupport from theiremployers for theiropen source work.

53% of interviewees

indicate their project has aformal new contributor
recruitment process.

39% of interviewees
feel that open source

software work ishighly valued at theirorganization.

A mention or
shout-out on social
media or a community

call can encourage newcontributors to tackle
hard problems.

Copyright © 2023 The Linux Foundation | July 2023. This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.

Contents
Foreword ........................................................................................................................4

Determine your project attributes............................................................................................ 28

Executive Summary.................................................................................................5

Create a strategy and road map based on your attributes.......................................... 28

Introduction.................................................................................................................. 7
Methodology.................................................................................................................8
Observations on the demographics ofmaintainers and contributors.............................................................................9
Career path of maintainers............................................................................................................... 9Contributor, maintainer, or both?................................................................................................. 9
Working full time or part time on OSS projects.................................................................10
Super contributor and maintainer project onboarding experience.....................11
Value maintainers receive from open source maintainership...............................13

Maintainer best practices....................................................................................14
Contributor experience..................................................................................................................... 14
Community governance and management......................................................................... 19
Documentation ...................................................................................................................................... 21
Funding and other forms of support........................................................................................ 23
Diversity......................................................................................................................................................25
Preventing maintainer burnout .................................................................................................26

Conclusion................................................................................................................... 28

Identify key metrics for your project, and track them regularly............................ 29
Identify best practices for your project.................................................................................. 29

Acknowledgments..................................................................................................30
About the Author ....................................................................................................30

Foreword
Open source software is the backbone of our world infrastructure.

A relatively small number of open source projects comprise an

From financial services and healthcare, to telecommunications

astonishingly high percentage of software in use today. It is imper-and the internet—it is no secret that open source runs the world..

ative that we understand more about these critical projects andIt powers smartphones and laptops, communications and data
infrastructure, our logistics systems, and our government. From
Linux and MySQL to thousands of viable projects in everythingfrom front-end frameworks to databases to container orchestration and telemetry, open source software is everywhere. We all

capture the lessons of those who run them. Their lessons caninform future founders and maintainers of critical projects. And,by making open source broadly more sustainable, we believe we
can increase the pool of successful open source projects and makemaintainership more fulfilling and less taxing.

know code doesn’t write itself. At the core of every successful open

Open source always has been and will be about the people

source project are the maintainers and primary contributors.

who take the risk and make the projects happen. As a founda-

From designing and writing the first lines of code to overseeing
and nurturing massive open source communities such as Linuxand Kubernetes, the maintainers and contributors drive innovation, progress, and healthy ecosystems. They set the rules and thetone—or set up the process that empowers healthy self-governance and continuity of their communities. Without maintainers

tion dedicated to the success of open source, we owe it to themaintainers to make their lives better and to illuminate a better
path forward. We hope this report can contribute to this effort
by recording the wisdom and learnings of some of the mostsuccessful maintainers from some of the most critical projects
and making them available to all.

and contributors, open source software would quickly become

Sincerely,

outdated and insecure. For critical software projects, the burden is

Shuah Khan

greater.

LF Fellow / Maintainer
The Linux Project

OPEN SOURCE MAINTAINERS

4

Executive Summary
From operating systems to databases toprogramming languages, the world increasingly
relies on open source software (OSS). It has become
the foundation of much of the global technology
infrastructure. Unlike proprietary software, which
engineers construct when working in a closed environment for a firm explicitly seeking profits fromcode, OSS relies on a web of maintainers who work,often without pay, in initial project stages to build
software. Research has found that our technology
infrastructure relies heavily on a few hundred
open source projects. These projects represent a
disproportionate percentage of software dependencies. The maintainers of these projects beara tremendous burden. Projects they oversee andsteward are responsible for much of the global
economy. Disruptions to these projects can cause
massive problems and outages.
In some cases, these maintainers work alone, withlittle or no organizational or financial support for
their projects. Even when maintainers enjoy significant organizational and financial support, including
explicit duties as part of their salaries, the job of maintaining the most important OSS—the job of supermaintainers—remains challenging to quantify andilluminate. This report seeks to document how maintainers become maintainers, their experiences andobservations for growing successful OSS projects,
and their tools and best practices for balancing
requirements to grow a software community and live
a fulfilling and sufficiently remunerative life.

Methodology
For this report, LF Research conducted detailed qualitative interviews with 32 super maintainers fromprojects our research identified as among the top
200 critical OSS projects. The maintainers camefrom a wide variety of employment histories but
shared many sentiments and common experiences.
As projects have grown in scale and complexity,
maintainers face increased demands on their time.
This led to less effort to welcome new contributors.

extrinsically in career trajectory, stature, andrespect in the community and career confidence
that another job would also be available. Many of themaintainers received their current employment due
to their community work. In some instances, companies hired maintainers specifically because of theirexpertise and ability to influence project dynamics.
However, most maintainers expressed concern that
their own organizations did not sufficiently recognize their efforts.

Early contributors benefited from less competi-

Growing contributions

tion and more opportunities to engage with project

Maintainers interviewed collectively supplied a widefounders. Despite concerted efforts to maintain apositive contributor experience, maintainers fear
it has deteriorated over time. They consistently
highlighted the imperative for continued focus on
fostering a supportive environment for new contributors. This is especially important for mature
projects where attracting new maintainers is morechallenging and for parts of projects that require
more technical acumen (memory management, toname one example).
As observed in multiple previous studies by LF
Research, maintainers enjoyed the intrinsic rewardsof working on open source, including a sense ofcommunity and camaraderie, work on cuttingedge technology, the ability to set their own courseand prioritize their activities, and the sense ofachievement in watching a community take shape.

range of best practices and wisdom for fosteringand growing communities, including prioritizing andmaking time for personal contributor engagement;using inclusive language; providing multiple
communication channels for engagement; andproviding clear onboarding resources. Successfulprojects further supported first-time contributors by suggesting suitable bugs or pull requests(PRs), either through flags in GitHub or in response
to questions floated in community channels.
Maintainers should always seek to identify thosewith higher capabilities or levels of persistence andnurture them to build the next generation of supermaintainers and project leads. Establishing triage
processes for new PRs and organizing team efforts
to handle commits and PRs in a timely fashion
further enhances the contributor experience.

Maintainers recognized that they benefitted
OPEN SOURCE MAINTAINERS

5

Executive Summary
Governance and control

FundingPreventing burnout

All interviewees felt that community governance andEarning enough money to live on was a concern

Maintainers discussed various strategies and prac-management are crucial for the long-term successfor only one of the interviewees (who also worked

tices that open source maintainers use to preventof a project but are often overlooked in the earlyon an unaffiliated smaller project in the JavaScript

burnout. These practices include recognizing thatstages. Best practices include establishing a code ofcommunity). That said, multiple maintainers expressed

open source work is never finished, designing a life-

conduct and promoting civility both explicitly andfrustration that critical open source projects they main-style that balances work and personal pursuits,

implicitly (through actions and the tone of projecttained or knew about languished or did not ship new

avoiding taking on unpaid projects that requireleadership). Distributing power can prevent deci-versions because of the lack of funding support. (Manyexcessive administrative work, automating work-

sion-making bottlenecks that frustrate contributors

maintainers interviewed maintain multiple projects,

flows to increase efficiency, setting boundaries

and slow down community innovation. Neutrality inincluding some that are not part of their employment

with regard to communication and work hours, andcommunity management ensures fair treatment ofresponsibilities.) Insufficient funding mechanisms fortaking breaks when feeling burnt out. Many of these

all contributors and encourages developer partici-

smaller and mid-sized critical projects were a key driver

strategies involve cultivating self-awareness andpation from multiple organizations.

in the decisions of maintainers to seek out full-time

being realistic about personal limitations to prevent

employment at an organization willing to underwrite

burnout while still contributing to open source

their work. Of the handful of independent maintainers

projects.

Documentation
Not surprisingly, maintainers expressed concernthat their project needed to improve documentation.
Best practices suggested by maintainers included
making sure that project leads demonstrate docu-

interviewed, all expressed concerns about how tosustain open source projects that do not have foundations or large corporate funders.

mentation is a first-class citizen in a project with

Diversity

comparable recognition to code contributions; hiring

Most maintainers struggled to generate a suffi-a documentation coordinator; requiring documen-

ciently diverse set of contributors and project leads.

tation to be submitted with each code contribution;

Roughly half of the maintainers had no explicit

and creating formal events or processes arounddiversity efforts or goals. Only a handful partic-

documentation to make it easier to contribute.

ipated in diversity programs such as Outreachy.
Maintainers that successfully fostered diversity
made DEI goals top-level project goals with associated governance efforts and participated indiversity programs. Despite best intentions, open
source has a long way to go regarding diversity.

OPEN SOURCE MAINTAINERS

6

Introduction
The health of the OSS ecosystem depends on the quality andto constantly recruit new contributors, set up proper systems

success of a core group of the most active and responsible main-of governance and adjudication for inter-project disputes, andtainers and contributors. The open source ecosystem and, byachieve greater levels of diversity, all the while ensuring that theirextension, the technology infrastructure of the world is heavily

project continues to innovate and iterate with new technology

dependent on a relatively small number of projects numbering

cycles.

in the hundreds. LF Research has studied and attempted to categorize the most critical projects in terms of dependencies inongoing work with Harvard University in our Census II program(most recently with “’Vulnerabilities in the Core,’ a Preliminary
Report and Census II of Open Source Software” and “Census II ofFree and Open Source Software—Application Libraries.”) Amidst
the millions of open source projects, a critical group of projects
and their maintainers and contributors occupy an outsized role.
LF Research calls these leaders of the open source realm “supermaintainers” and “super contributors,” who collectively form agroup of "super coders."
The burdens on them are heavy. Millions of users and systems
around the world download the projects they oversee. Security

This research is the result of interviews with more than 30 maintainers of, and core contributors to, the world's most critical
OSS projects, many of which were among the most widely usedapplication libraries identified in the Census II report publishedby the Linux Foundation in collaboration with the Laboratory ofInnovation Science at Harvard University.
Together, the interviews capture the insight and wisdom of thepeople at the helm of some of the most critical open source
projects. Interviewees describe how to effectively start, scale,manage, and innovate within open source projects and identify
opportunities for open source communities and enterprises aliketo better support them in their important work.

vulnerabilities in their projects may cause massive global disruption. Vulnerabilities in their code can “break the Internet.” They
also must balance these concerns against more mundane but
equally critical operational considerations, such as the need

OPEN SOURCE MAINTAINERS

7

Methodology
LF Research conducted 32 interviews of roughly one hour with

LF Research intentionally included projects at various stages ofsuper coders from critical projects. Interviewees for this study

maturity and age, from a few years to multiple decades, and in size

were contributors to, or maintainers of, a diverse array of softwarefrom a single maintainer to projects with thousands of contrib-that occupies different roles and niches in the vast open source

utors and dozens of maintainers. Lastly, LF Research included

ecosystem. This includes front-end libraries (Babel, Webpack,projects using multiple languages, including C/C++, Go, Rust,

React, Storybook); operating systems (Linux); infrastructure

JavaScript, Java, Node.js, Python, Ruby, Julia, and more. In doing(containerd, Kubernetes); package repositories and managers

so, LF Research identified common patterns, challenges, and best

(Rust Cargo, npm, RubyGems, Gradle, Apache Maven / Maven

practices based on these three core parameters.

Central); databases and storage (PostgreSQL, Ceph); developer
tooling (LLVM, Git, cURL); DevOps (Salt); lower level languages(Julia); and data analysis and machine learning frameworks andapplications (PyTorch, NumPy, Jupyter).

There are millions of OSS programs available for free download,
hosted in multiple locations, including on the leading version
control and programming collaboration tools (GitHub, GitLab,
Bitbucket) as well as on web servers and in other locations. The
data in the Census report provides a limited but important view
into the most widely used OSS. The software projects assessed

FIGURE 1

by Census II had various organizational structures. Some wereLANGUAGES OF PROJECTS SURVEYED
3.6% Rust
3.6% Ruby
3.6% Julia
3.6% Go
10.7% Java
14.3%
Pythonsingle maintainers with no foundation or funding support. Some
projects were larger and more complex software projects, withmultiple committees and bodies as part of project governance.
A single company wholly controlled some projects, while a large

25%Ccommunity of contributors wrote others. The aggregated datameasured the dependency graph and assessed which software
packages the largest group of end users used and was dependent upon. The data was anonymized and modified to prevent

21.4%
JavaScript
14.3%
C++

any linkage to the organizations running the applications themselves. In some instances, usage data (primarily downloads permonth) was also studied and available through other data sourcesthat collect and analyze data on OSS usage, such as Libraries.io.
Libraries.io collects usage data from package repositories andmanagers, a key nexus of open source dependency data andapplication usage.

OPEN SOURCE MAINTAINERS

8

Observations on the demographics ofmaintainers and contributors
The 32 interviews included maintainers of various ages andfrom a wide variety of locations. Maintainers hailed from a half
dozen countries. Six of the interviewees were female, and theremainder were male. All were developers and engineers withconsiderable experience. They worked for companies ranging
from large multinationals to small consultancies. One worked
solely on their open source project. Most were working either
at very large or small companies. Large companies represented

Career path of maintainers
Maintainers of and contributors to these critical projects camefrom a variety of academic backgrounds. A significant percentage
studied computer science or software engineering in university
as a major or a minor; several worked on the software they would
later become a maintainer of while in school as an undergraduate
or graduate student.

included Red Hat, Amazon, Microsoft, IBM, Meta, and VMware.

This was particularly true for maintainers and contributors working

Few were working at “mid-sized companies.” Two of the inter-on lower-level and more complex projects such as the Linux kernel

viewees worked at the Linux Foundation. Three of the interviews

and distributions, Git, and databases. Those maintainers also werefocused on previous project work; those interviewees had moved

more likely to take jobs out of school at large established softwareon from maintainer and contributor roles, but their experience

companies, where they took part in open source work as part of aremains useful and valuable.

lab or part of a growing open source practice.
Many of these maintainers initially started in open source throughexposure to and work with the Linux operating system. There wasalso a correlation between the language of the project and the

FIGURE 2

percentage of contributors who studied computer science; projects

PRIOR CAREER ROLES OF MAINTAINERS

written in C-type languages tended to attract university-trained

3.1% UX

computer scientists more than projects written in other languages.

3.1% IT
6.3% DevOps

began to work on open source to better solve their own computing

9.4%
Eng—Solo
14.3% Acad
NUMBER OF INTERVIEWS = 32

Another significant group of maintainers was academics who
problems. Only one of the maintainers LF Research interviewed

53.1%
Eng

with an academic background remains primarily employed as an
academic; most migrate to a role at a technology company or foundation once their project gathers sufficient critical mass.

Contributor, maintainer, or both?
LF Research defines a contributor as someone who writes andsubmits code to a project and a maintainer as someone who works
in the management of a project, including code review, triage,
OPEN SOURCE MAINTAINERS

9

test, security, build and infrastructure, and release management.
A total of 75% of interviewees served both as project maintainers
and contributors of code, with 25% serving only as maintainers.

37.5%
No

FIGURE 3

MAINTAINERS WORKINGFTE ON OSS PROJECTS

None were only contributing code, as one would expect when

62.5%
Yes

interviewing maintainers. The percentage of their time spentworking on open source projects varied widely, averaging 70% of
their time. Our interviews covered only one project operating withjust one maintainer; every other project examined had more than
one maintainer helping with the workload.
Over the course of their time working on their project, most of theinterviewees followed a progression path from contributor to core
contributor to maintainer. Inside the larger organizations, maintainers tended to juggle multiple roles and tasks. For example,
Brian Granger, a Project Jupyter maintainer, initially wrote much of

FIGURE 4

the project code. Today he focuses on fundraising, management,

MAINTAINER ARCHETYPE GRID

technical architecture design, reviewing code, and improving
the UX practice for Jupyter. Granger, who works at Amazon Web
Services, also continues to be involved in the community gover-

Fully Employed on Projectnance of Jupyter as a member of its Executive Council. Shuah Khanat the Linux Foundation oversees test and QA processes for theLinux kernel. She also works to improve project documentationand is actively mentoring 13 contributors as part of her efforts
to increase project diversity. Khan initially started out primarily
contributing expertise and architectural design to the test and QA
infrastructure of the Linux kernel but then progressed to roles that

No Project
Experience

Part Time /Some Experience

Project
Maintainer

included more managerial activities.

Working full time or parttime on OSS projects
All but two of the interviewees had full-time employment witha company that supported investing their time in the project.
Another significant percentage worked at venture-backed

Not Paid to Work on Projectcompanies of significant scale, including Vercel, Chromatic, andOxide Computer. Only one maintainer received support solely
from sponsorships, donors, and other forms of ad hoc project

OPEN SOURCE MAINTAINERS

10

funding. Another was in between jobs but had been employedsteadily working in open source for the past decade, primarily as
an open source evangelist.

FIGURE 5

PERCEIVED DEGREE
OF ORGANIZATIONALSUPPORT

24.5%
Low

The relationship between the interviewee, their employer, andtheir project was varied and often fluid. In some instances,

38.8%
High

the employee was hired full time to come work on a project
without having worked on the project specifically before. In
some instances, an employee was hired specifically because

36.7%
Mediumof their position in the community and their ability to help thecompany understand the project road map and support upstream
contributions.
In some instances, an employee was hired with the understandingthat they would spend part of their time working on a project thatis strategic to their employer. In a handful of the cases covered
here, interviewees worked for a company that employed all the
primary maintainers of a project. In a rare set of instances, theinterviewee was fully employed, but the employer was indifferent
to their work on the project. In two instances, an interviewee
worked for a company that specialized in helping customers bycrafting features for a specific project.

Super contributor and maintainer
project onboarding experience
With few exceptions, interviewees enjoyed a welcoming
onboarding experience when they first became involved in the“If I step back from the job I have and fromproject. This is not to say in every instance that it was necessarily

everything else and just ask, ‘Okay, whateasy or obvious to find a set of first issues to work on. However,

could I do that would have the greatest impact
on society, technology, humankind?’ as awhole, I’d be hard-pressed to find something

universally, interviewees who were not original founders reported
a positive first experience entering the community.
Nevertheless, multiple interviewees who had been contributors
or maintainers since or near the inception of their projects said

better than working on open source.”that they doubted their community today would be as welcoming—BRIAN GRANGER, CO-CREATOR AND LEAD MAINTAINER, JUPYTER

on maintainers, and the increased complexity of the project codedue to the scale of the mature community, the present demands

OPEN SOURCE MAINTAINERS

11

and architecture. When he first contributed code to PostgreSQL,
Andres Freund said, “... because the responses were so quick
and in-depth, it was like, ‘Cool! That's way more than review or

FIGURE 6

whatever I've ever gotten in my work life.’ I don't think that's the

34.4%
Yes

case anymore these days because just the volume has increased

PROJECT HAS FORMALMENTORSHIP PROGRAM

65.6%
No

so much that that kind of quick response and in-depth response is
not the norm anymore.”
Several interviewees remarked that their initial contributions,
often error-riddled, would have less likely received a warm
response in the project today. Their same contributions, if
submitted today, would require considerable effort to push theirPRs over the line and get them merged. In addition, early contributors felt they were able to tackle more substantive problems since
they were so early in a project. Competition for maintainers’ time
was less stiff, so rich engagements with project founders (via email
or in GitHub) were more likely and sustainable. Also, there were

FIGURE 7

PROJECT HAS FORMAL NEW
CONTRIBUTOR RECRUITMENTPROCESS / PLAN

53.3%
Yes

46.76%
No

many more areas where contributions were welcomed because
the project community was less mature, and expertise in key
areas of project development remained lightly covered. In at least
one instance, a maintainer had carefully observed community
behavior and picked an area of contribution that was extremelycomplex and had few participants precisely to stand out andimprove their chances of acceptance into the community.
The maintainers interviewed recognize specific behaviors that
discourage new contributors:

9.4%
NA
FIGURE 8PERCEIVED STRENGTH
OF NEW CONTRIBUTORPIPELINE• Maintainers have been unable to respond to PRs in a timely
manner.

34.4%
Strong21.9%
No• Maintainers stopped spending extended time helping newcontributors debug PRs.
• Maintainers stopped actively triaging new contributors to

34.4%
Kinda

identify potentially valuable talent.
• Contributors struggled to find an entry point for
conversations and input.

OPEN SOURCE MAINTAINERS

12

“Because just the volume (of work and PRs) has increased somuch that that kind of quick response and in-depth response(which I received) is not the norm anymore, at least in the
PostgreSQL community, I don't even know whether I could
succeed today or whether I would be hooked again like I waswhen I started out,” explains Freund, a member of the corecommitter team of the project. In other words, contributor expe-“Open source, it is a life-changing experience
for me. Coming from a closed-source world,
I feel like I am in the driver’s seat, I would
say, as opposed to riding as a passenger

rience tended to degrade, in their opinion, over time. This wasin the backseat. I feel like I can control myoften despite concerted efforts to address and maintain contrib-

career; I have direct control over what I

utor experience.

Value maintainers receive fromopen source maintainership

do and what my contributions are.”—SHUAH KHAN, MAINTAINER, LINUX KERNEL

Maintainers universally expressed gratitude for open source
and their ability to work in a system with open source values.
Specific benefits derived by maintainers for their activities
include both intrinsic and extrinsic values. The intrinsic values
LF Research has commonly seen expressed in previous surveys
of open source maintainers and contributors, such as the FOSS
Contributor Survey Report, include:• A sense of community and camaraderie• The ability to work on cutting-edge technology• The ability to set their own course and prioritize theiractivities, the ability to work with a global community ofpeers, and the joy of creating something from scratch• A sense of achievement in watching a community take shapeand flight• The chance to work with really smart people

Extrinsic values included access to better employment; theability to work for a variety of employers and choose their mode,
location, and style of work; and external status signals such as
association with a noted or trending project. In addition, several
maintainers mentioned that their open source work, while notdirectly contributing to their day-to-day work, did contribute totheir attractiveness to employers. Only one of the interviewees
expressed financial concerns over working in open source as acareer choice. Not coincidentally, that maintainer was heading a
project with no clear commercial entity or monetary engine, one
entirely dependent on donations and sponsorships. The majority“When I first met some of the people in person in the commu-

of the maintainers expressing funding concerns for their projects

nity, I was giving everybody hugs. It was a very emotional moment

were working on JavaScript projects, an area that has traditionallyactually because we had sort of been so invested and committed

struggled to obtain sufficient funding due to the dynamics of thefor so many years working on things together,” says one of the lead

JavaScript ecosystem and low levels of corporate funding for inde-

maintainers of Julia.

pendently maintained JavaScript projects.

OPEN SOURCE MAINTAINERS

13

Maintainer best practices
As part of each interview, LF Research asked maintainers and

How each project’s best practices came about varied widely. Most

contributors what were the best practices that contributed to themaintainers created some best practices from personal hands-on

success of their project. While community health is an inexact

experience and through trial and error. Others were codified inscience, most of the communities covered in this research effort

the community as specific parts of governance and rules. Many

were healthy by the most basic metric—they were shipping new

projects had gone through periods of change where a new set ofcode and versions.

best practices was adopted to enable smoother community inter-

Several maintainers voiced concerns that their community was
struggling to find fresh contributors and that this challenge could
negatively impact the project down the road. Maintainers all

action, execution, and growth. In hindsight, the projects treatedtheir own practices as they did code, subjecting them to constantscrutiny and review for potential ways to improve.

expressed strong views on how to maintain community health.

There is no one set of comprehensive best practices that will work in

The size, language, and life cycle stage of the project impacted

all cases. However, maintainers and core contributors demonstrated

these views.

great creativity in building out personalized and organizational bestpractices that met their needs. Here is a breakdown of the bestpractices identified as useful and helpful by interviewees. This list
is grouped into specific areas of practice, although in many cases, abest practice affects multiple areas, including contributor experience;
community governance; documentation; fundraising and in-kind
contribution generation; diversity; and burnout prevention. In thesections below, LF Research expands on each of them.

Contributor experience
Contributors are the lifeblood of neutral open source projects.
Many of the successful maintainers prioritized contributor experience very early in the project, working to encourage contributors tocomment, file bugs, and, ultimately, submit suggestions for improvements to code (in the form of PRs). Some maintainers undertook
heroic measures to encourage contributors. For example, Norbert deLangen, the lead maintainer of the Storybook project, sent a meetingscheduling link with a request to speak in person to anyone who sent
him an email with a suggestion or question about the project code.
De Langen met with over 200 people using this method during thefirst year of the project. He estimates that nearly 20% of those he met
with later became repeat contributors to Storybook.
OPEN SOURCE MAINTAINERS

14

Maintainers that build successful projects often go to extensive

organizations use bots in GitHub to greet new contributors.

lengths to help first-time contributors improve their contribution“Jupyter Lab (part of the Project Jupyter) uses a GitHub bot toand learn how to prepare a code submission, such as checking

welcome new contributors. If we detect you opening an issue

the format and syntax of code using automated check systems.

or pull request, we respond, ‘Hey, this is your first time contrib-

Gareth Greenway, currently a maintainer of the Salt project,uting. Welcome to the project. Here's how you can participate in

had submitted an error-riddled PR that the lead project creator,

the community,’" explains Granger.

Thomas Hatch, read. The original creator gave Greenway positive
feedback and worked with him to fix the code. Greenaway went on
to submit numerous other PRs and later became a Salt maintainer.
Here is a list of some other common ways that successful maintainers build a strong contributor experience.
Respond personally to first-time contributors.

Use inclusive language.
This can meaningfully improve participation for diverse groups of current
and prospective contributors.
Inclusive language is neutral withrespect to race or gender but

Personally respond to first-time contributors when they start toalso considers regional language

engage with the community. This is more viable in early-stage

differences and the ability of

projects with smaller communities, but many maintainers still

non-English speakers to easily

attempt to respond personally consistently. For smaller, more

understand project commu-

contained projects, personal response time is less of a challenge.

nications. Inclusive language

For example, in Linux toolchains or in projects such as containerd,

can be welcoming, engaging,which do not require large numbers of contributors and are written

and energetic. This is not to say ain more challenging software languages such as C++, maintainers

project must communicate solely in

do not see a high volume of inbound messages from potential

an anodyne style but that project leaders

contributors or maintainers. (Note: This also indicates challenges inshould be cognizant of the communications

recruiting new community members and contributors, particularly

requirements for contributors and other project participants. For

for older projects at the later stages of their life cycle).

example, a project should seek to minimize regional expressions,such as sports references and local jokes, to simplify commu-

Set up automated greeting bots and an onboarding guide.

nications. There are a variety of automated analysis tools thatcan provide inclusive language suggestions for emails, Slack,

Automation does not replace the human touch, but it does

and online documents and pages. Grammarly, the most popular

provide key benefits such as easy scale and instant response

online grammar-checking tool, now offers suggestions for inclu-

times. Particularly for mid-sized and larger communities, maintainers generally set up an automated greeting bot to greet

sive and gender-neutral language. Textio is a popular online toolthat screens job listing language for both explicit and implicit bias

new community members in Slack or Discord and guide themand suggests language that is both explicitly and implicitly more

toward onboarding resources. Linkerd, Kubernetes, Ansible,

inclusive. Common sense also can go a long way toward making

GitHub, and many other organizations use this capability. Somelanguage more inclusive.

OPEN SOURCE MAINTAINERS

15

Create a simple page that aggregates all thedifferent entry points and communications
channels for a project.
Many projects have multiple means of communication, including
email lists, chat (Slack, Discord, IRC), GitHub repos, projectchannels on YouTube, Wikis, and more. A simple way to help newcontributors connect with the community is to make it easy to find
all these channels, as Ceph does with their “get involved” page.
Create an onboarding or “how to contribute”“A maintainer’s job is being responsive to thecommunity and contributors, trying to understandwhere they’re coming from and giving them
feedback. A lot of times, some of our major
bugs have been caught or addressedin time because we’ve been
responsive.”—NEHA OJHA, Ceph

section in the project documentation or amarkdown file on the project’s GitHub page.
This includes an explanation of how the community works,
links to tutorials and key documentation, and ideally identifies
ways to contribute and participate along with ways to connect
with key community leaders and members. Almost every project
does have an onboarding page somewhere in its documentation and GitHub. The best practice is to link to them from multiple
locations to ensure new contributors can easily find them. The
more information on this page, the better. For example, Jupyter’s
CONTRIBUTING.MD page on GitHub contains granular detail
down to links to how to do regression tests for any contributions.
Suggest bugs or PRs for first-time contributors(often called “good first issue” bugs or PRs), or
identify bugs that could use help.

wanted” label to identify bugs that are unclaimed. Storybook.js has
a “good first issue” label that steers contributors to issues that may
be less complex. A key part of using these labels is ensuring that they
always have a backlog. Storybook, for example, at the time of thiswriting, has 26 issues under the label. For contributors that do notknow where to start, this is an ideal method to steer them.
Establish criteria or a mechanism to identify
contributors with higher-than-average capabilities.
While all contributors may be valuable, those with suitable skills may
be more valuable because of their comparatively shorter learning
curves. For example, in projects written in C-type languages,
fluency in one C language is a huge benefit. Contributors that

In many projects, contributors are hesitant to dive in and submit ademonstrate technical acumen through a high-quality PR or even

PR because they do not know whether a bug is “owned” by anyone insheer persistence in tackling harder problems can be encour-the project. (For example, someone who controls a module may haveaged to take on more complex initial projects or connected witha trusted cadre of bug fixers.) This is where labels on bugs for new

mentors working on more challenging aspects of a project code

contributors come in handy. These first-time bugs can be a creationbase or sub-systems, such as memory management, compilers, orof docs or more basic code fixes, but it really depends on the pref-

networking. Maintainers identified technical acumen primarily by

erences of project leadership. Many projects now have a label fornoting code quality or thinking of an initial PR or in the content ofthese items in their GitHub repos. For example, VSCode has a “helpemail conversations with a potential contributor about the project.
OPEN SOURCE MAINTAINERS

16

Both underscore the importance of outreach and direct commu-

public settings and on the project site, and assisting them in lining

nication with new contributors, particularly in projects where it isup conference presentations about their work, to name a few

hard to find contributors to tackle hard problems and project tasks

examples. Above all, maintainers should work especially hard to(memory management, compilers, and security, to name a few

nurture these contributors by ensuring timely responses to ques-

examples). Some projects require knowledge overlaps that can act

tions, comments, emails, or code submissions. This demonstrates

as a filter for contributors with potential. For example, NumPy isinterest in the scarcest of maintainer commodities—their time.

primarily written by and for scientists, engineers, and people using
Python for data analysis, but the code for the project is in C. The
NumPy maintainers know that if any scientists who have C coding
skills ask to contribute, they are likely to be strong contributors.
Rather than reject flawed contributions, offer
suggestions on how to improve and start a dialogue.
For some maintainers, a potential contributor who communicates

Strive to lower the bar for contributions.
Some contributors may wish to participate but get frustrated due toa steep learning curve, lack of documentation, or challenges in using
the technology. This can scare off contributors who may ultimately
become quite valuable and productive. Smart maintainers recognize this problem and set out to address it as part of their core work.

clearly and logically in their PR or via email passes the sniff test.

At Ceph, Neha Ojha has long struggled against the perception that

"Better than the patch quality was people who submitted some-the project is hard to use and get started on. To combat this, one

thing and explained what they were trying to do. I came back toof her top priorities is “... lowering the bar. We can always lower

them and said, ‘I see what you're trying to do, but X, Y, Z,’ and you

the bar for new contributors and new users,” says Ojha. For her,

had a good conversation with them,” explains Jeff King, a former

some of that emphasis has come on documentation. “I emphasize

lead maintainer of Git.

improving the Ceph documentation because I felt like, if we havethe right documentation in place, the first battle is already won.

Reward efforts to tackle the hardest problems.
Hard problems can become “showstopper” risks and major bottlenecks for projects. More challenging engineering tasks generally
attract fewer aspirants. This problem tends to grow as projects
mature and institutional knowledge accumulates in a small cadre

Then users can at least get Ceph up and running, and we havethose small wins to keep them engaged.”
Create happy milestones to encourage new contributors
who are showing promise and dedication.

of experts. For this reason, project maintainers indicated theyFor example, Storybook quietly adds a contributor to the projectmade extraordinary efforts to nurture contributors who showteam in GitHub after their second PR is merged. The contributor

interest in solving or working on harder problems, even if they

is notified and is generally delighted. (This also unlocks otherare project newcomers. There are several simple yet meaningful

GitHub benefits for them, such as a free Copilot account.) ”People

ways to acknowledge and reward these efforts. A mention inare surprised, and it makes them really happy,” says de Langen of

release notes, a shout-out in social media, and a mention on a

Storybook. Other maintainers suggest a simple means of recogni-

community call are just a few of the zero-cost, low-effort ways totion, such as sending out a special limited-edition release sticker

encourage efforts to tackle hard problems. Maintainers may want

to all contributors cited on each project release. NumPy adds a “+”to go further. This could mean sending contributors working on

sign next to first-time contributors' names to show special grati-

hard problems special swag, helping them to author blog posts intude in release notes emails.
OPEN SOURCE MAINTAINERS

17

Set up office hours specifically for new contributors.

Don’t be afraid to say no.

This time can be used to help guide them through the contribution

New contributors may propose ideas and submit patches thatprocess and raise the probability their contribution will be quickly

could have significant impacts on the workings of project code

merged. New contributors also often enjoy mentorship from andand subsystems with cascading and unintended consequences.

contact with maintainers. Shuah Khan of the Linux kernel mentors

Strong maintainers strive to respond quickly and explain politely

multiple contributors of diverse backgrounds by meeting with

but firmly why their idea or patch may be problematic and that itthem periodically, answering their questions via email, andis unlikely to be accepted. In addition, the response (which should“The very firstpull request I submitted
had close to 500 lint errors.
I think I still hold the record
for the most lint errors of any
contribution to Salt. A lot of open

helping them prepare contributions. This is part of her job

remain public) can help guide later contributors or serve as anin the project. “They will be submitting patches that weeasy way to explain the point to other new contributors in theneed to consider upstream, so it is better if their work

future. “No is temporary, but yes is permanent. Be very carefulis mentored to give them a better understanding ofabout what code you agree to add because it has long-term

how to land a patch,” explains Khan. “It benefits theconsequences,” says Laura Abbott, who was one of three prin-project overall by improving patch quality from new

cipal kernel engineers of the Fedora Project (a downstream Linux

contributors.”

distribution) at Red Hat and was a Linux maintainer. Beyond kernel
engineering, Abbott was highly active in the Fedora and broader
Linux community, both as a maintainer and as a mentor of contrib-

source projects would just have

Establish and follow triage

told me, ‘This is garbage. Take

processes for new PRs.

utors and wrangler of community concerns. Explains Abbotta hike.’ Instead, Tom Hatch (theThis may seem obvious. Still, the key is to gothat it can be a lot harder to remove code than add code, so makecreator of the Salt project) said,

beyond setting up the process and to give owner-

sure that it's added with this in mind.”ship of triage to a key project member or group‘This is great! We have neededof members (this can mean rotating members

this for a long time. It looks

through stints as the triage master). Most projects

like you’ve got some lint
errors. Let’s get those fixedand get this merged.’”—GARETH GREENAWAY, SALT

further, “Listen to what people are asking, but also just be aware

Create team efforts to “burst” handle commits and PRs.

already aspire to responsible triage of new patches

The PostgreSQL team regularly organizes “committfests,” where

and requests, but often work and life can get in theevery meaningful pending code submission and patch receives away. Without a system to handle triage and support

response from the project team. This system works best if there isfrom project leadership to prioritize it, triage tends to falla cadence and the activities are repeated several times a year.

to the bottom of priority lists. Unless triage and first-time
response is aggressively prioritized, it can become an ad hoc/ best efforts approach. This may turn off contributors because
it does not manage expectations and may result in lengthy delays.
For example, the Salt maintainers overhauled their triage process
and created specific roles and coverage to ensure triage moved
along and followed the same process. “Every new issue that comesin goes through proper triage these days,” says Pedro Algarvio, aSalt maintainer, noting this was not always the case.

Ensure that the right tone is set at the top.
The founding and leadership DNA of open source projects is
critical to further success and community growth. The best project
founders and leaders facilitate and support processes and efforts
to improve governance and grow contributorship. The tone ofinclusion and community health must be set at the top—usually by
the project founder and the small team that starts the project.

OPEN SOURCE MAINTAINERS

18

Community governanceand management“I tend to view the changes and ignore who’s actuallybehind it. Even if there’s a regular contributor

Community governance and management are often left out of

doing this commit (or proposing a change) or aconsideration in the early stages of a project. This is not surprising.

complete newbie, I try to view both identically.”

In the early stages, a project creator is focused on getting to aminimum viable project and creating a strong software f­ oundation.

—DANIEL STENBERG, LEAD MAINTAINER, CURL

When a project is birthed inside an organization, then governance is often an internal function and focused on internal needs
rather than the longer-term requirements of building a sustainablecommunity. Any complex project eventually requires codified
governance and a management structure—even if there is anatural “lead maintainer” overseeing the project (e.g., the creator).
For small projects, explicit governance policies and structure
may not be necessary for day-to-day management but become
essential for adjudicating disputes and for making long-term direction decisions about a project involving the community. Codified
governance is often overlooked when things are going great but
suddenly becomes critical when the community hits an issue. Hereis a collection of some of the best practices for community governance and management provided by the interviewees. Some ofthese are obvious—such as establishing a code of conduct. Others
are less obvious, more idiomatic, and may not work broadly acrossall projects but have been successful in their specific project.
Establish a code of conduct.
This is now common practice for successful open source projects
that wish to maintain a welcoming environment. Examples ofcodes of conduct are easy to find. Rarely do open source project
leadership teams and project members object to codes ofconduct. However, they are critical to prevent conflicts and to set aminimum standard for cordial interactions. In addition, it is often
critical to document the guidelines and processes for dealing with
reported conduct violations, removing bias from decisions, anddealing with repeat offenders.

Establish prevailing community norms of civility.
Codes of conduct are necessary but are not sufficient on theirown for setting the right tone. Many of the interviewees consistently mentioned that part of why they continued to contribute to
a community—and later agreed to become a maintainer—is thecivility of the community. Experienced maintainers also said thatthey politely requested community members to soften their tone
if it appeared that a discussion was getting heated. This was a way
to make a community conversation more welcoming by visibly
encouraging abrasive but well-meaning community members to
use a less abrasive tone in dialogue.
Design yourself out of your job ASAP.
Maintainers discussed how challenging it was to relinquish powerand control over their project emotionally. Most felt a strong senseof attachment to their projects. However, they recognized theimportance of giving up control to incentivize contributors andallow them to create and build a more self-sustaining and healthy
community. A handful of maintainers aggressively sought to give
responsibility out to any developers or volunteers who expressed

OPEN SOURCE MAINTAINERS

19

interest and could prove basic competence. “From minute one, I
was like, ‘All right, who can I transfer this ownership to? Who can I
give this responsibility to?’” says Norbert de Langren, lead maintainer of Storybook, who initially planned to only serve in thiscapacity for a single year.
Provide radical transparency.

Distribute power and decision-making.
Until 2022, the Jupyter Project used community-wide roughconsensus for making key decisions. While consensus worked wellin the initial stages of the project, as it grew in complexity andnumber of participants with over 1,500 contributors and over 100
GitHub repositories, building broad consensus became unmanageable. Many parts of Jupyter required specialized knowledge to

Maintainers often stated that they tried to push everything

understand and make decisions. According to Jupyter co-creator

happening in their projects from private to public channels toand maintainer Granger, even sub-projects with 50 or 100 contrib-

achieve 100% transparency. Most intuitively understood thatutors and maintainers were struggling with consensus. This was

open source communities expect transparency. For the most part,

slowing innovation.

private contacts came when private companies wished to submit
code changes and wanted to understand the best way to bring thisabout. Maintainers discouraged side-channel discussions such as
this. Radical transparency is especially important for two otherreasons. First, it simplifies succession and continuity, and second,it enables the entire community to participate in decision-making.

As a result, the project leaders struggled to make decisions whenconsensus was inadequate. This led to community member
frustrations and complaints, which in turn contributed to theburnout of project leaders After public discussions and deliberation, Jupyter adopted a modular governance structure with an
Executive Committee, a Software Steering Council, and Working
Groups to parcel out decision-making. “Our new model really
works hard to make sure that we have a good balance of power
checks in place, clear decision making processes, accountability
mechanisms, and that we handle conflicts of interest in a responsible and transparent manner. All of this is to make sure thatcompanies, individuals, and nonprofit organizations can come“Any open source projects where there’s atogether and work on Jupyter in a neutral, collaborative context,”
explains Granger.

commercial company that’s supporting the project—
it needs to be one community. It can’t be, you’ve got your

Maintain clear neutrality in community management.

commercial side, and they’re doing their own thing, andThis is particularly critical for projects controlled by a single orga-

you’ve got your open-source community, and they’renization or company. Experienced maintainers spoke of striving

doing their own thing. That doesn’t work because
you’re defeating the purpose of things being open.”

to maintain a neutral view of all contributors, even to the point of
ignoring the identity of submitters of issues and PRs. Some maintainers acknowledged that if a contribution comes from a regularknown for working on a particularly complex area, they may flag it.

—GARETH GREENAWAY, SALT

But, broadly speaking, they strove to treat all contributors and all

OPEN SOURCE MAINTAINERS

20

PRs filed with fresh eyes and on an equal basis. A critical piece ofthan larger projects such as Kubernetes. “It's rare to get someone

maintaining neutrality is demonstrating perception and awarenesswho just shows up and says, ‘Oh, I'm here, and I want to work onof what neutrality should look like and how a neutral party should

containerd. I don't work for a vendor who has container offerings,

behave. This entails both putting in the core work of maintaining

but I just love this technology’,” explains Estes.

a project in a very public manner as well as encouraging project
development that is clearly non-zero-sum, even to the point ofmaking a project more commercially useful beyond the controlling

Use test sets to enforce neutrality.
Another piece of advice from maintainers is to use test sets ascompany.
Explains Phil Estes of Amazon, a core maintainer of the containerd
runtime engine, “By doing generally helpful community chores,
often referred to as ‘chopping wood and carrying water,’ many times
you end up with credibility and trust that garners leadership in the
project, such that when it's time to say, ‘Hey, project maintainers, wethink this would be a cool way to make the project more observableor measurable, or this feature would be really valuable for these
specific use cases,’ those discussions get a lot easier when you've
been a critical piece of just keeping the project healthy.“That said, for many key critical open source
projects, there is often difficulty finding
independent or hobbyist community contributors with the time
afforded those working for
major vendors. This is areality for projects that
operate at the lowest
layers of infrastructure, such as
toolchains andruntime environments, which

forcing functions for neutrality. “Meta understands the importance of PyTorch as a project, but another thing that protects us
from conflicted interests between internal customers and externalcustomers is a good test set. Unit tests that we run in open source,that we also run internally, provide a very good proxy of what
the community needs versus what the company needs,” explains
Nikita Shulga, a PyTorch core maintainer.

Documentation
Creating a culture of strong documentation is essential at every
stage of open source project development. Documentation enables
smoother onboarding for new contributors and project users alike.
As a project scales, documentation becomes a key tool for communicating not only the “hows” of project code but also the architectural philosophy behind the engineering approach. While users andcontributors may not read the documentation before contacting
project maintainers and contributors on Slack or in GitHub, thedocumentation can simplify support tasks by enabling cut-andpaste responses to common questions. Incomplete documentation, particularly for commonly requested information, not only
erects barriers to adoption but also generates unnecessary work foralready overworked project maintainers and contributors.

require more

The significant majority of project leaders interviewed for thisniche skills

study expressed concern that their project needed to improveand could be

documentation. Recruiting and retaining good documentation

viewed as lesscontributors is a challenge. A second problem frequently cited isglamorous

the wish to overhaul documentation competing against merging

OPEN SOURCE MAINTAINERS

21

new code. Additionally, they cited problems or lack of capability ofstruggle and suffer from a lack of resources or high turnover. Most

documentation infrastructure, explains one of the core contribu-of the critical projects have a full-time, paid coordinator or docu-

tors and maintainers of the Apache Maven project:mentation leader or a paid project maintainer who is partly or

A full reorganization of the whole documentation is exactly the typeof contribution nobody is able to get because there are people who
perhaps could have the knowledge to change everything, but wewould need infrastructure. We would need to rework the contents.
In fact, nobody has the full ability to reorganize absolutely everything. It is as it is. I worked a lot to improve it, and at the moment,
yes, it keeps working as it is.
Projects that have built more advanced and systematic
approaches to documentation undertake a variety of steps toimprove the process and attract more contributors. Here is asummary of tactics used by successful maintainers to address
documentation challenges.
Make documentation a first-class citizen in the
project hierarchy.

solely tasked with documentation.
Either recruit engineers for documentation tasks
or create an educational process to nurturepotential doc writers.
The reality for complex projects is that documentation writers
must have a strong technical understanding of how the codeworks. According to Nabors, many of the best documentation
writers have engineering backgrounds. Some engineers actually
enjoy documentation because they enjoy the creative act ofwriting.
Require that contributors properly document theirPRs as part of the merge and build process.
Salt uses a flag in its development process to ensure that all code

This usually means a set of very visible policies and practices tosubmissions and patches have fulfilled documentation require-demonstrate to the community that documentation is critical.

ments. “The way Salt is structured, every module, every function

One approach is for project creators to sit on the documentation

within a module has a docstring. If we see someone contribute a

committee and be involved in documentation efforts. Anothermodule that has functions that you would run via Salt that don't

is to include documentation goals and metrics as part of overall

have a docstring, that pull request is not going to get merged,”reporting efforts for a project. According to Rachel Lee Nabors,says Gareth Greenaway, Salt maintainer. The Linux kernel follows

former documentation manager for the React Project at Meta,a similar policy. That said, documentation of code is only aproject founder and maintainer attitudes toward the docs team is

portion of the required documentation, but it provides a neces-a good indicator of the longer-term health of the project. She feels

sary foundation.

that when project founders and core maintainers take an active
interest in documentation, that increases the likelihood that a

Formalize documentation sprints, forums, andproject will continue to grow and attract new users.

other efforts.

Hire a documentation coordinator.

Many organizations employ “doc-sprints,” where engineers take abreak from coding to help write docs. But few make doc sprints a

Because it is an activity so largely unloved in the engineering

regular event running on a calendar and even included in overall

world, documentation that relies solely on volunteers tends toproject planning.

OPEN SOURCE MAINTAINERS

22

Make sure documentation writers receive publicpraise for their efforts from lead maintainers.
Mentioning all the documentation contributors in release
notes, shouting out to them in project meetings and online
events, and giving documentation teams their own swag are
just a few of the ways that projects can reward “docstars.”
Calling them out on social media is another low-cost, high-impact way to show appreciation for documentation writers.

Funding and other forms of support
How to support OSS creation is a controversial topic. Most open
source projects do not directly collect revenues for services or
products; many that do are controlled by a single company. It“There’s a class of folks who want to contributeto documentation, but they just don’t know how
because documentation change also meansa GitHub commit in the Ceph project. There’sthat class that wants to complain about the
documentation but can’t get to the right audience. I
created DocuBetter to bridge that gap andhelp both of those types of people
be heard and helped.”—NEHA OJHA, Ceph

is important to separate support into two buckets: financial
support of the contributors and maintainers themselves in theform of salary or sponsorship or business revenues and supportof the project and its organizational requirements, including
operations, marketing, infrastructure, and finances.
Financial support of contributors and maintainers was a concern
and problem for only one of the interviewees of this project.
Among critical open source projects, the majority of maintainers
and core contributors enjoy full-time employment. In most cases,
the employment allows them to spend a portion or all of theirtime working on their open source project. All but two of theinterviewees for this project enjoyed sufficient financial support
for their open source activities, primarily in the form of full-time

In one instance, a maintainer of critical open source projects thatis a solo project, expressed frustration that one of their projects
required a significant upgrade but that current mechanisms forfunding open source made direct funding to him a challenge.
Equally important, the maintainer noted that he did not even know
how to properly price the upgrade work because he would notunderstand the full scope without additional research.

employment. Two of the interviewees had been or were currently

Broadly, LF Research found that successful projects behaved inmaintainers of projects that relied primarily on sponsor dollars toa fashion similar to a business or a nonprofit organization. Thispay maintainers and to cover operating costs. One of the main-

meant software development was the first priority but projects

tainers helped found a consultancy that offered consulting andalso put considerable ongoing efforts toward fulfilling other opera-

services focused on the open source project the maintainer

tional requirements, including fundraising, marketing, operational

had worked on. Most of the maintainers worked at larger orga-

support, and infrastructure. Numerous organizations and startup

nizations, where part of their explicit duties was to continue

businesses are seeking to address one or more of these areas; thecontributing to or working on the project.

majority of these efforts focus on increasing sponsorships andOPEN SOURCE MAINTAINERS

23

building funding sources. Fewer organizations focus on otheroperational aspects, which are inherently less interesting to

grants (OpenSSF grants to OpenSSL and other key open source
security practices).

sponsors and other funders. Several respondents noted
that, globally, governments are only starting to recognize the importance of supporting open source
projects with grants to foster the development of both technology tools and tooling for

For small independent projects, determine if theyrequire funding and, if so, designate a funding leador set up a supporting business.

ongoing R&D in biology, materials science

Of the three small independent project maintainers interviewed,

and chemistry, applied physics, and othertwo had a person working for the project as an employee or in

relevant disciplines. Interviewees iden-

project leadership responsible for funding. The third did not prior-tified established the following best

itize work on their own open source projects over their day job,practices for funding and support.

which did not include working on those projects. The two smaller
projects that did have a full-time fundraising maintainer (who also

Ensure there are regularsources of project fundingor support.

handled other non-code tasks) were able to pay primary maintainers a living wage based on sponsorship and other forms of
support. The lead cURL maintainer dedicated part of their work
hours to helping paying clients solve cURL issues or designing

At the risk of stating the obvious,and coding features clients wished to have included in the cURL

the financial viability of a project iscode base. While not a massively scalable business model, it did

key to a successful project. This cangenerate sufficient revenue to maintain the lead maintainer’s

take various forms, including insidepaycheck and to earn a profit for the maintainer’s employer.

funding at a company where a project
is solving a problem but is not a core
part of the company product; indirect
funding through academic grants or ongoing
research by academics (multiple key open

Small independent projects should offload asmuch administrative work as possible.
The reality of any open source project is that it is a nonprofit

source projects launched as academic researchorganization and must check all the boxes required by these orga-

projects, including Ceph, Apache Spark, and others);

nizations, including handling finance, marketing, infrastructure,

direct funding through consortia or foundations; anddirect funding at a company that uses the project as partinternal IT, and more. Developers working on open source projects
are not COOs and rarely enjoy that part of the job or respon-of its core product but views a community and open source

sibly managing an open source project. This can be accomplishedas additive and complementary to its business model rather than

through joining foundations, signing up with organizations that

purely competitive (Chromatic is an example of this). For solo andfocus on providing operational support to open source projects,

unaffiliated projects, potential sources of funding include sponsor-

and utilizing free automation tools in platforms such as GitHub toships (GitHub sponsors, LFX, Open Collective), paid support andperform key operational tasks, ranging from the deployment ofdependency models (Tidelift), and one-time foundation or industry

new code builds to license selection.

OPEN SOURCE MAINTAINERS

24

Diversity
As with other sectors of tech, diversity remains a challenge for thesignificant majority of the interviewees. Few of the most criticalopen source projects have a significant representation of diverse
maintainers and contributors. Some have virtually none. While

strategies, which included some best practices for building morediverse project leadership. Some of those best practices included:
Make diversity and inclusion a first-order goalof a project.

all maintainers interviewed stated they wanted to improve theMany critical projects treat diversity and inclusion as a bit of andiversity of their maintainer and contributor base, many projects

afterthought. They lack a standing committee or defined efforts to

did not have defined diversity strategies, and some pursued

build diversity. They may have goals or aspirations but few specificlimited or no programs to increase diversity. That said, somemechanisms in place to advance diversity. Forward-thinking

diversity efforts are now commonplace, such as using inclusive

project maintainers seek to include diversity and inclusion as a key

language (see Contributor Experience).

goal of the project. For example, Jupyter had significantly elevated

Projects of smaller size and operating in more complex areas ofprogramming (runtime environments, databases) do not requirelarge contributor bases. In these smaller projects or teams, it isoften hard to sustain formal efforts to improve diversity; maintainers tend to have to juggle multiple priorities. The most pressing
need is shipping code because there is no bench of potential
contributors eager to enter and contribute to the project. This
problem is particularly acute for projects written in older, more
technical languages such as C or Java. “It's an ancient language
for most people. It's a very niche language over there, and it's
mostly just old people working on it,” explains Stenberg, who sayscURL does not have a defined diversity strategy beyond periodic
outreach. “We would love to do better with getting new contributors
and creating more diversity. I have posted on Twitter asking for help.
We have asked the community. I am very open to any suggestions.”

diversity and inclusion efforts to the highest levels of the project
in its recent governance changes. “Our new governance model
has a DEI standing committee that is a key part of the governancemodel,” says Granger, one of the creators of the project and a leadmaintainer. “That body has a seat, for example, on the Software
Steering Council that makes decisions about the overall directionof Jupyter’s software. We are prioritizing diversity and inclusion,
and we haven't always prioritized it at this level.”
Pair mentoring with diversity efforts.
Recruiting contributors who can later become core maintainers isonly half the battle. Most lack experience in open source and canbenefit from active mentoring by maintainers, who can explain
the conventions of the paradigm and help them navigate theprocesses and group dynamics. “There are a few challenges in

Programs to improve diversity, such as Google Summer of Code andmentoring this large number, and they require careful planning to

Outreachy, represent additional responsibility and time commit-

minimize the overhead,” explains Khan of the Linux Project, who

ments for already time-strapped smaller projects, according tomentors 13 individuals. The office hours are for answering ques-maintainers of these projects. Larger projects and projects affili-tions, sharing resources, and demonstrating tools and debugging

ated with foundations or umbrella groups or larger corporations aretechniques as required. For Khan, some of these new contribu-

more likely to pursue these outreach programs. Maintainers report

tors have turned into mentees working on becoming more regular

mixed results on the quality of interns and contributions.

contributors as part of her work on the LFX Mentorship program

More advanced and developed projects had specific diversity

at the Linux Foundation.

OPEN SOURCE MAINTAINERS

25

Participate in third-party programs to boost
diversity, such as Outreachy.
There are a handful of programs dedicated to fostering
diversity in technology companies and roles. The most prominent is Outreachy. The Linux Foundation also funds a variety“There’s like a Maslow’s hierarchy thing going on
there. If a maintainer has enough money, they don’t
have to overwork themselves at a different job, andthey don’t have to worry about medical problemsof diversity scholarships. “I believe in Outreachy. I think it's aand housing and food and things like that, then I

fantastic program for being able to bring in a wide variety ofthink that the risks of burnout drop considerably.”

contributors and other things,” says Abbott. “I'm thrilled to seethat Fedora continues to host interns with Outreachy pretty—JORDAN HARBAND, MAINTAINEROF QS AND es5-shimmuch every round they can, and they work in a wide varietyof areas, including not only engineering but also design anddocumentation.”

Preventing maintainer burnout
The job of maintaining a vital open source project can be
exhausting and draining. Each interviewee was familiar with
the idea of maintainer burnout. Several maintainers mentionedthat part of burnout comes from the different nature of open
source development. All activity is public and subject to commentand scrutiny. Projects that rely solely on consensus for decision-making among participants and leadership often require
additional work and interactions to build consensus and may
accelerate burnout. “I think that there's a certain magic to a
project like Node.js, for example, that does the open model, thathas a truly openly governed steering committee, with an open
governance system,” says Myles Borins, a maintainer of the npm

Recognize you will never “finish the job.”
Until a project is sunsetted, open source work is never finished.
There will always be PRs and issues waiting to be read andresponded to. Successful maintainers recognize and accept that
their work is never-ending. ”Always just be realistic about what you
personally can't accomplish. It's okay to balance that with otherthings. It's okay if you don't complete everything on your to-do list
because open source maintainership can fill an infinite amount oftime if you let it,” explains Abbott.

package repository and Node.js. “But I think to a certain extent,
the ambiguity that exists and the difficulty of really balancing

Accept that open source is always on, and embracea consensus model with a lot of people who tend to be conflictthe hybrid lifestyle.

diverse or just want to be nice all the time results in patterns thatare likely to burn folks out.”

Some maintainers that did not experience burnout designed
their lives to work around the flow of open source. They never

Most interviewees had created specific “survival” practices andreally turned off from their projects, but they did take advan-

strategies. These are not complicated or detailed; most are

tage of the flexibility of open source to maintain healthy external

common sense. That said, it remains useful to survey these prac-pursuits and spend time with family and friends. Jordan Harband,tices. Some burnout prevention methods included:

maintainer of `qs,’ for example, elected never to take a vacation
OPEN SOURCE MAINTAINERS

26

from his open source maintainership and governance work,

the project. Most avoid private email conversations about

but he built a lifestyle that enabled him to spend time with histheir project, wishing to route all discussion into publicly visible

partner and children, exercise, and hang out with friends. This is

GitHub repos or email listservs. Some maintainers simply ignore

not for everyone, he notes, but it worked well for him.

comments or messages outside of the project's GitHub repos.
Additionally, many maintainers set workday boundaries to ensure

Working on open source projects that are rapidly
expanding and require administrative overhead as an
unpaid hobby is not advisable.
This was the general advice from interviewees, the majority ofwhom were well paid to work on fast-growing open source projects.

they spend time with friends or family. They found that once thecommunity understood the boundaries, they respected them andtended to follow them.
Step away if you feel burned out.

Many worked on open source projects on the side for fun, but none

Multiple maintainers said that when they begin to feel burnout,of those projects required the same levels of administration andthey take a vacation or they take a break from working on theircoordination work as their paid open source work. “If this is some-project. In part, this came with cultivated self-awareness of whatthing you're not necessarily getting paid to do and you are having toburnout feels like. Most carve out exceptions for critical periods,

spend extra hours outside of your working hours doing stuff that’ssuch as big version pushes, annual project planning sessions or

not fun, it might be a different story in terms of causing maintainer

online events, and vulnerability remediation efforts.

burnout,” notes Eli Uriegas, a PyTorch maintainer focused on build
and release tooling.
Constantly look for efficiency hacks to optimize
and automate your workflows.
Super maintainers tended to have bespoke setups to filter project
activities and allow them to focus on the activities and issues thatmattered the most. This may include an aggressive use of email
labels, filters in GitHub, the use of bots to automate workflows,or other mechanisms to automate processes or enable greater
focus. For some maintainers, such as Tobias Koppers of
Webpack, the best way to do this is only to respond to communication in only one channel—in his case, inside of GitHub.
Set boundaries and stick to them.
Seasoned maintainers said that they strictly stickto boundaries on various parameters. For example,
most refuse to engage in Twitter conversations about

OPEN SOURCE MAINTAINERS

27

Conclusion
Over the course of interviewing 30+ maintainers, LF Research

to attract maintainers, so they may do well to seek out a corporate

heard many amazing stories and learned how some of the mostsponsor. Each combination of attributes comes with its own

successful projects effectively navigated the myriad challenges

recommendations, and there is no one-size-fits-all playbook. Thatof founding, nurturing, and growing an open source project.

said, common patterns for specific attribute types can help inform

LF Research hopes that these insights enable future genera-

project strategy and direction. Projects will change and evolve

tions of maintainers by documenting patterns and anti-pat-over time. But even at inception, it is possible to have some idea ofterns of successful maintainership and project formation andwhere a project sits with regard to the four attributes.

management. These patterns can provide detailed situational
guidance for many of the common problems faced by open
source projects and their maintainers, as well as ideas on how to

TABLE 1

surmount or, even better, preclude these problems from devel-

PROJECT ATTRIBUTES FOR CREATINGA RELEVANT MAINTAINER STRATEGY

oping and becoming significant concerns. In the detailed anecdotes and suggestions, LF Research aims to provide maintainers
with a basic tool kit for managing their projects as well as ideas forcreating a positive work / life balance. This report only scratches

Size

Small

MediumLarge

Supported

No Funding

Some Funding

Well Funded

it into this paper. That said, from these interviews, LF ResearchComplexity

SimpleModerate

Complexgarnered several specific action items for maintainers that can

Criticality

Low

MediumHigh

Lifecycle
Stage

Startup

Fast Growth

Maturethe surface of an immense topic; in the interest of brevity, many
instructive maintainer stories from our research did not make

improve both their project experience and project code quality.

Determine your project attributes.
Identifying your project attributes from the four categories listed
below is key for creating a maintainer strategy (see TABLE 1). For
example, a small but complex project with high criticality (OpenSSL
is a good example) will likely need to think about both recruiting
highly skilled maintainers and securing funding sources from
corporations or others that rely on the project. And any projectwith high criticality benefits from a transparent, community-based
governance process that is designed and implemented with
community input—as early in the project life cycle as possible.
Very large, complex projects that are well-funded, like Kubernetes,
face more of an issue of promoting governance and neutrality.
Medium criticality and moderate complexity projects may struggle

Create a strategy and road map
based on your attributes.
Recognizing that often open source project management is adhoc, and too much structure can become a blocker to productivity, maintainers will find it useful to create a rough strategy
for the project to help focus activities and guide contributors
and co-maintainers. This strategy document is worth revisiting on an annual basis to ensure that activities match attributes. For example, if a project moves toward becoming a critical
OPEN SOURCE MAINTAINERS

28

dependency in the technology ecosystem, then a project may

metrics that provides a palette to choose from and a great startingneed to prioritize additional security activities. If a project ispoint for maintainers.

clearly moving from early stage to fast growth, then the maintainers may need to spend more time building onboarding
infrastructure and ramping documentation. Again, there isno perfect recipe, but a mindful approach to maintainership
regarding attributes and stage can enable focus on whatmatters in what is always a noisy process.

Identify key metrics for yourproject, and track them regularly.
Project and community health are highly subjective anddependent on the maintainer and community definition of
success. For example, a front-end framework primarily
backed by a large company may care less about thepipeline of new contributors versus whether
contributors are constantly submitting
bug reports and suggesting fixes.
And projects that are deep in thestack and complex to codefor may prefer to measureexisting community performance—ship dates, code
quality, etc.—rather thancommunity growth. Thatsaid, determining thehealth indicators for a
project and measuring
them is a key stepfor better project
management andmore productive maintenance. The CHAOSS
Project offers a laundry
list of community health

Identify best practices for your project.
Open source project formation and maintenance can be overwhelming. Focus and clarity are critical. The preceding three piecesof guidance lay the framework and strategy. Putting in place thetactical steps and processes to impact project health and drive
project improvements in the desired areas works best when
project leadership and the community cooperate to lay out playbooks, best practices, and specific ways of working. It is possible
for projects to lay out detailed guidance across a wide varietyof areas, but for all but the largest and best-resourced projects,
maintainers may want to focus best practices on the areas andmetrics identified as being most impactful. For example, Salt is
now at a scale where it wants higher quality code and less codeoverall in the core project, with more functionality moving toSalt-community-managed extensions. To match this goal, Salt
has made test compliance a mandatory part of the submission
process, versus optional before when the project was more
focused on pulling in new contributors to the core project’s codebase. This is just one small example that highlights how you canleverage best practices to impact-focused areas of a project.
LF Research hopes that this will create a starting point for conversations and that, with the help of the growing maintainer community,
LF Research can grow this body of knowledge, heuristics, andobservations to cover a wider range of situations and tasks than
this initial effort. The open source maintainer plays a critical role inaccelerating global innovation and building enterprise, government,
and nonprofit technologies that will solve global challenges andimprove people’s lives. Creating a body of reference knowledge anda larger pool of competency in this discipline will ultimately makeopen source more useful and successful by helping maintainers
and contributors help themselves, building on the shoulders ofwhat we have learned from those who came before.

OPEN SOURCE MAINTAINERS

29

Acknowledgments
This report would not have been possible without the help from numerous open source project maintainers who took the time to talkwith us about their work and share their wisdom and insights. We wish to thank:• Rachel Lee Nabors, Brian Granger, Phil Estes (Amazon Web
Services)• Myles Borins, Andres Freund (Github, Microsoft)• Eli Uriegas, Nikita Shulga (Meta)• Shuah Khan (Linux Foundation)• David Edelsohn, Neha Ojha (IBM)• Siddesh Poyarekar, Carlos O’Donnell (Red Hat)
• Anil Sharma, Gareth Greenaway, Pedro Algarvio, Megan
Wilhite (VMware)• Norbert de Langen (Chromatic)• Daniel Stenberg (wolfSSL)• Laura Abbott (Oxide Computer)• Tobias Koppers (Vercel)• Joel Orlina, Jason Swank, Hervé Boutemy (Sonatype)• Sterling Greene (Gradle)• Liz Rice (Isovalent)• Ralf Gommers (Quansight)• Henry Zhu• Jordan Harbend

About the Author
Alex Salkever is the co-author of four books on the impact of technology on business and society including, “The Driver in the DriverlessCar” and “Your Happiness Was Hacked.” He worked in senior leadership roles in product and marketing at numerous technology
companies and also served as the technology editor for BusinessWeek. A longtime open source advocate, he has worked with the LinuxFoundation on special projects since 2016.

OPEN SOURCE MAINTAINERS

30

Founded in 2021, Linux Foundation Research explores
the growing scale of open source collaboration,
providing insight into emerging technology trends,
best practices, and the global impact of open source
projects. Through leveraging project databases andnetworks, and a commitment to best practices inquantitative and qualitative methodologies, LinuxFoundation Research is creating the go-to library foropen source insights for the benefit of organizations
the world over.

Copyright © 2023 The Linux Foundation
This report is licensed under the Creative Commons

Attribution-NoDerivatives 4.0 International Public
License.

To reference this work, please cite as follows: Alex
Salkever, “Open Source Maintainers: Exploring thepeople, practices, and constraints facing the world’s
most critical open source software projects,” foreword
by Shuah Khan, The Linux Foundation, July 2023.

OPEN SOURCE MAINTAINERS

31