So, I'm going to talk today about strategies for building healthy open source communities.
I wanted to start by just quickly thanking the Alfa Peace Loan Foundation.
So, they fund the Chaos Data Science Initiative, which pays me, and also thanks to the Linux
Foundation and Board Foundation, which also provides support for the projects.
I have been in the technology industry for well over 20 years, working mostly on open
source projects with a focus on community strategy metrics and growing your contributor
base.
And I can tell you that it is really, really hard to build a strong open source community
for a project.
Most of us struggle with finding enough humans to sustain our projects.
So, let's start by talking just a little bit about the problem and why it can be so hard
to achieve sustainable communities for open source projects.
Like I said, the problem is hard.
I like to start my community talks with a quote from an alien life form on Star Trek
the next generation who described humans as ugly bags of mostly water.
Now, I don't think we're ugly, so I think they missed that part.
But we're super squishy, right?
And not just in the physical sense.
We can be unpredictable.
We can be irrational, especially when we're stressed out, overworked, burnt out.
And the reality is, right, we're not robots.
We're not mindless automatons.
We have feelings.
We have bad days.
We have other commitments and we have personal challenges in our lives that are often completely
invisible to other contributors.
And they can get in the way of our contributions to open source projects.
But you can't have an open source project without having human beings to maintain it.
So you need to be able to encourage people to participate in ways that are sustainable
over the long term, both for your project and also for those people.
And it helps to be proactive and ask people to participate in specific ways and in ways
that match the work you need to do within your project.
Now many projects struggle to find people who will actively participate in their projects
and continue to participate over the long term.
If it was easy, you'd already have all the people you need to maintain your project.
We wouldn't need this dev room.
And none of you would be here watching this talk.
But I think a common theme throughout all of the presentations in this dev room so far
really has been that we're in a situation now where there are a lot of open source projects
and not enough contributors and not enough resources to maintain those projects.
So maintainers are burning out and they're in desperate need of help.
And sometimes it can be really difficult to get people to contribute to your project.
And unfortunately there's no magic, there's no one size fits all solution.
So throughout this talk I'll focus on some things you can do to increase the chances
of building a community and growing contributors for your project.
Now that we've talked about the problem and some of the challenges, I'll shift into talking
about strategies for building healthy communities.
So next I'll talk about, and after that I'll talk about us taking a strategic goals based
approach to metrics.
And then finally I'll talk about some metrics you can use to measure project sustainability.
To grow your community along with some resources and some final thoughts at the end.
So as promised let's start by talking about developing and executing on a long term strategy
for building a healthy community.
Including motivation, project governance, new contributor onboarding, roadmaps, contributor
ladders which you might have heard before from some of the talks, and leadership.
To have people's motivations for contributing to your project vary widely.
Some people are contributing as a part of their job while others might contribute to
gain experience or maybe learn about a particular language or particular technology.
Regardless of why they showed up there are some things you can do to motivate them to
stick around.
Clear communication, working in the open, and reducing friction are key to helping people
stick around.
And I'll talk more in the upcoming slides about the importance of explicit and clearly
communicated project governance along with onboarding docs and fostering a welcoming
community.
There are also other things you can do to motivate people to contribute.
Having good first issues or help wanted labels are excellent places to start because these
help those humans find something they can work on while they learn more about your project.
Good first issues and help wanted labels are passive requests for help.
So I also encourage people to be proactive and specific about ways that people can help.
Asking someone specific to review a PR or answer a question or respond to an issue demonstrates
that you recognize their unique expertise and that you want their help with it.
Anything that we're wanted and appreciated makes us squishy humans feel good, right?
Which can be a strong motivator to contribute to an open source project or to continue contributing
over time.
People can also be more motivated to contribute when all of the project work is done in the
open where they can participate as equals.
When some of the work is done within the walls of a company or maybe inside a close knit
group of maintainers it can leave the rest of us feeling left out and demotivated.
A lot of people like to hate on project governance.
It's just extra paperwork, it's busy work, it's politicking, it gets in the way of doing
the real work on the project.
But this isn't true of good governance which is really just about setting the expectations
and getting all of the various humans within your community collaborating together.
Ultimately the focus of project governance is on people, the roles we play, our responsibilities,
how we make decisions and what we should expect from each other as part of participating in
the community.
The goal should be to make the processes for participation as obvious as possible.
Even for people who are brand new to the community.
Having clear rules about how collaboration occurs, how decisions are made, what types
of contributions are in or out of scope helps community members make contributions that
are likely to be accepted and embraced by the project.
This helps avoid wasting people's time with contributions that maybe just aren't aligned
with the project for whatever reason.
A healthy project with clear governance makes the humans happy and it sets your project
up for future growth and long term success.
The good news is you don't have to start from scratch.
The link we have here is some good templates with some instructions that apply to most
projects if you want to quickly and easily build out some basic governance for your project.
It's a lot more difficult to participate in a community if you don't know anything about
the role you might play, the expectations, the key players or any of the rules for participating.
That explicit documented project governance gives you both new and existing contributors
a clear path to guide them through your project.
Spending a bit of time documenting that governance up front can save you a lot of time later
with fewer questions about how things work and it gives you a document that you can
point those other humans to if they have questions.
When I start contributing to an open source project, I want to know how decisions are
made, who makes those decisions, where the discussions about those decisions happen,
which helps me understand whether those decisions are made fairly and out in the open.
The bottom line is that if the processes for collaboration and decision making are not
clearly documented as part of the project governance, this introduces uncertainty into
the mix and uncertainty makes the humans nervous.
It increases the barrier to contribution and it jeopardizes the health and viability of
your project.
Good documentation is how we scale the things that take up precious time for the already
overworked human beings, like answering the same onboarding questions over and over and
over and over.
I see so many open source projects with contributing guides that don't actually provide any useful
information for people who are contributing.
At a minimum, a new contributor needs to understand how to spin up an environment where they can
do their development, the expectations for testing, how to run tests, and any processes
or other expectations that you have for pull requests and then instructions for any other
requirements you might have.
If this is all well documented, new contributors can get started with a minimal amount of help
from the existing maintainers, which can save you a lot of time in the long run.
When a project doesn't have good onboarding docs, those poor, squishy, burnt out maintainers
can get frustrated by the amount of time they spend on new contributor questions, which
can make it hard for contributors to feel welcome.
It'll take a longer time for them to become productive.
This is how the humans get discouraged and then just drift away from your project.
This does not mean that you need to spend weeks and months writing the perfect onboarding
documentation.
At this point, anything is better than nothing.
If you start with a few things that help people actually get started quickly, then new contributors
can help make those onboarding documents better by adding more details and maybe some additional
instructions for something that they found confusing or that they struggled with.
Then after onboarding, people need to be able to find something to work on.
Having public roadmaps is a great way to do your planning in the open, while helping people
find something to work on that aligns with the direction of the project.
If you were here yesterday for Lori Apples' talk, she talked a bit about roadmaps as well.
Roadmaps provide some crucial functions within open source projects, including setting the
direction of the project, prioritizing tasks, organizing the work, and attracting and retaining
contributors, and also providing transparency into where the project is heading.
I think a lot of people underestimate the impact that a well-defined and up-to-date roadmap
can have when building community around a project.
They can help guide everyone toward achieving common goals and having a shared vision about
the future of a project to help contributors work on activities that are aligned with that
vision.
The document linked on the slide has loads of detailed information about building a roadmap
for your open source project.
One of the most important things to think about is how you'll maintain that roadmap over time
and actually keep it up-to-date.
It can help to use tools that are already part of your development or your community processes,
like GitHub project boards, for example, if you use GitHub, so that people don't need
to use yet another tool.
If you have community or developer meetings, it can help to have someone walk through the
roadmap every couple of weeks just to talk about the things that are blocked or need
help.
Maybe set aside some focus time once or twice a year to think about the future of the project,
and then you can incorporate that back into the roadmap.
Bonus points if you can find a really good project manager who can help with the process.
Your project should also be designed to keep diversity, equity, and inclusion top of mind.
Building a diverse community where all of these humans feel welcome and included doesn't
just happen.
It requires putting work and thought into it.
But this time is well spent, right?
Providing an environment where everyone, including people from marginalized populations, feels
safe is the first step toward building a diverse community around your project.
Ideally having programs that give people opportunities for shadowing, mentoring, and sponsoring new
potential leaders can help you grow a diverse set of people into new leaders for your project.
Paris talked a bit about this.
The Kubernetes experience, sorry, the Kubernetes contributor experience special interest group
is a really great place to see some examples of how to implement programs for things like
shadowing and mentoring.
And projects that make a concerted effort to actually bring in new people from a variety
of backgrounds and have programs in place to move them into leadership positions are
more likely to benefit from increased innovation and just have a healthier contributor community.
And by having a diverse and welcoming community, you have the advantage of getting those humans
who might not feel welcome in some other projects.
Now Paris and Bill both talked about contributor ladders.
Defining the roles and responsibilities for contributors, reviewers, and maintainers can
really help with recruiting new humans into these roles.
It can help to think about this as a ladder where contributors can climb up to become reviewers
and those reviewers can become maintainers.
But what's important is to document and make sure that people understand how they can climb
that ladder and how they can gain more responsibilities within your project.
A contributor ladder usually outlines the different contributor roles within the project
and along with the responsibilities and privileges that come with them.
Having a contributor ladder helps set expectations for the roles and it encourages people to
think about how they might take on areas of increasing responsibility within the project.
And as you get more of the humans moving into maintainer roles, you can reduce the load
of the existing maintainers.
And the good news is, again, there's a template that you can use to avoid building this from
scratch.
This one was based on Kubernetes, so it probably has more roles than you need, but you can
simplify it, customize it, make it work for whatever your project needs.
Paris talked a little bit about emeritus as well, so I feel like I'm just dovetailing
on all the things Paris said.
But humans like to think of ourselves as irreplaceable.
We are not.
We move on to other jobs.
We burn out.
We retire.
And let's face it, unlike the robots, humans are mortal and we do not live forever.
You should think about what you might want to do next and how you can prepare someone
else to take over after you move on.
I encourage projects to have an option for people to move into emeritus roles, which
recognizes the hard work that they've put in into a project and gives others a point
of contact.
If they have any questions about what came before, while also allowing you to step away
from the day-to-day responsibilities of the project.
And I encourage you to think of stepping into an emeritus role as a successful way of just
sort of handing off your duties to the next generation of maintainers for a project.
Now, I've talked a lot about things you can improve.
Metrics can help you decide where you need to improve your community and measure your
progress after making improvements.
But quite a few people seem to take what feels to me like a random approach to metrics by
measuring the things that they see other people measuring or gathering the metrics maybe that
are easiest to collect.
And maybe this even provides something useful.
But I encourage you to think about your goals and take maybe a less random and more strategic
approach by focusing on those goals.
And when I say start with the goals, I don't actually mean start with your goals for the
community.
I actually think you need to take a few steps back and start at the very top.
What's important for your organization or what's important for your project as a whole?
And this in a lot of cases has been a company in my case, but it could be an organization
like a foundation.
It could just be the project instead of an organization.
But you should start by looking at what that organization or project hopes to accomplish
and what its goals and objectives are.
And then you can take this down a level and figure out what your goals are as a community.
And your roadmap can be one input into this whole process.
And the most important part of putting together the strategies and plans for your open source
contributions is then aligning them with the overall goals of your project.
If your goals for the community don't support the overall goals for the project, you aren't
likely to be successful.
So it's worth the time to figure out what you want to do and how it supports the rest
of the project or how it supports what your organization is trying to achieve.
Once you figure out what you want to do as a community and then can tie it back to the
bigger organization or the project, then you can start looking at using metrics to measure
your progress.
So people often ask me, for example, of the projects with the best metrics.
But I really just don't think that's a good approach.
What you measure depends on your goals and what you're trying to achieve, which may be
completely different for other projects.
So I prefer to encourage people to start by defining their goals.
And ultimately, you need to look at your strategies and plans and come up with criteria that will
help you measure whether or not you are successful.
For example, if you want to improve the performance of a particular piece of open source software,
measuring commits is not going to get you that.
You actually need to have success criteria and measurement based on those types of performance
you're trying to improve.
If you want to gain influence within an open source project, maybe you work at a company.
Maybe you measure increases in contributions or the number of employees who are moving
into positions of leadership.
And as with any good strategies and plans, hopefully the outcome and results should be
measurable so that you can tell whether your efforts are successful.
And this is where your metrics come in handy.
Once you decide on your success criteria, you need to make sure that you can get the
data required to measure it and maybe start measuring it now, get a good baseline of data.
And there are loads of tools available to measure data about open source projects.
Some of the commonly used tools can be found in the Linux Foundation's Chaos project where
I work.
But there are also loads of other tools and lots of big projects already have dashboards
using either the Chaos tools or CNCF uses DevStats.
There are loads of tools available for doing this.
Since this is a presentation about building community, I encourage you to focus on your
goals while also thinking about your time would be best spent on community activities.
I've given a lot of suggestions so far in this presentation and you should not try to
do everything at once.
So I recommend that you think strategically about where you should start while keeping
your goals top of mind.
If you know you've had people interested in contributing but they've given up when
they couldn't get started, maybe you should start with onboarding docs.
If you have a lot of casual contributors, maybe you focus on the contributor ladder and governance
to help move some of those other humans up to take on more leadership positions.
An excellent way to free up time from maintainers is by getting help with different types of
contributions that take up valuable time and are actually required to make an open source
project successful.
Things like documentation, marketing, community management, project management, and many more
roles.
For projects with complex code bases especially, it can sometimes be easier to onboard people
into these roles first to free up some time to onboard other contributors later.
This also has the advantage of bringing people in to help with things that can have a big
impact on growing your community like roadmaps, governance, and other documentation.
Time is precious.
So it is important to identify the problem areas within your community where you can
focus on the right things while avoiding wasting time on areas that are already working
well.
However, metrics do need to be interpreted in light of your goals, how you operate as
a community, and all of the other things happening within your project.
There's no one size fits all interpretation of metrics.
So in this next section, I'll use some example graphs from some of our chaos metrics and
talk about what some trends might indicate and how to think about addressing potential
issues.
One key area to look at for your project is responsiveness.
This is a backlog graph from the chaos grammar lab tool.
In this project, you can see that there are times where they've got a lot of PRs in the
backlog that need to be merged or closed.
Now, if these PRs are coming from several regular contributors who aren't maintainers,
it might be a good idea to look at how you can promote some of those humans to become
reviewers or maintainers to help out with the workload.
But as with any metrics, you need to interpret them in light of your project.
There are other things that can cause an increase in the backlog, like everyone preparing for
a big release or maybe a big conference or just vacation season that might not be resolved
by moving more people into leadership.
Again, these graphs come from grammar lab.
Other metrics to look at responsiveness focus on the amount of time it takes for maintainers
to close issues in PRs.
Looking at trends for these metrics is particularly important.
This example, you can see that it's taking a lot longer for maintainers to close issues
or PRs.
It might be a good idea to look at how you can promote some more humans to become reviewers,
maintainers, help with the workload.
Again, you need to interpret this in light of your project.
There are other things that can cause an increase in time to close, like the project becoming
more complex or becoming larger, which can just increase the time required for things
like testing and other activities that would happen in the process of reviewing and closing
PRs.
It can also help to look at the types of contributors that you have.
In this case, casual contributors are those drive-through contributors who make a small
handful of contributions and then disappear possibly forever.
Regular contributors are the ones who make some contributions and then they stick around
and continue to make contributions over a period of time.
Core contributors are usually the maintainers who are there for the long term.
You can really learn a lot from this graph.
If you have a very small number of casual and regular contributors, this can mean that
people don't have the information needed to become productive and to contribute.
In some cases, onboarding docs can help solve these issues.
Another thing this graph can indicate is whether there may be some fundamental issues within
the project that are driving the humans away from your project.
If you see the total number of contributors declining or the number of regular contributors
declining, this can indicate some deeper issues, maybe toxic community members or an
unwelcoming environment, and that probably needs to be resolved before you do anything
else.
Or it can mean there are other issues with things like lack of responsiveness.
This metric is often called the bus factor or lottery factor based on the idea that if
one person disappeared after winning the lottery and that person was making all of the contributions,
then the project would probably be in trouble if they left.
This graph uses data from Chaos's Augur software.
I recommend measuring this because there are a few things that can tell you.
First of all, how big of an issue is your current contributor situation?
If it's like this one, you really should focus on getting some additional contributors and
maintainers.
You also might find that there are people who are contributing more than you realized,
which is the other reason this is a good metric.
This can help you think about who you can encourage to contribute more or maybe find
someone who can move up the ladder into a leadership role.
So you might look at some of those people who are a little bit lower down on the graph
and see if you can promote them up into being a maintainer.
The catch here and with so many metrics is that we don't want to just think about the
people who are making commits.
This is a good start, right?
It's a start, but you should also be thinking about how to move people into leadership positions
to be responsible for things that might not show up in GitHub, like documentation, community
management, marketing, mentorship, lots of other important roles.
And metrics are not something that you look at once and never revisit.
It's important to think about metrics gathering as an ongoing process of measuring, improving,
and monitoring.
So you think about your goals and what you want to achieve.
You pick some metrics.
You make improvements, and then you monitor that over time.
And before I wrap up the talk, here are just a few resources that you might find useful.
There's some great stuff there from the CNCF contributor strategy tag around how to use
and templates.
The Open Source Way guidebook is just another one of my favorite community resources.
And then the chaos metrics.
We also have a Slack channel.
You're welcome to join us.
Anyone can participate in the chaos project.
Maintaining an open source project is so much work.
And there are so many maintainers who are overworked, exhausted, and burning out.
The best way to address this challenge is by finding more humans and growing your contributor
community.
But it's hard work, right?
And it takes time away from the day-to-day activities now, which can be super hard to
justify if you feel like you're barely keeping up as it is.
In the longer term, spending at least a little time on things that can help you recruit and
keep new contributors will be worth it.
And as I mentioned before, you don't need to do everything at once.
Think about your goals.
Use your metrics to help you figure out where your time would be best spent.
So this is what I'm asking you to do.
If you're a contributor to an open source project, carve out maybe an hour a week to
improve your onboarding docs, your contributing guide, your project governance metrics, or
just spend that time helping another human learn to do something new in the community.
With that, thank you.
And I'll, I think we have another two minutes for questions.
Yes?
Thanks for the presentation.
It seems that some of the ideas that you presented, the contribution layer, the layer.
Sorry, can you speak up a little bit?
Thanks.
Thanks for the presentation.
It looks like some of the ideas that you presented,
like the contribution ladder, can be maybe at odds
with a project that is really owned by a company
or where there is a strong presence of the company.
Do you believe that there is a way to resolve this?
Yes, I do think that there's a way to resolve that.
I do think that sometimes the governance
and the contributor ladders sometimes
work a little bit differently
when you're talking about projects
that are owned by companies.
I think that the best thing that the company can do
is to be honest about what roles are really open
to people from the community and which ones might not be.
And that might not be something
that your company wants to be transparent about,
but I think if you're really trying
to build a community around it,
I do think you have to be transparent about that.
And I think that the people that will stick around
in your community will at least respect that transparency,
even if maybe it's not the answer that they wanted to hear.
So I think there's definitely room for that,
but it will look a little bit different
and you will have to have that balance
between the company and the community.
Hey, thank you, Don.
All we have time for.
Thanks.
Thank you.