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: check out the trust audit service provided by Open Strategy Partners. 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.

An open source project can work to directly influence their trust signals by creating good docs and nurturing their community.

If you’re a project looking to increase your user base or grow your community, consider the trust signals of the project. Put effort into polishing your indirect signals (written content and community activity) so that they flow on to impact your direct signals.

References

Image credits: Tower photo by Joshua Slate on Unsplash.

Also Published here