Initial thoughts about Critical Human Infrastructure.

A couple weeks ago I appeared on the excellent Open Source Stories podcast with the MOST excellent Julia Ferraioli. The theme of the podcast was Critical Human Infrastructure.

Then, Last week, I wrote a blog post to tell the world "I Am Ready For My Next Role." In the blog post, I said "I want to work with people who care about Critical Human Infrastructure."

Because I've just started using the term in relation to open source, I want to give people a better sense of what I'm talking about. To do that, I need start by talking about Critical Digital Infrastructure.

Open source software and Critical Digital Infrastructure.  

The phrase Critical Digital Infrastructure has grown in popularity over the past few years, thanks in no small part due to the funding of research by several large philanthropic organizations such as the Ford Foundation, the Sloan Foundation, Mozilla, Omidyar Network, Open Society Foundations, and others. (Disclaimer: I was a grant recipient in the last round of funding, but that's not why I'm writing this today.) Open source software is everywhere, and some - but not ALL - of that software is Critical Digital Infrastructure. For several years now, we've been talking collectively about how to define the boundary between open source software that is Critical Digital Infrastructure, and other open source software that is widely used or important, but not quite Critical. (cf. this research from Stanford PACS).

This exploration into Critical Digital Infrastructure has spawned or renewed many other relevant conversations. What role does public funding play in sustaining open source? What do we do about the open source supply chain? What, if anything, do we do about open source projects with only one maintainer? (More on that in another blog post.) These conversations are all important, and I'm glad we're having them.

But the longer these conversations go on, the more I find myself worrying that we're missing the bigger picture. We are very focused on trying to figure out which software projects we need to fund and secure. We want to ensure that the projects are "sustainably developed" and that they have "good best practices." But we talk about these things in the abstract, often without open source maintainers in the room. Who, exactly, do we think will develop these projects sustainably? Who will implement these best practices? Who struggles when we say a project is "struggling?"

It's people all the way down.

Projects don't implement best practices. Projects don't sustainably develop themselves. Projects certainly don't fund themselves. People do these things. Humans do these things. Projects don't struggle or burn out. Humans do. Every time we talk about a project that has challenges without also talking about the Humans who are facing those challenges, we are forgetting that Open Source Is People. This is a problem that first started to bother as I was developing Indeed's open source funding strategy.

In 2021, I led the Indeed's implementation of GitHub Sponsors for Companies. We already had the FOSS Contributor Fund to help us find and fund open source projects that were important to Indeed. But there was something missing from this program. I kept coming across individual contributors who were heavily involved across a wide range of projects within language ecosystems. Weren't these humans just as important to Indeed as the open source projects to which they were contributing? With this thought in mind, I focused our GitHub Sponsors engagement on sponsoring People rather than Projects.

The more I sit with this approach, the more it makes sense to me. We can collectively sponsor Projects for years and years, but if we aren't also thinking about the People behind those projects, we will perpetuate the sustainability problems in those projects as well. I began using the phrase Critical Human Infrastructure to try and steer some of the conversation back to the human needs of our open source maintainers.

You cannot claim to care about open source without also caring about humans.

If you are paying attention to the open source software that you use, you can probably think of at least one recent occasion where a maintainer abruptly quit the project. Some of these maintainers quit open source entirely, never to return.

When this happens, do we spend our time and energy trying to support the project, or trying to support the human? Typically, we're more concerned about the health of the project, because if the project isn't healthy, our own projects will also become unhealthy. And even then, we generally only worry about project health until it's "handled." How often to we check in on the former maintainer to see how they are doing?

There is a limited supply of maintainers. Every time a maintainer quits open source because of unhealthy conditions, that limited supply gets smaller. Yes, someone with the right disposition can learn the right skills to be an effective maintainer. But this takes time, willingness, and experience. If the unhealthy conditions don't change, we haven't fixed the problem. The new maintainer will quit, and now our limited supply grows even smaller.

Project Health cannot be separated from Maintainer Health. You cannot claim to care about open source without also caring about humans.

Critical Human Infrastructure just means caring about Humans too.

Humans are hard at work keeping our Critical Digital Infrastructure from falling over. If we tend to our Digital Infrastructure, but don't tend to our Human Infrastructure, we have failed, and our Digital Infrastructure is doomed to failure. If your sustainability program only supports projects, you have a Human-shaped-hole in your program design.

Next time, I'll talk about some ways that we can fix it.