How should we think about trust when it comes to adding new maintainers to a project? Another way of saying that is: if I'm an existing project maintainer, considering whether to entrust you with co-maintainership, what kind of trust am I placing in you?

It's worth thinking about this beyond the obvious.

It's fairly easy to think in terms of the absence of big negatives: "I trust you won't deliberately add malware to the codebase" and "I trust you won't irrevocably obliterate something valuable". But to get better at sustainability in open source, we need to get better at recruiting and training new leaders, and at delegating power. And it's easier to do that when we can state what attributes we're positively looking for, including subtle ones.

So:

1. What is this like? Comparing this promotion to four other trust decisions helps us think about:
2. How can we assess trustworthiness? Ideas for steps you could take.
3. Can you reduce how much trust you need to give? Mitigate how much harm they could do.
4. What if you don't have time? Three options.

1: What is this like?

Trust isn't just one continuous linear hierarchy, as I've explained before. I might trust Batman to save my life but not to tell me the truth. When I'm thinking about what forms of trust we put in open source maintainers, I find it helpful to jog my intuitions with imperfect analogies. As a project leader delegating trust, I'm like:

A policymaker trusting a staffer to craft the language of a bill, or a legislature delegating the task of writing regulations to an administrative agency. The specific details of a law, and regulations ("administrative law") developed by those implementing it, are crucial to what effects it has. A staffer or an administrative agency could, accidentally or deliberately, insert subtle yet vital changes. They could increase, or reduce, how well regulators actually carry out the intended policy goal.

A business owner hiring a new store manager. The new manager will have to make on-the-spot decisions to manage shared resources and to keep the day-to-day work ticking along. So the store manager needs to trust them to notice and address new situations, communicate and listen well, and make and meet commitments. They also need to appropriately choose what kinds of decisions require the owner's input, what they should decide themselves but tell the owner about afterwards, and what decisions don't require notification. How they treat customers, staff, vendors, neighbors, inspectors, and others who interact with us could enhance or damage the business's reputation. And, since a store manager often hires staff, the owner's transitively trusting those staff, and the store manager needs to exercise good judgment in hiring and managing them.

A Meals On Wheels organizer onboarding a volunteer or staffer. Meal delivery volunteers each get the names and home addresses of a few senior citizens who have trouble leaving their homes, and often become trusted people in their lives. Because those people are particularly vulnerable to abuse, Meals On Wheels has "a vetting process for volunteers.... You may be asked to undergo a background check process prior to delivering meals if your local program assigns you to a route unaccompanied by a more experienced volunteer or staff member."

The staffers who organize deliveries and prepare the meals also have significant scope for care or abuse, since they need to ensure the safety and nutrition of the food, and steward all the confidential client data. And all members trust each other to share the same ethics and be acting towards the same mission, and to make on-the-spot decisions in accordance with those ethics and that mission.

