Who is a “member” of your project?

This post co-authored with Brian Exelbierd.
We often use the words “contributor” and “member” interchangeably in open source projects, but there are subtle differences between the two. Members are a subset of contributors, and the distinction doesn’t always matter, but sometimes it does. Ruth Cheesley spoke about this at FOSDEM 2024, but we have more detailed thoughts.
How is being a member different from being a contributor
A contributor is largely defined by their sustained contribution over time. While useful contribution always advances the project towards its mission and vision, members typically go above and beyond in this area. It isn’t that they contribute more than most, though they may, it is that they are focused on the project’s mission and vision as first-class goals above and beyond any value the project may provide for their specific use case.
In some projects, distinguishing between a member and a contributor may not be necessary. In such cases, it’s better not to create that distinction. For example, if your project has a very high ratio of users to contributors (far in excess of the generally discussed 1:100) your project probably doesn’t need a distinction between contributors and members because all contributors are effectively members.
Benefits of having defined membership
Being able to define your membership and identify the members can be important in a few situations:
- Members can be expected to provide “altruistic” help and to step up when no one else does.
- When there is tension in a project or a big decision, you may wish to give consideration to user, contributor, and member concerns separately. Having a list of members can help you know who gets to vote. This can also help you more easily identify commentary from drive-by, single-issue individuals or opinion-only stakeholders.
- When you need to manage resources, membership can be a good starting point for deciding who receives funding. For example, membership may be a condition for sponsored attendance at your project conference or receipt of potentially abusable resources, such as a project email alias.
- Sometimes you need to define membership to satisfy a governance or legal entity requirement. For example, in some countries, your project will need a non-profit legal entity to do things like accept donations or gifted services. That entity needs members to fulfill their legal requirements.
When you have to create a membership class for this reason, make sure you’re clear about if you’re expecting the other aspects of membership to apply to these people or not. It may be helpful to choose a very specific name for this group that is unambiguous.
How do you decide who is a member?
There are several ways you may initially think are good to use to define membership, such as donations and activity. Those are fundamentally flawed.
Patronage: Using donation or patronage, typically of funds, infrastructure, or some other resource, as a benchmark for membership doesn’t serve as a proxy for making the project’s mission and values the primary goal. This kind of contribution is usually just furthering contribution or, in a lot of cases, showing support while serving in a more advisory position. A company sponsoring your CI infrastructure may want to be associated with your project for a ton of reasons that don’t involve putting your project’s mission first. Your successful application to someone’s open source sponsorship program doesn’t mean they endorse you specifically.
Activity: Measuring activity also feels like a useful proxy for membership. However, you risk identifying super contributors who are narrowly focused. Generally, you’ll want your membership to reflect both the breadth and depth of your contributors. Using activity as a measure can remove the voices of individuals whose contributions are hard to measure or where there are few measurement points.It is worth noting that for projects with limited use cases (or users whose use cases are very aligned) this measure may work. That still doesn’t mean you should use it.
Given the limitations of using activity or patronage as criteria, a better approach might be to evaluate contributors based on their criticality to the project.
Criticality: Thinking about your project and your contributors — who would you go to talk about big problems and issues first? These could be technical direction questions, but they could also be governance or goals questions. Who is doing the yeoman’s work of keeping critical systems that serve everyone online and working? Who shows up and provides the words of wisdom and advice you need? Those are your members. This is not a metric-measured criterion; it is a subjective judgement. Therefore you need to have a public process for identifying and confirming membership over time. This way, your membership list is defined before it is needed, not during or after. And don’t forget to have a process for removing them!
Pitfalls
Defining your membership is not without challenges. When you create an in-group people may start to feel like they are part of the out-group. This could disincentivize people from starting in your project. They may be worried that they need to get permission from the in-group or will struggle because they aren’t members. This can be overcome, but you need to do so intentionally.
Creating membership necessarily adds an administrative burden. You’re going to have to track who is a member and determine if they remain a member. Measuring activity is notoriously hard because a lot of activity isn’t as easy to see retrospectively as a git history.
Having a separate membership class can draw a strong line between groups of people in your community. You need to intentionally focus on making sure they still feel like a welcome and important part of the community. Make it clear how they can submit ideas and engage on problems. Also, consider creating an advisory board to ensure that non-members feel like their viewpoints are represented.
This post’s featured photo by Mick Haupt on Unsplash.