Open source projects have many visible cues (or signals) that let people make rich inferences about the health of the project and the tone of its community. These signals inform their decision about using a product or joining a project.
Trust plays an important role in values-based decision-making. If your project has a vibrant set of signals, a prospective user or contributor is far more likely to engage with your product or community.
So how can you influence your trust signals? Let’s dive in.
Trust signals can be direct or indirect.
Direct - Highly visual cues that are quick and easy to consume. These are usually built-in to an interface and include things like the number of commits or issues, project stars, badges, and use of labels.
Direct cues, by nature, make an immediate impression.
Indirect - These are inferred from browsing through content associated with the project, for example, pull requests and discussions. Responsive maintainers can signal a healthy project; and if conversations are positive and inclusive, people can gauge the tone of the community.
Indirect cues are costlier to produce and are therefore more reliable (because they are harder to fake).
An important attribute of signals is their production cost: signals that are costlier to produce are considered more reliable because they are harder to fake.
Key signals that people use to inform their decision about whether or not to contribute to a GitHub project:
A direct trust signal (for example, the number of downloads) may not always be inherently meaningful, but can provide a baseline to measure against. Once a project improves its indirect trust signals, it can measure change against the baseline. For example, improving the README might increase the number of downloads.
When interpreting results, context is really important. The same signal can mean different things to different people (it might be both attractive and unattractive). For example,
What is meaningful can vary by team and by project, so context and personas are crucial when interpreting signals. You can find useful persona questions and metrics at Community Health analytics for OSS (CHAOSS) covering:
Diversity and inclusion
Evolution (growth and decline of project)
Risk (security, code quality, license, transparency)
Value (social, economic, individual, communal)
Shameless plug: Open Strategy Partners provide a trust audit service, and can help tailor a communication strategy for your open source project. Full disclosure: I worth with this agency.
Highly visual cues that are quick and easy to consume (usually built-in to a user interface).
Knowledge inferred from additional information available about the project.
Written content associated with the project, including:
Events involvement (hosting, attending, presenting).
Community channels - Slack and Discord, activity on Stack Overflow, project hashtag use on social media.
Community tone - language used through the project can indicate attitude to inclusion, diversity, and accessibility.
If you’re an open source project looking to increase your user base or grow your community, consider your indirect trust signals. Put effort into creating good docs, be aware of the language you’re using, and really nurture your community. This work will flow through to impact your direct signals (number of download, size of community), and entice new folk to your project.
Image credits: Tower photo by Joshua Slate on Unsplash.
Also Published here