A person moving in with a romantic partner, or marrying them, or co-parenting a child. If I do one of these things, I'm simultaneously escalating how much we're committed to each other, how much of my well-being (and my child's) they are potentially responsible for, and how much intimacy and vulnerability is possible between us. Many of the dimensions of trust I've described for other roles apply; for instance, I'm trusting them to implement my or our decisions to carry out our intentions, notice and address new situations appropriately, communicate and listen well, negotiate shared decisionmaking and responsibilities with me, and steward confidential information.

But I'm also likely trying to engage in a nonhierarchical relationship where I share equal power with the other person. I may be trusting this person to influence my sense of self, and to provide casual input on my work, hobbies, friendships, and influence on the world. And I'm likely developing a relationship informally and without any written policies, and in a setting without workplace norms about decorum, and that carries additional trust. I trust that they'll take criticism productively and not sulk or lash out, and that they'll speak up about problems that need solving but without sideswiping me in the process. I trust that they'll notice if I'm going through a rough time and proactively offer to temporarily pick up leadership, and some of my shared chores.

And I trust that, if they decide to change or dissolve their relationship with me, they will do so respectfully and carefully, minimizing harm to me and to the people who depend on us.

These analogies have correspondences to bad things new co-maintainers could do, such as hurt downstream users through negligence or malice, harass contributors, damage the project's reputation and yours, betray the project's ethical values, annoy or demoralize you, and transitively trust the wrong people to comaintain. I hope I've also demonstrated some correspondences to good things they could do, such as thoughtfully notice and take opportunities for the project to get better and do more in ways you hadn't considered, enhance the project's reputation, and take care of more people, including you.

2: How can we assess trustworthiness?

How can we decide whether someone is worthy of our trust? Thinking about the analogies above can help us develop criteria, and ideas for intake processes. This isn't a checklist -- it's meant to help you think about what bits might work for you.

You may be familiar with intake processes at businesses, governments, or other organizations that hire people, or at nonprofits that are concerned about what volunteers could do that might hurt others. Even if they don't require candidates to initiate formal applications, they can still gather information. They can ask the candidate for a written summary of their relevant experience (often in the form of a curriculum vitae or résumé), speak with the candidate in an interview, check the candidate's references, pay for a background check on the candidate, or ask the candidate to do work sample tasks.

Often those processes emphasize checking the candidate's skill level. But some intake processes concentrate quite a lot on checking for trustworthiness, including the candidate's capacity to be a responsible colleague, share core ethical values with the existing group, and take criticism well.

In romantic dating, we often get advice to try lower-stakes activities with a partner before escalating commitment, to test their character and compatibility. We might try playing a game together. In institutional settings, the idea of playing a game with a candidate can seem frivolous, or even exclusionary if it's a snobbish test of whether the candidate is already familiar with the gatekeepers' cultural practices. But a well-chosen game, set up right, can be like a work sample task where part of the work is live collaboration.

Another common practice is to try low-stakes responsibilities together. We might travel together before moving in together, or co-own a pet before parenting a child, to gather data on each other's reliability and kindness.

In open source, you could try running an event together, co-presenting a conference talk, or delegating responsibility for a particular component of the release infrastructure. You can notice how the candidate reacts to boredom, criticism, vetoes, and unexpected opportunities. This helps you find patterns and assess the candidate's actions for trustworthiness.

Consider the suggestions in Jacob Kaplan-Moss's "How to build trust" list for managers, and reflect on whether you notice the candidate doing these things:

• Act consistently
• Communicate clearly and transparently
• Be reliable
• Set and respect boundaries
• Use role power rarely – but when you do, don’t be coy
• Give feedback: quite a lot, mostly positive
• Give credit; take blame
• “Give away your toys”
• Sponsor and coach
• Respect confidentiality but be clear about the limits
• Ask for permission to give feedback, suggestions, etc.

In dating, we also often place value on learning about a prospective partner's past influences and impacts. We often meet their families, especially their parents, and collate and synthesize what we learn about their friends, past partners, and formative environments.

In open source, it can be easy to assume that all of this is already public, because so much of a candidate's past participation in open source projects is public and fairly easy to find via web searches and unified platform accounts on GitHub and similar sites.

But quite a lot of open source participation is in person or otherwise private, and everyone has a life from before they started contributing to FLOSS. Where have they studied and worked, and what did they learn from those cultures? If they've left a previous project, why? If you know people who worked with them on a different project, can you ask those contacts what that was like, and whether the candidate was a good colleague?

The Recurse Center's admissions process requires some sample code and few short written answers, a conversational chat about the candidate's programming experience and goals, and a pair programming task. This does check for a minimum level of programming skill, but also checks how the candidate takes suggestions and how they react when confused.

In an open source project where you're deciding whether to promote an existing volunteer contributor, you could do similar things: invite them to a few open or private live chats to discuss the project's goals, yours, and theirs, and invite them to synchronously co-work on a videocall a few times.

We can also learn from the examples of groups that necessarily organize outside of formal legal structures, such as fictional or historical underground resistance movements. Their "vetting" is sometimes informal, including casual conversation that both grows rapport and elicits information about the candidate's values and temperament. Organizers spend time collaborating with candidates in lower-stakes situations (including games or training exercises), and deliberately allow candidates to encounter stressful situations to test their reactions.

Sometimes vetting does include a more formal process. An organizer might ask whether any existing group members have endorsed the candidate's application, or otherwise ask for references -- people whose judgment the group trusts. And the group might ask for a statement of commitment to the group, perhaps along with a stake of credibility or resources. For instance, a vetted member might have to give organizers their legal name and address, or be willing to host others who need a bed for a night.

That's a lot. I struggle to imagine any open source project that would be wise to set up all of those gatekeeping steps when assessing a new volunteer candidate for maintainership. But, depending on your capabilities and needs, you can choose some. If it's easy for you to get together for live calls or meetups, maybe those approaches work better. If one of your project's other contributors is good at online research, you could delegate to them the task of looking up the candidate's past work. And so on.

3: Can you reduce how much trust you need to give?

The examples above remind us that we can set up systems to reduce how much we need to trust others. For example, a partnered couple can maintain both a joint bank account and separate personal bank accounts, to maintain each partner's financial freedom and reduce risk of theft or accidental overspending. (This does require that the couple place additional trust in their banks. My friend David and I often amiably argue about what trust we place in institutions versus individuals, and I can hear her voice in my head right now reminding me to be skeptical.)

Some ways you can reduce the scope you're trusting your co-maintainer with:

• Do they need to be a full co-maintainer to do useful things? Check the granularity of permissions available on the systems they could help with. GitHub offers several repository roles that don't have full administrative access. Similarly, PyPI lets you add another owner, who can add other collaborators or delete stuff, or another maintainer, who cannot. And you could give someone permission to commit to main but not to publish packages, or vice versa. More on this in "Provide alternate structures for high-quality contributions from strong contributors" in my guide to promoting maintainers.
• Improve security to guard against the co-maintainer's systems getting hacked. Require multi-factor authentication on relevant platform accounts. Confirm code provenance and validate package security with one of a frankly bewildering array of tools (Dustin, I assume this is where you talk about Sigstore in the comments).
  Consider using cloud automation to build, sign, and upload packages instead of the developer's local machine, if you think it's more likely the platform's ops team can keep it secure than it is likely the individual developer can reliably defend their own machine.
• Require co-signing to prevent them from going rogue and doing certain things solo. (I assume this is where the Secure Systems Lab people pop up to remind you: if you want a higher consensus threshold before they can publish a release, use a tool like The Update Framework to require that multiple people use their tokens to approve a new release.)
• Share resources using shared systems to avoid the co-maintainer becoming a single point of failure, and to make it easier to change the locks if you need to stop trusting them. Instead of directly giving them credentials, such as the password to a social media account, use the platform's team features to make them a team member, or use a shared password manager such as 1Password or Bitwarden. Keep shared documents in a shared folder, not just one person's Dropbox.
  Ask colleagues to contact the maintainers via role email addresses (such as "dev@example.com") that alias or forward to the individual maintainers, rather than just cc'ing you as individuals.
• Build alerting systems so you can know you'll get a heads-up if something goes awry. You could set up notifications to tell you of new releases, deletions, additions of co-maintainers, and so on.
  Less obviously, if you're concerned about less concrete effects such as dings to the project's reputation, you could set up a dashboard of social media mentions, and/or set up a recurring calendar item to remind you to check in with particular bellwether users. Set up schedule bots to remind you to make or meet shared commitments together, such as roadmap updates, or to nudge you to make a new release.
  And you could provide a way for users and contributors to escalate complaints to you, or to an ombuds, in case they're running into a problem with your co-maintainer. (This is another tool in the "infrastructure of equanimity" toolbox, and I'd love for fiscal hosts like Open Source Collective to consider providing it.)
