[00:00.000 --> 00:10.760]  Here today at Bosdem, I am going to be talking about contributor growth strategies, how to
[00:10.760 --> 00:17.840]  get more contributors for your open source project.
[00:17.840 --> 00:23.080]  Today I'll start by talking about the factors that can impact contributor growth and why
[00:23.080 --> 00:29.480]  it can be so incredibly challenging before moving into some strategies for growing your
[00:29.480 --> 00:34.800]  contributor base using contributor ladders to help people move into leadership positions.
[00:34.800 --> 00:40.240]  And then finally I'll talk about some metrics you can use to measure project sustainability
[00:40.240 --> 00:47.120]  and then we'll look at a few resources and give you some final thoughts.
[00:47.120 --> 00:49.120]  First I'll tell you a teeny tiny bit about me.
[00:49.120 --> 00:55.040]  I've been in the technology industry for well over 20 years working mostly on open
[00:55.040 --> 01:01.520]  source projects from within companies like Intel, Puppet, and now at VMware I'm responsible
[01:01.520 --> 01:06.840]  for our open source community strategy within the open source program office.
[01:06.840 --> 01:11.800]  I'm a board member of Open UK, I'm a governing board member and maintainer for the Linux
[01:11.800 --> 01:17.600]  Foundation's Chaos Metrics project, I'm co-chair of the CNCF contributor strategy technical
[01:17.600 --> 01:24.280]  advisory group and I also have a PhD from the University of Greenwich where I researched
[01:24.280 --> 01:29.400]  how people collaborate within the Linux kernel.
[01:29.400 --> 01:36.840]  Let's start by talking more about why it can be so hard to achieve contributor growth.
[01:36.840 --> 01:42.640]  In this section we'll talk about some of the issues people face that can impact the sustainability
[01:42.640 --> 01:48.200]  of contributions along with the vicious cycle that people often face when trying to balance
[01:48.200 --> 01:55.120]  the time required to maintain the project versus the time to onboard new contributors.
[01:55.120 --> 01:58.920]  The reality is we are not mindless automatons.
[01:58.920 --> 02:05.480]  We have feelings, we have bad days, we have other commitments and personal challenges
[02:05.480 --> 02:10.920]  in our lives that are often invisible to the other contributors within the project and
[02:10.920 --> 02:14.640]  they can get in the way of our contributions to open source projects.
[02:14.640 --> 02:20.800]  We can be squishy, we can be unpredictable and irrational, especially when we're stressed
[02:20.800 --> 02:26.000]  out, when we're overworked, when we're burnt out.
[02:26.000 --> 02:29.680]  But you can't have an open source project without actually having people to maintain
[02:29.680 --> 02:35.160]  it so you need to be able to encourage people to participate in ways that are sustainable
[02:35.160 --> 02:40.640]  not just for the project but also for those people as human beings.
[02:40.640 --> 02:45.240]  Many projects struggle to find people who will actively participate in their projects
[02:45.240 --> 02:48.320]  and continue to participate over the long term.
[02:48.320 --> 02:53.320]  If it was easy you would all have all of the people you needed to maintain your project
[02:53.320 --> 02:58.280]  and I'd be in an empty room and none of you would be watching this talk.
[02:58.280 --> 03:03.040]  But we're in a situation now where there are lots of open source projects and just frankly
[03:03.040 --> 03:05.920]  not enough contributors.
[03:05.920 --> 03:09.800]  Maintainers are burning out and are in desperate need of help.
[03:09.800 --> 03:14.680]  And sometimes it can be really difficult to get people to contribute to your project.
[03:14.680 --> 03:19.760]  And unfortunately there's no magic behind this, there's no one size fits all solution.
[03:19.760 --> 03:24.840]  But throughout this talk I will focus on some things that you can do to increase the chances
[03:24.840 --> 03:32.360]  of successfully building a community and then growing more contributors for your project.
[03:32.360 --> 03:36.440]  Maintaining an open source project is hard work.
[03:36.440 --> 03:40.040]  And it extends out over many years.
[03:40.040 --> 03:43.280]  And maintainer burnout is common within open source projects.
[03:43.280 --> 03:48.720]  Even the really big successful projects like Kubernetes struggle with maintainer burnout
[03:48.720 --> 03:51.360]  and growing the contributor community.
[03:51.360 --> 03:57.080]  It can be hard for already overworked maintainers to balance the day to day work required to
[03:57.080 --> 04:02.080]  keep the project running while also investing in additional activity to increase future
[04:02.080 --> 04:04.280]  community sustainability.
[04:04.280 --> 04:10.240]  So this creates a vicious cycle where maintainers don't have enough time to onboard new contributors
[04:10.240 --> 04:16.360]  leading to fewer contributors which leads back to no time to onboard new contributors.
[04:16.360 --> 04:21.560]  And while it takes a bit more time up front, if you can invest some time in activities
[04:21.560 --> 04:26.760]  that will help onboard new contributors like onboarding documentation for example, you
[04:26.760 --> 04:31.040]  can increase the chances that you can break out of this vicious cycle.
[04:31.040 --> 04:34.760]  Another way to free up some time for maintainers to break out of this cycle is by getting
[04:34.760 --> 04:40.360]  help for different types of contributions that take up valuable time and are required
[04:40.360 --> 04:42.440]  to make an open source project successful.
[04:42.440 --> 04:47.640]  So think about things like documentation, marketing, community management and loads
[04:47.640 --> 04:48.640]  of other things.
[04:48.640 --> 04:54.600]  And for projects with really complex code bases, it can sometimes be a lot easier to
[04:54.600 --> 05:00.280]  onboard people into some of these roles first to help free up some time to onboard other
[05:00.280 --> 05:03.640]  contributors later.
[05:03.640 --> 05:08.160]  Now next up, let's talk about developing and executing on a long term contributor growth
[05:08.160 --> 05:14.160]  strategy including motivation, governance, new contributor onboarding, mentoring and
[05:14.160 --> 05:17.600]  leadership.
[05:17.600 --> 05:22.680]  People's motivations for contributing to your project vary widely.
[05:22.680 --> 05:26.520]  Some people are contributing as part of their job while others might contribute to gain
[05:26.520 --> 05:30.560]  experience or maybe learn more about a particular technology.
[05:30.560 --> 05:36.440]  And you don't really have any control whatsoever over what motivated people to show up.
[05:36.440 --> 05:42.120]  But there are things that you can do to motivate them to stick around regardless of why they
[05:42.120 --> 05:44.160]  showed up in the first place.
[05:44.160 --> 05:49.800]  Clear communication and reducing friction are key to helping people stick around.
[05:49.800 --> 05:55.560]  And I'll talk more in upcoming slides about the importance of explicit and clearly communicated
[05:55.560 --> 06:02.120]  governance along with solid onboarding docs and fostering a welcoming and inclusive community.
[06:02.120 --> 06:06.640]  But there are other things you can do to help motivate people to contribute.
[06:06.640 --> 06:12.640]  Having good first issues or help wanted labels are excellent places to start because these
[06:12.640 --> 06:18.320]  help contributors find something that they can work on while they learn more about the
[06:18.320 --> 06:19.320]  project.
[06:19.320 --> 06:23.800]  So good first issues should be targeted as something very simple that a brand new contributor
[06:23.800 --> 06:29.760]  can just pick up and do in a very quick amount of time.
[06:29.760 --> 06:32.440]  It helps them learn more about the contribution process.
[06:32.440 --> 06:37.240]  And then help wanted labels are for issues that maybe are a little bit more complicated
[06:37.240 --> 06:41.520]  and take a little bit more time so that people who've already started to contribute can find
[06:41.520 --> 06:44.520]  something else to work on next.
[06:44.520 --> 06:49.200]  And good first issues and help wanted labels are passive requests for help, right?
[06:49.200 --> 06:56.160]  But I also encourage maintainers to be proactive and specific about ways that people can help.
[06:56.160 --> 07:02.440]  Asking someone specific to review a PR or maybe answer a question in Slack or some other
[07:02.440 --> 07:09.040]  forum from a user demonstrates that you recognize their expertise and that you want their help
[07:09.040 --> 07:10.600]  specifically.
[07:10.600 --> 07:16.080]  And going back to the discussion about squishy humans, knowing that we're appreciated makes
[07:16.080 --> 07:18.200]  us feel good, right?
[07:18.200 --> 07:23.360]  Which can be a strong motivator to participate in an open source project.
[07:23.360 --> 07:25.640]  Now I know a lot of people like to really hate on governance.
[07:25.640 --> 07:29.640]  It's just paperwork, it's busy work, nobody likes it, it's just gets in the way of doing
[07:29.640 --> 07:31.720]  the real work on the project.
[07:31.720 --> 07:35.200]  But this really isn't true of good governance.
[07:35.200 --> 07:40.040]  And good governance is really about setting expectations and getting all of the people
[07:40.040 --> 07:42.600]  in the community collaborating together.
[07:42.600 --> 07:47.520]  And ultimately the focus of open source project governance is on people.
[07:47.520 --> 07:52.800]  The roles we play, our responsibilities, how we make decisions, and what we should expect
[07:52.800 --> 07:57.160]  from each other as participating in the community.
[07:57.160 --> 08:02.040]  The goal should be to make the processes for participation as obvious as possible.
[08:02.040 --> 08:04.320]  Even for people who are brand new to the community.
[08:04.320 --> 08:09.280]  So having clear rules about how collaboration occurs, how decisions are made, and what types
[08:09.280 --> 08:15.400]  of contributions are in or out of scope really helps community members make contributions
[08:15.400 --> 08:19.000]  that are likely to be accepted and embraced by the project.
[08:19.000 --> 08:24.440]  This helps avoid wasting maintainers' time for contributions that just aren't aligned
[08:24.440 --> 08:26.200]  with the project at all.
[08:26.200 --> 08:29.880]  And a healthy project with clear governance makes contributors happy and helps set the
[08:29.880 --> 08:34.920]  project up for success and future growth.
[08:34.920 --> 08:40.440]  Now another aspect of governance is about making it easier for people to move into positions
[08:40.440 --> 08:44.880]  of increasing responsibility to help reduce the load on existing maintainers.
[08:44.880 --> 08:49.840]  We'll talk more about this later in the section about contributor ladders and leadership.
[08:49.840 --> 08:53.160]  But the good news is you don't have to start from scratch, right?
[08:53.160 --> 08:58.640]  We have some good templates with instructions that we've developed at the CNCF.
[08:58.640 --> 09:03.280]  But they apply to most projects so they can help you sort of quickly and easily build
[09:03.280 --> 09:07.480]  out some really basic governance for your project.
[09:07.480 --> 09:10.960]  Now I suspect that some of you are still thinking that you really don't need to spend time on
[09:10.960 --> 09:11.960]  governance.
[09:11.960 --> 09:16.400]  But think about this from the perspective of the new contributor.
[09:16.400 --> 09:21.720]  It's a lot more difficult to participate in a project or participate in a community if
[09:21.720 --> 09:26.120]  you don't know anything about the role that you might play, the expectations, the key
[09:26.120 --> 09:29.120]  players, or the roles for participating.
[09:29.120 --> 09:35.840]  So explicit documented governance gives new and existing contributors a clear path to
[09:35.840 --> 09:37.840]  guide them through your project.
[09:37.840 --> 09:43.000]  And spending a bit of time, you don't spend a lot but just a bit of time documenting governance
[09:43.000 --> 09:49.280]  up front can help save you time later with fewer questions about how things work.
[09:49.280 --> 09:53.840]  And it gives you a document that you can point people to if they have questions.
[09:53.840 --> 09:58.120]  Now when I start contributing to a new open source project, I want to know how decisions
[09:58.120 --> 10:03.760]  are made and who makes those decisions which helps me understand whether decisions are likely
[10:03.760 --> 10:08.720]  to be made fairly by people with the expertise to make those decisions.
[10:08.720 --> 10:13.160]  And I also want to see a clear path into leadership for me or for my colleagues if we decide to
[10:13.160 --> 10:16.080]  stick around in the project over the long term.
[10:16.080 --> 10:20.000]  But the bottom line is that if the process for collaboration and decision making are
[10:20.000 --> 10:25.820]  not clearly documented as part of the project governance, this introduces a lot of uncertainty
[10:25.820 --> 10:30.540]  and increases the barrier to contribution while also jeopardizing the long term health
[10:30.540 --> 10:34.300]  and viability of the project.
[10:34.300 --> 10:42.500]  I see so many open source projects with contributing guides that don't actually provide any useful
[10:42.500 --> 10:45.380]  information about contributing to the project.
[10:45.380 --> 10:50.860]  At a minimum, a new contributor needs to understand how to spin up an environment where they can
[10:50.860 --> 10:57.660]  do their development, the expectations for testing and how to run those tests, any processes
[10:57.660 --> 11:02.500]  or expectations you have around things like pull requests or issues, and instructions
[11:02.500 --> 11:07.180]  for other requirements like maybe they need to sign a CLA or sign their commits using
[11:07.180 --> 11:09.300]  the DCO process.
[11:09.300 --> 11:14.260]  Now if this is well documented, contributors can get started with a minimal amount of help
[11:14.260 --> 11:19.860]  from existing maintainers which can save you a lot of time in the long run.
[11:19.860 --> 11:24.300]  And when a project doesn't have good onboarding docs, maintainers can get frustrated by the
[11:24.300 --> 11:29.980]  amount of time they spend on new contributor questions and it can make it hard for contributors
[11:29.980 --> 11:33.740]  to feel welcome and take them longer to become productive.
[11:33.740 --> 11:37.580]  Now this does not mean that you need to spend days and days and weeks and weeks writing
[11:37.580 --> 11:42.220]  the perfect onboarding documentation for your project.
[11:42.220 --> 11:44.620]  Anything is better than nothing.
[11:44.620 --> 11:49.780]  And if you just start with a few things that can help people get started quickly, new contributors
[11:49.780 --> 11:54.740]  can actually help make the onboarding documents better by adding more details and additional
[11:54.740 --> 12:01.300]  instructions for things that they found confusing or that they had struggled with.
[12:01.300 --> 12:06.180]  Your project should also be designed to keep diversity, equity and inclusion top of mind.
[12:06.180 --> 12:10.740]  Building a diverse community where people feel welcome and included doesn't just happen,
[12:10.740 --> 12:17.060]  it does require putting at least some thought into it, but it's really time well spent.
[12:17.060 --> 12:21.820]  Building an environment where everyone, including people from marginalized populations feels
[12:21.820 --> 12:27.300]  safe is the first step toward building a diverse community for your project.
[12:27.300 --> 12:32.580]  Ideally having programs that give people opportunities for things like shadowing, mentoring, sponsoring
[12:32.580 --> 12:37.580]  new potential leaders can help you grow a diverse set of people into new leadership within
[12:37.580 --> 12:39.300]  your project.
[12:39.300 --> 12:43.460]  The Kubernetes contributor experience SIG is a great place to see some examples of how
[12:43.460 --> 12:48.260]  to implement some of these programs for things like shadowing and mentoring, and projects
[12:48.260 --> 12:54.820]  that make a concerted effort to bring in new people from a variety of backgrounds and have
[12:54.820 --> 12:59.140]  programs in place to help them grow into leadership positions are more likely to benefit from
[12:59.140 --> 13:03.620]  increased innovation and just have a healthier contributor community.
[13:03.620 --> 13:08.300]  And by having a diverse and welcoming community, you have the advantage of getting contributors
[13:08.300 --> 13:12.780]  that might not feel welcome in other projects.
[13:12.780 --> 13:16.900]  Now this, I gave it its own section, but it's really still kind of part of the strategies
[13:16.900 --> 13:21.860]  section, but it's important enough to call out separately since moving people into leadership
[13:21.860 --> 13:27.940]  positions really is a key part of growing your contributor base and scaling your project.
[13:27.940 --> 13:31.500]  So I'll talk about this in the context of contributor ladders, which is a good way to
[13:31.500 --> 13:34.580]  do this.
[13:34.580 --> 13:40.060]  Defining the roles and responsibilities for contributors, reviewers, maintainers can help
[13:40.060 --> 13:42.940]  with recruiting new people into these roles.
[13:42.940 --> 13:47.260]  It can help to really think of this as a ladder where contributors can climb up to become
[13:47.260 --> 13:51.220]  reviewers and those reviewers can become maintainers.
[13:51.220 --> 13:55.780]  And what's important is to document it and make sure that people understand how they
[13:55.780 --> 14:04.060]  can climb this ladder and move into positions with more responsibility within the project.
[14:04.060 --> 14:08.180]  A contributor ladder usually outlines the different roles within the project, along
[14:08.180 --> 14:12.060]  with responsibilities and privileges that come with them.
[14:12.060 --> 14:17.980]  Community members generally start at the first levels of the ladder and then they advance
[14:17.980 --> 14:20.600]  up as their involvement in the project grows.
[14:20.600 --> 14:24.540]  So for each one of the ladder, you can define responsibilities, which are the things that
[14:24.540 --> 14:28.700]  a contributor is expected to do.
[14:28.700 --> 14:33.700]  Requirements are the qualifications that a person needs to be put in that role.
[14:33.700 --> 14:37.580]  And then privileges are maybe some things that those contributors are entitled to do
[14:37.780 --> 14:39.780]  as a part of that position.
[14:39.780 --> 14:44.620]  And all of this helps set expectations for roles and encourages people to think about
[14:44.620 --> 14:50.340]  how they might take on additional responsibilities within the project.
[14:50.340 --> 14:54.780]  And as you get more people moving into maintainer roles, you can reduce the load of the existing
[14:54.780 --> 14:55.780]  maintainers.
[14:55.780 --> 15:01.420]  Now, the good news is that there is, like with many things, also a template, so you
[15:01.420 --> 15:02.860]  can avoid building this from scratch.
[15:02.860 --> 15:07.180]  Now, this template has probably more roles than most projects need, but it's intended
[15:07.220 --> 15:12.180]  to be simplified and customized for your project.
[15:12.180 --> 15:17.260]  Project leadership is one of the key elements of good governance, and this is how you scale
[15:17.260 --> 15:18.940]  your project.
[15:18.940 --> 15:22.060]  So you should have some kind of documentation about your leadership.
[15:22.060 --> 15:25.460]  For small projects, maybe you just have a list of maintainers that indicates which people
[15:25.460 --> 15:28.660]  are responsible for which things.
[15:28.660 --> 15:32.500]  And there are quite a few different options for selecting leaders as part of defining
[15:32.500 --> 15:33.980]  your governance.
[15:33.980 --> 15:39.420]  And the ideal is to have a process that provides a fair and level playing field that defines
[15:39.420 --> 15:42.340]  how contributors can become leaders.
[15:42.340 --> 15:48.140]  And this should be documented so that all participants can clearly understand the criteria
[15:48.140 --> 15:51.060]  and the process for moving into leadership positions.
[15:51.060 --> 15:56.020]  Now, some of the bigger projects, like Kubernetes, for example, have an election process, at
[15:56.020 --> 16:01.140]  least for the top levels of leadership, like a steering committee.
[16:01.180 --> 16:05.940]  But only the biggest projects actually need something that complicated.
[16:05.940 --> 16:10.620]  Most projects have a relatively simple process, where the existing leaders or existing maintainers
[16:10.620 --> 16:12.580]  get to select the new ones.
[16:12.580 --> 16:17.340]  So for example, new maintainers are often nominated by existing maintainers and maybe
[16:17.340 --> 16:22.300]  approved after a certain number of maintainers have agreed to it, or maybe there's a voting
[16:22.300 --> 16:23.860]  process.
[16:23.860 --> 16:27.820]  And there are loads of different options for selecting leaders for a project, so I won't
[16:27.860 --> 16:33.020]  go into all of them, but there is a, I wrote a document for the CNCF that kind of describes
[16:33.020 --> 16:35.140]  some different options.
[16:35.140 --> 16:40.020]  But the key is to spend some time thinking about this as you document your governance
[16:40.020 --> 16:44.460]  and as you build your contributor ladder, so that you can bring new people into leadership
[16:44.460 --> 16:49.300]  positions and reduce the load on the existing maintainers to help scale your project by
[16:49.300 --> 16:51.460]  growing your contributor base.
[16:51.460 --> 16:57.660]  Now, granted, mentoring takes a bit more time, but it's a good way to help existing
[16:57.700 --> 17:02.940]  contributors become even better, with an eye toward moving them into leadership positions.
[17:02.940 --> 17:07.420]  So for busy maintainers, one good approach is to focus on mentoring people who've already
[17:07.420 --> 17:14.420]  been around a while and are unlikely to disappear and help them learn to do maybe some more
[17:14.980 --> 17:17.820]  complex time consuming tasks.
[17:17.820 --> 17:22.700]  Like with many things, mentoring isn't something that's all or nothing, and you can time box
[17:22.700 --> 17:26.700]  it to whatever time you can fit in your schedule, so this doesn't have to be hours and hours
[17:27.100 --> 17:28.740]  every week.
[17:28.740 --> 17:34.020]  Even spending an hour a month or an hour a week to help someone quickly become productive
[17:34.020 --> 17:38.980]  in some part of your project can be time well spent if that person can then take on a few
[17:38.980 --> 17:43.180]  tasks that help you reduce your load as a maintainer.
[17:43.180 --> 17:48.380]  You can even structure this as shadowing and allow them to watch you and learn while
[17:48.380 --> 17:52.380]  you do some maintainer tasks that you're going to do anyways.
[17:52.380 --> 17:55.860]  And if you focus this on helping someone learn to do something that can free up your time
[17:55.900 --> 18:00.100]  later, then this will be time well spent.
[18:00.100 --> 18:05.420]  Now the strategic part of all of this comes in to thinking about where your time would
[18:05.420 --> 18:07.620]  be best spent.
[18:07.620 --> 18:12.660]  I've given a lot of suggestions so far in this presentation, and you should not try
[18:12.660 --> 18:15.220]  to do everything at once, right?
[18:15.220 --> 18:18.420]  So I recommend you think strategically about where you start.
[18:18.420 --> 18:22.260]  If you know you've had people interested in contributing, but they've given up when they
[18:22.300 --> 18:27.500]  couldn't get started, then maybe you focus on onboarding docs.
[18:27.500 --> 18:33.100]  If you have a lot of casual contributors who come around occasionally and contribute things,
[18:33.100 --> 18:37.180]  maybe you focus on the contributor ladder and governance to help some of them move up
[18:37.180 --> 18:42.180]  to take on more responsibility and eventually move into leadership positions.
[18:42.180 --> 18:47.180]  One way to figure out the best place to start is by using metrics.
[18:48.180 --> 18:52.180]  So I'm a big fan of metrics and data for those who know me.
[18:52.180 --> 18:57.180]  But this can help you find problem areas and figure out where you should be spending your time.
[18:57.180 --> 18:59.180]  Time is precious, right?
[18:59.180 --> 19:04.180]  So it's important to identify problem areas so that you can focus on the right things
[19:04.180 --> 19:10.180]  while avoiding wasting time on things that maybe are already going okay or going really well.
[19:10.180 --> 19:15.180]  However, metrics do need to be interpreted in light of how you operate as a community
[19:15.180 --> 19:18.180]  and the other things happening in your project.
[19:18.180 --> 19:22.180]  And there's no one-size-fits-all interpretation for metrics.
[19:22.180 --> 19:29.180]  But I will talk in this section about what some trends might indicate and how you can think about addressing them.
[19:29.180 --> 19:33.180]  One key area to look at for your project is responsiveness.
[19:33.180 --> 19:39.180]  So in this project, in this graph, you can see that there are times when they have a lot of PRs
[19:39.180 --> 19:42.180]  in the backlog that need to be merged or closed.
[19:42.180 --> 19:47.180]  Now, if these PRs are coming from several regular contributors who aren't maintainers,
[19:47.180 --> 19:51.180]  maybe it's a good time to look at how you can promote some of those contributors
[19:51.180 --> 19:56.180]  to become maybe reviewers, approvers, maintainers to help with the workload.
[19:56.180 --> 19:59.180]  Now, as with any metrics, you need to interpret them in light of your project.
[19:59.180 --> 20:02.180]  So there are other things that can cause an increase in the backlog,
[20:02.180 --> 20:08.180]  like everyone preparing for a big release or maybe there's a big conference coming up
[20:08.180 --> 20:13.180]  or it's vacation season in Europe that just are not resolved by moving people into leadership roles.
[20:13.180 --> 20:19.180]  So you have to think about maybe why you have this backlog and what might help resolve it.
[20:19.180 --> 20:23.180]  It can also help to look at the types of contributors that you have.
[20:23.180 --> 20:26.180]  So in this case, casual contributors are those drive-through contributors
[20:26.180 --> 20:30.180]  who make just a handful of contributions and then you never see them again.
[20:30.180 --> 20:35.180]  Regular contributors are the ones that make some contributions and stick around.
[20:35.180 --> 20:40.180]  So they continue to make some contributions but maybe not a ton of contributions.
[20:40.180 --> 20:44.180]  And then core contributors are usually the maintainers who make most of the contributions
[20:44.180 --> 20:47.180]  and stick around over the long term.
[20:47.180 --> 20:51.180]  Now, you can really learn a lot from this graph, actually.
[20:51.180 --> 20:55.180]  If you have a very small number of casual and regular contributors,
[20:55.180 --> 21:00.180]  this can mean that people don't have the information needed to become productive and contribute.
[21:00.180 --> 21:04.180]  So in some cases, onboarding docs can help solve this issue.
[21:04.180 --> 21:08.180]  Another thing that this graph can indicate is whether maybe you have some fundamental issues
[21:08.180 --> 21:11.180]  within your project that are driving people away.
[21:11.180 --> 21:17.180]  So if you see the total number of contributors declining or the number of regular contributors declining,
[21:17.180 --> 21:23.180]  this can indicate some deeper issues, maybe with toxic community members or an unwelcoming environment
[21:23.180 --> 21:29.180]  that probably needs to be resolved before you take any other actions to grow the community.
[21:29.180 --> 21:33.180]  Or it could mean people are leaving your community for some other reasons.
[21:33.180 --> 21:37.180]  You know, maybe lack of responsiveness is another one.
[21:37.180 --> 21:42.180]  Now, this metric is often called the bus factor, pony factor, lottery factor.
[21:42.180 --> 21:48.180]  Based on the idea that if one person or a small number of people disappeared,
[21:48.180 --> 21:54.180]  maybe after winning the lottery, that the project would possibly be completely screwed
[21:54.180 --> 21:57.180]  because they're making all of the contributions.
[21:57.180 --> 22:02.180]  So I recommend measuring this because there are a couple of things that can tell you.
[22:02.180 --> 22:08.180]  So first of all, it tells you how big of an issue this is for your current contributor situation.
[22:08.180 --> 22:13.180]  If it's like this one, this is a big issue and you should focus on getting some more contributors
[22:13.180 --> 22:16.180]  that can be moved into leadership roles.
[22:16.180 --> 22:20.180]  You might also find that there are people contributing more than you realized,
[22:20.180 --> 22:22.180]  which is the other reason that this is a good metric.
[22:22.180 --> 22:26.180]  This can help you think about who you can encourage to contribute more
[22:26.180 --> 22:30.180]  and maybe find someone who could move up the ladder into a leadership role
[22:30.180 --> 22:36.180]  and reaching out to someone and acknowledging their work while encouraging them to do a bit more
[22:36.180 --> 22:39.180]  can help quite a bit with contributor growth.
[22:39.180 --> 22:42.180]  Sometimes people just need a bit of encouragement.
[22:42.180 --> 22:46.180]  And as I mentioned earlier, you can ask people for specific things that you know they're good at.
[22:46.180 --> 22:51.180]  There are several communities that I've gotten more involved in or involved in in the first place
[22:51.180 --> 22:58.180]  because someone asked for my specific help and kind of made me feel wanted within that community.
[22:58.180 --> 23:03.180]  Now before I wrap up this talk, I'm going to leave you with a few resources that you might find useful.
[23:03.180 --> 23:08.180]  I've mentioned the CNCF contributor strategy technical advisory group a couple of times.
[23:08.180 --> 23:12.180]  We have a governance working group and a contributor growth working group,
[23:12.180 --> 23:17.180]  which provide templates and guidance about contributor experience, sustainability, governance,
[23:17.180 --> 23:22.180]  that sort of thing to help people develop strategies for maintaining healthy projects.
[23:22.180 --> 23:30.180]  The resources are designed for CNCF projects, but most of what we talk about applies just about any open source project.
[23:30.180 --> 23:38.180]  The open source way guidebook has loads of really great details about building and maintaining open source projects.
[23:38.180 --> 23:45.180]  The chaos project has loads of metric definitions and software, which you could see in my metric slides,
[23:45.180 --> 23:48.180]  that you can use to measure the health of your open source community.
[23:48.180 --> 23:53.180]  These are all great starting places for understanding how to grow your contributor community.
[23:53.180 --> 24:00.180]  I just mentioned the contributor strategy tag on the resources slide, but I wanted to put in a really quick recruiting plug.
[24:00.180 --> 24:06.180]  Like with most open source projects, we're also looking for help. We don't have enough people to contribute.
[24:06.180 --> 24:13.180]  Anyone's welcome to join our meetings if you want to learn about us or even better if you're passionate about contributor growth,
[24:13.180 --> 24:18.180]  governance or related topics and want to help CNCF projects improve in those areas.
[24:18.180 --> 24:23.180]  We'd love to have you join us and help us develop resources and provide advice to projects.
[24:23.180 --> 24:27.180]  This slide has several ways to find us and get involved.
[24:27.180 --> 24:31.180]  With that said, let me leave you with just a few final thoughts.
[24:31.180 --> 24:41.180]  Maintaining an open source project is so much work and there are so many maintainers who are overworked, exhausted, burning out.
[24:41.180 --> 24:47.180]  The best way to address this challenge is by growing your contributor base, but it's hard work.
[24:47.180 --> 24:56.180]  It takes time away from the day-to-day activities now, which can be really hard to justify when you feel like you're barely keeping up as it is.
[24:56.180 --> 25:06.180]  But 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 in the long run.
[25:06.180 --> 25:12.180]  And hopefully some of the templates and resources that I've provided will help you get started with some of this work.
[25:12.180 --> 25:15.180]  And as I've mentioned before, you don't need to do everything at once.
[25:15.180 --> 25:22.180]  Spending just a little time on something to grow your contributor base is a great way to start.
[25:22.180 --> 25:26.180]  Thank you for coming to my talk and we can open it up for questions.
[25:26.180 --> 25:34.180]  That was very easy.
[25:34.180 --> 25:36.180]  Thank you, Don.
[25:36.180 --> 25:38.180]  I have a question about the lottery factor.
[25:38.180 --> 25:50.180]  Do you have any advice on how to measure or how to take into account quality, not just enumerating the quantity of commits that various contributors make?
[25:51.180 --> 25:56.180]  So the question is how to take into account quality versus quantity?
[25:56.180 --> 26:02.180]  Yeah, I think that that's something you have to...
[26:02.180 --> 26:08.180]  So you're not going to be able to measure the quality really well instead of a quantitative way, right?
[26:08.180 --> 26:11.180]  But I think it's something, again, it gets at interpretation.
[26:11.180 --> 26:15.180]  So I think it's something that you need to really think about.
[26:15.180 --> 26:20.180]  So there might be somebody that has loads of commits for some particular reason,
[26:20.180 --> 26:25.180]  but maybe they're not a major contributor to the project for some other reason.
[26:25.180 --> 26:30.180]  Maybe they're not a maintainer and maybe it wouldn't be a big deal if they left tomorrow.
[26:30.180 --> 26:35.180]  Maybe they're working on something that's fairly niche that not a lot of people use, for example.
[26:35.180 --> 26:40.180]  So I think you really do need to interpret those graphs.
[26:40.180 --> 26:43.180]  And you can think about the quality of what someone does.
[26:43.180 --> 26:46.180]  If that's someone who makes a ton of commits and they're kind of crap,
[26:46.180 --> 26:51.180]  then that's not as important as someone who makes a lot of commits that are really great.
[26:51.180 --> 26:55.180]  So you just need to, I think, apply a reality filter on top of it.
[26:55.180 --> 26:59.180]  But I don't think it's something that you can really easily measure quantitatively,
[26:59.180 --> 27:05.180]  but you need to just think about and kind of put a qualitative filter on top of it.
[27:05.180 --> 27:08.180]  Yeah, other questions?
[27:14.180 --> 27:19.180]  Hi.
[27:19.180 --> 27:22.180]  First off, great talk.
[27:22.180 --> 27:26.180]  I had a question about the governance side,
[27:26.180 --> 27:30.180]  because I work on a pretty big open source project,
[27:30.180 --> 27:33.180]  but the problem there is that it's owned by a company
[27:33.180 --> 27:41.180]  that doesn't really necessarily value open sources like one of their core reasons why they do it.
[27:42.180 --> 27:47.180]  Do you have any recommendations for how to advocate for governance
[27:47.180 --> 27:51.180]  in the open source project or company owned projects?
[27:51.180 --> 27:55.180]  Yeah, it's really hard to advocate for governance in company owned projects.
[27:55.180 --> 28:00.180]  I've tried to do it and failed in certain projects in the past.
[28:00.180 --> 28:04.180]  What I've found is usually the best way to approach it
[28:04.180 --> 28:08.180]  is to get them to document the way things work now.
[28:08.180 --> 28:11.180]  So not worry about changing all of the governance,
[28:11.180 --> 28:16.180]  not worry about coming up with some big elaborate governance structure,
[28:16.180 --> 28:19.180]  but how do people get moved into committed roles now?
[28:19.180 --> 28:21.180]  How do they get moved up?
[28:21.180 --> 28:23.180]  And try to encourage companies,
[28:23.180 --> 28:27.180]  and this is something I have this discussion internally with NVMware all the time too,
[28:27.180 --> 28:30.180]  is we hire people to work on certain open source projects,
[28:30.180 --> 28:34.180]  and so they get committer status kind of automatically,
[28:34.180 --> 28:38.180]  and we should be as transparent as possible about that in our governance materials,
[28:38.180 --> 28:44.180]  for example, that they do get special treatment as of the fact that it's a NVMware open source project,
[28:44.180 --> 28:49.180]  and we're paying them to do the work, so they're going to be able to commit from day one.
[28:49.180 --> 28:53.180]  So I think being transparent about that as transparent as possible can help,
[28:53.180 --> 28:56.180]  but I would say work with them to document what they have right now,
[28:56.180 --> 29:01.180]  and then maybe people will start to see the gaps and you can try to build on it,
[29:01.180 --> 29:07.180]  but it's hard, it's really hard to get good governance for company and projects.
[29:07.180 --> 29:09.180]  It's a tough problem.
[29:15.180 --> 29:16.180]  Thanks for your talk.
[29:16.180 --> 29:21.180]  About the lottery factor, I'm not sure if you mentioned it or anything,