I've given a lot of conference talks recently. As part of the PyCon US Maintainers' Summit in May, I delivered an eight-minute talk, "Researching the leadership gap for legacy projects". The video is now available, and here's the written version (I did not use slides).

Contents:

1. Introducing the question/problem
2. A little more about the problem I see
3. Tooling hypothesis
4. Corporate involvement hypothesis (hypotheses)
5. New problems hypothesis
6. Values and culture hypothesis
7. How would we check?

Hi! I'm Sumana Harihareswara of Changeset Consulting and I'm not using any slides today, so you're free to take a few minutes to stretch, fold some laundry, what have you.

Introducing the question/problem

We have a pipeline for getting folks with coding skills to start or contribute to open source projects. That's great and I'm glad.

But I'm pretty sure we don't have a pipeline to recruit or grow contributors with leadership and management skills. A maintainer of a widely-used project *is* a manager, but since skilled managers are scarce in open source, we're seeing important projects stumble, or even wither, for lack of managerial work. (At least, this is what I've seen, and if you are seeing something to the contrary, I want to hear about it.) And I think this is a factor in the open source sustainability problem.

Knowing why this is happening can help us fix it. So in this talk I'll share a few hypotheses: one about the tooling we build and use, one about the effects of corporate involvement, one about changes in the problems we're trying to address, and one about values and culture. And I'll talk about how we would check whether any of these are true. I hope that considering this question will aid your efforts in focusing time and energy on things that will make a difference to project sustainability.

A little more about the problem I see

Founders start projects but are unprepared for the managerial demands of maintaining things that other people depend on. And, when legacy projects stagnate, contributors don't know how to take them over and stabilize them by solving common strategic, team, communication, workflow, and financial problems. Since they don't know how to rehab existing projects, individuals and orgs fork or start new ones, exacerbating fragmentation headaches.

So what hypotheses do we have?

Tooling hypothesis

Here's one. It used to be that, if you were going to run an open source project, you had to make the tooling platform yourself. You had to set up and administer, and maybe even build, your own bug tracker, source code repository, wiki, documentation site, and tarball release repository. Now these are hosted services -- GitHub, Read the Docs, PyPI. That means that it's easier to start a project, but that also means it's easier to start a project without learning a lot about the value and capabilities of these platforms along the way. And then project founders are less equipped to use those things well.

Corporate involvement hypothesis (hypotheses)

Here's another: it changes things when companies get more and more involved in open source, or hire people from open source. Maybe big companies hire the people who have managerial skills, and sometimes take them out of open source work entirely, and leave behind the ones who don't. Or maybe open source would be failing worse without corporate involvement, and corporate engagement is sort of subsidizing the poor management that we would otherwise see.

New problems hypothesis

Here's another: what got us here won't get us there. We're trying to address new or unsolved or undersolved problems and areas in open source -- distributed and cloud computing, getting telemetry while protecting user privacy, user experience design that can stand up to the best that industry can offer, diversity, equity, and inclusion, and so on. So, in general, open source contributors have grown a certain median level of leadership skill, but we're seeing cracks in the infrastructure because of the new loads they are trying to handle.

Values and culture hypothesis

Here's another: Let's talk about our culture and values, and how that affects contributor retention and promotion. We in open source recognize and promote people for the code they write, but we're bad at recognizing and valuing people for the managerial contributions they make -- we treat glue work https://noidea.dog/glue as invisible. So we don't attract or retain people with managerial skills or with the interest in growing in that direction.

And I'd like to thank Amye Scavarda for some thoughts about some of these hypotheses.

How would we check?

So. How would we check whether any of these are right? A few thoughts. We could talk with the scholars who were funded by the Ford and Sloan Foundation grants on critical digital infrastructure to get their thoughts. We could work with the CHAOSS people, the open source metrics working group, to construct a means to quantitatively measure maintainership actions happening within a project, and find out what other attributes it correlates with -- like whether or not those particular projects, or the domain areas they're in, were particularly influenced by companies. We could look for conversations from 15 years ago to check what our forebearers were saying, whether they thought this was likely to be a problem. We could try to offer explicit skills learning opportunities to contributors, to see whether people are interested, and whether we can find ways to retain the people who take those offers as open source maintainers.

My gut says that the source of the problem is a mix of the corporate involvement and values and culture hypotheses. So that's the basis I'm working from. I am working on a book outlining and teaching the skills open source software maintainers need, and teaching these skills to contributors who have never managed public-facing projects before. It'll be a textbook or a self-help guide for new and current maintainers of existing projects (what I call "brownfield projects", as opposed to "greenfield") and will focus on teaching specific project management skills (such as initial project audit, grantwriting, bug triage, and meeting facilitation) in the context of open source. If you go to changeset.nyc, under "resources" you'll find a free sample.

But let's talk during the Q&A session on Thursday. Which, if any, of these hypotheses ring true to you, and how could someone check whether you're right?

Thanks.