• Diversify how you meet your needs. Ask yourself whether your identity, livelihood, reputation, and/or friendships are entirely dependent on this project. If so, develop an exit strategy.

4: What if you don't have time?

I've laid out a lot of ideas for checking a candidate's trustworthiness. But what if you don't have time to do any of that? What if the core reason you need to delegate and leave is because you are a solo maintainer with no time?

(A few maintainer collectives or groups of projects have developed safety-net volunteer groups that can take over projects, which are variations on the model that the currently-stagnating Jazzband initiative popularized. But if your ecosystem doesn't already have a safety net like this, and you don't have enough time to keep your project maintained, you probably don't have time to do social infrastructure work like starting a local Jazzband-like.)

I suggest three options, in the following order.

#1: ask for resources. What would you need to help the project move forward? Coaching, money, administrative assistance, testing infrastructure, mentorship for new contributors, something else? I've written about things you could ask for, and how to ask for them:

• five ways open source projects get stuck
• four non-development ways your users can support you
• a step-by-step how-to guide to recruiting financial sponsors (caution: this will likely take at least 10 hours of work)

And look for your package on Tidelift to see whether some monthly income is waiting for you (example).

These resources could free up your time so you can concentrate on maintaining the project. So ask for help:

• in the README
• on the project's website, if there is one
• in release notes
• on your social media channels
• in replies to people's requests, questions, patches, and bug reports on the mailing list, in chat, and on forges such as GitHub (for example, my comments in 2020 on CI for pip or in 2021 on a requested pip feature.)

Let's say that doesn't work. You could:

#2: perform a hasty check and public handover. Find an existing contributor who is willing to be the new maintainer. Do the bare minimum to confirm that the candidate shows no obvious signs that it would be a bad idea to trust them, and announce the handover in public, in the places a reasonable person would look for that notification. [Edited 31 March 2024 to add: the xz backdoor incident reminds me to note that (a) this hasty check is of course only going to be partially resistant to very dedicated malicious actors, and so (b) if your project is infrastructure that lots of other people depend on, I recommend that you instead skip to step #3, archiving the project and announcing it's done.]

What's the bare minimum? Here's what I think:

• Do a web search for their username and another for their main email address, and spend 10-15 minutes poking around to look for big red flags. Have they been banned from other projects? Do they habitually post hate speech?
• Ask for their wallet name; if they're willing to share it, spend 5 minutes on that web search too. Have they been convicted of embezzling? Are they affiliated with a hate group?
• Mention the candidate privately to 2-3 other open source maintainers. They'll likely speak up if they've heard gossip about the candidate or had bad experiences themselves.
• Review the candidate's past contributions to your project. Have they done anything obviously negligent when they should have known better? Take about 15 minutes to do this.

And where should you announce it?

• the README
• the project's website, if there is one
• the release notes for the first release under new management
• your social media channels

But: let's say you don't have any maintainer candidates, or you are just so done with this project that you cannot face the work of the check and handover. [Edited 31 March 2024 to add: Or, let's say your project is infrastructure that lots of other people depend on.] In that case:

#3: archive the project and announce it's done.

You do not need to find a successor.

Archive the project -- leave the code publicly accessible, but move it to an "archived" state however your forge allows .For instance, GitHub lets you make a repository a read-only archive. Renew the domain name for a couple years, but turn off auto-renewal.

Before you hit that Archive button, change the README, add the No Maintenance Intended badge, and publish a final release whose release notes explicitly say that this is the last version. On PyPI you can set a classifier in the metadata for "Development Status :: 7 - Inactive" to better set user expectations (examples). And announce the conclusion and deprecation of the project on any social media channels and (if there is one) the project website. Announce on Volunteer Responsibility Amnesty Day (the next one is June 20th) if it helps.

If you've already asked for support, and you haven't gotten what you need, you do not owe your downstreams a smooth transition to a successor maintainer or project. And here's why.

As I said in my "infrastructure of equanimity" post:

Each maintainer has to seriously reflect on power and economics enough to develop their own analysis of their freedoms and obligations within open source, and the freedoms and obligations of others. This ought to be nuanced enough to differentiate between users who contribute to sustaining the project and users who do not, and to acknowledge that maintainers have power over users unless they actively work to have power with those users.

Your users had the chance to support you. They still have choices. They could collectively decide to fork your project and co-maintain it, or hire a vendor to do so. Of course this would be easier if we had a pre-existing template and tools for them to gather, decide, and implement that decision, as I discussed in "What Would Open Source Look Like If It Were Healthy?". But they could do it, and it's not your fault if they don't.

Many businesses and volunteer organizations choose to shut down. Sometimes that's because of lack of resources, and/or because they can't find any successor leaders trustworthy enough to steward the project, and they don't want to betray their users/customers/etc. who have come to trust a particular brand reputation. If you need help deciding whether a conscious and caring closure is right for your project, my friend Camille E. Acey has a new initiative called The Wind Down that you should check out.

In your sunsetting announcement, you can even mention that you're interested in anointing a successor, but that the successor will not get your repository, nor the namespace of your package in the package manager (e.g. they won't own "example" in PyPI). This then forces your downstreams to make their own choices of whom to trust.

Another thing that your users could do: publish their own analyses of potential replacements. Someone else can blog about why you should go with the fork of "example" that's called "example2" and why that maintainer seems trustworthy. If they are right, then likely other major distributions, downstream users, etc. will pick that up and share that recommendation till it becomes a bit of conventional wisdom.

If you do later notice a successor project that seems good, you can probably un-archive the README long enough to add that pointer and then re-archive it.

Hope that helps

I’m Sumana Harihareswara, and I can help you implement these recommendations through my consultancy, Changeset Consulting; I do project management, coaching, training workshops, and more. Anyone reading this is eligible for a short free 30-minute consultation call; email me.

And I’m working on a book on managing existing open source projects, so you can learn how to get them unstuck. You can read three sample chapters by signing up for my newsletter.

Want me to write more about related issues? Let me know in the comments or in the Fediverse.

This post started as a few conversations with Paul Ganssle, Itamar Turner-Trauring, and Jacob Kaplan-Moss, and got input from Camille E. Acey, Candra K. Gill, Jed Hartman, Leonard Richardson, and other friends along the way. Thanks, all.