Choosing the right tools for your open source projects

Current discussions are broadening to how a tool might streamline workflow and make it easier for people to contribute to and participate in communities.
87 readers like this
87 readers like this
Minecraft and open source?

Opensource.com

Every open source community wants to make it easier for community members to participate and contribute. Typically, there are discussions on cultural aspects of the community to lower barriers to entry, such as fostering a friendly and welcoming environment, onboarding processes, mentorship, code of conduct, etc. However, in my discussions with several open source communities (e.g., Freedesktop, GNOME, KDE, etc.), I found that one of the key criteria when selecting new tools for code, CI, bug tracking, etc. for their projects was how a new tool could also help lower barriers to entry for new contributors.

Many open source communities have now been around a decade or more, and the tools they have been using are starting to show their age. So I have been hearing a lot of discussion in various communities about evaluating new tools for the future. I was pleasantly surprised to hear that for several communities, the discussion was not just limited to technical feature comparisons among different tools. In fact, they were using these tools’ evaluation/migration process as an opportunity to streamline their workflow and make it easier for people to contribute to and participate in their communities.

Some of the points I heard concerning how proper tools can help lower barriers to entry are:

  • Better integrated tools can support a more seamless workflow for contributors. Integrated tools will lead to a decrease in context switching between tools and duplicate work. Even something as simple as not having to deal with multiple logins can make a big difference in improving contributor experience.
  • Better/more familiar user interface makes it easier for people to contribute and engage with the community. If the user interface is not intuitive, it will be even more challenging for new members to start engaging with the community. Most people experience impostor syndrome when they join new communities and are reluctant to ask what they think are simple questions. Also, having to look through pages of documentation is a frustrating way to get started in a new community.
  • Easier management of toolchains will allow IT people to spend more time actually helping community members rather than managing and fixing tools. This is somewhat related to the point above on better integration. Too often, you see IT and sysadmin team members trying to debug or fix things like integration issues between tools. This takes valuable time away from helping new members with their onboarding and answering questions on tools and workflow.
  • The right tools can facilitate more transparent discussions and decision making in the community. This point was particularly interesting for me, as I had heard that when it becomes too difficult to find or follow communications on how important decisions (e.g., on governance, technical directions, prioritization, etc.) are made in the community, people will start to get discouraged, lose interest, and stop participating in discussions. This is where things like being able to label or organize discussions easily can be helpful for community members.

I have had my share of contentious discussions around tools in open source communities that I have been a part of. Looking back, I feel like too much focus may have been on technical features or even the tools’ vendors or providers. I wish we had taken the opportunity to expand our deliberation to consider how tools could contribute to lowering barriers to entry for community members.

I was impressed to learn that, in some communities that are evaluating new tools, community, and onboarding groups are key stakeholders in the evaluation and migration processes. Tool selection and migration is an important discussion that can have an impact on your community for years to come. So when you start the journey, I encourage you to follow the lead from communities that worked with their teams to evaluate how new tools can also help lower barriers to entry for contributors.

What to read next
Ray is the Head of Community at Cube Dev where he is helping to grow the community of contributors to Cube.js. Prior to Cube Dev, Ray managed open source communities at GitLab and the Linux Foundation.

2 Comments

Ray, Good write-up in addition, tools can also be tested on varieties of metrics to access their correct usage. For example, using CHAOSS project.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.