Trust Signals in Open Source Projects

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.

Signals 101

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 README file with thorough contents and clear structure, describing what the project does, how to get started using it, what a new contributor could work on, and what guidelines they should follow.
• The availability of scaffolding, such as issue and pull request templates, or issue labels.
• How actively maintained the project is, along multiple dimensions, such as the number of contributors and the recency of commits.
• The friendliness of the maintainers in issue and pull request discussions.
• Project popularity (a rating on GitHub).

—From The Signals that Potential Contributors Look for When Choosing Open-source Projects

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.

Context is important

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,

• Frequent releases might signal a vibrant project, or that a codebase is very buggy.
• A detailed contributor’s guide might excite some new contributors but be off-putting to others, signaling too much process overhead and a higher bar to participation.

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.

Examples of signals

Direct signals

Highly visual cues that are quick and easy to consume (usually built-in to a user interface).

• Number of downloads
• Popularity (stars)
• Use of labels
• Number of open issues, open PRs
• Release history
• Code quality and coverage, and other information represented by badges
• License
• Number of commits, contributors, forks, issues, pull requests, star gazers, and watchers

Indirect signals

Knowledge inferred from additional information available about the project.

• Written content associated with the project, including:

  • README
  • Release notes
  • Documentation
  • Code of conduct
  • Contributor’s guide
  • Onboarding process
  • Conversations in issues and pull requests.

• 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.

  Focus on your indirect signals

  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.

References

• The Signals that Potential Contributors Look for When Choosing Open-source Projects
• How to Make Your Open Source Project Successful
• How to evaluate the sustainability of an open source project
• Beyond maintenance
• Ten Ways to Build Better Communications with Trust

Image credits: Tower photo by Joshua Slate on Unsplash.

Also Published here