The Diversity problem in Open-Source projects

The software industry has a diversity problem. Specifically that there isn’t much diversity at all. We are also living in a time where we are hearing about project maintainers engaging in targeted harassment against minorities. This is a problem that we need to address. Why do we as a community have to deal with this, and how can we as maintainers help? Trying to fix a broken system is not a solution, but trying to make it better is the first step.

Just because a problem is hard doesn’t mean it’s not worth trying to address.

I am not proposing that the ideas suggested here are radical, and I am not going to guarantee that by following them that you will see a more diverse population in your own projects. However, The ideas below are simple and effective steps that can be taken to make it easier for everyone to be an active part of your community. There is no magic here, and I am not going to try to make it work for everyone.

How do you make it easier for maintainers to encourage interaction?

Fortunately, there are a few ways to make it easier for maintainers to make it easier to interact with your projects. the good news is that these are also universal approaches that can be applied to any project, and are not difficult to implement.

Maintain and Enforce a Code of Conduct

This might seem like a small thing, but it can be a big deal and requires a lot of dedication. A strong code of conduct is a document describing what is and is not acceptable behavior for interactions in your project. It is a set of rules that you can follow, and it is a way to make sure that everyone is following the rules. A good CoC defines the enforcement rules and what happens when you don’t follow them. It is really easy to find examples of a good Code of Conduct, but many maintainers don’t know how to implement it, and never follow through with violations. Inconsistent or non-existent enforcement of a Code of Conduct can lead to a lot of problems, including scaring off new contributors.

You can start with the Contributor Covenant. It is a very good catch-all, but does not cover all the rules or enforcement details; it is a good starting point. I would recommend making modifications that fit your project.

No matter whether you choose a pre-existing Code of Conduct or create your own, you should make sure that you read it, understand it, and are following it. It is a good idea to have a Code of Conduct for your project, and you should make sure that you are enforcing it. It is not a good look to have a maintainer who doesn’t follow their own rules.

Make it easier to contribute

It doesn’t matter how many times you ask your community for help if they can’t figure out how to get started. Welcoming new contributors not only helps them get started, but it also helps them to get more involved in the project, and the more community members you have contributing, the more likely they will recommend your project to others.

Document your workflows

One of the largest reasons newcomers don’t contribute to a project is due to missing or incomplete documentation. The theory that “good software is self-documenting” is a myth, and it is not true. Documentation is a key part of the maintainer’s job, and it is important to make sure that you have a good documentation system. When your project is public, you should document not only the code, but also the instructions for how to use it, and how to contribute to it.

It is also good to get into the mindset that not all contributions are code. The community also interacts with filing issues, asking questions, and working with peers both in and out of the project. Your community doesn’t begin and end at your repository; just take a look at questions on StackOverflow or any popular forum. Your reputation matters everywhere.

Make it easier to find and file issues

For many new developers, the hardest step in becoming an active member of the community is knowing where to start. As a maintainer, you can start by labeling issues with tags such as Good First Issue or Help Wanted. This is a good signal to new members that you looking for help, and that their contribution will have an impact. As a maintainer, it is a good idea to keep your issues list clean and organized and to make sure that it is easy to know what issues are ready to be addressed.

Be nice

It’s simple. If you are a contributor, you should be nice to others. If you are a maintainer, you should be nice to everyone. It’s a cliche for a reason, but it works. Open-source communication is asynchronous, time-consuming, and very public; it’s easy to get frustrated and even easier to say something that causes a lot of trouble.

As a maintainer, you are a moderator and evangelist for your brand.

I have been contributing to projects for a long time, and have seen my share of drama. Historically I gravitate towards projects that are open and welcoming to new members. I value my time and choose to dedicate it to projects that value respect and collaboration. I hope to see more projects that are open and welcoming to new contributors and look forward to a more diverse community.