Contributing To Open Source Software As A Beginner: The DOs and DON'Ts

Contributing To Open Source Software As A Beginner: The DOs and DON'Ts

Contributing to open source is pretty interesting as it helps to improve skills while collaborating with others on projects. The amazing thing about open source software is that the source code is freely available for anyone to make changes. My fear about contributing to open source has always been, "when is the right time to start?" But now, I've realised even skilled developers may have anxiety issues when contributing to OSS (Open Source Software).

In this article, I'll share a few things I recently learned about contributing to open source. I hope this will guide anyone hesitant about getting started.

Roles in an open source project

You can choose a range of roles that don't necessarily involve writing codes. People contribute to OSS with various skills and technical expertise. Knowing these roles and what they are about in the project is best.

  1. Contributor
    They fix issues and update the project's software with necessary changes. Contributors are required to follow a contributing guideline.

  2. Users
    These are people who use the software. They provide feedback about feature suggestions and also report bugs.

  3. Author
    This is the creator of the project. The author usually has the power to distribute roles among others who want to contribute.

  4. Maintainer
    They help to review contributors' pull requests and communicate with the community on the applications of the project. Maintainers are generally about the project's improvement.

Features of an open source software

  1. ReadME file
    image.png A README file is like plain markdown documentation. It serves as the first detail of the project that provides users and contributors with the first details about the software. I find this feature friendly.

  2. Contributing guidelines
    image.png The contributing file is a text for intending contributors describing how they can contribute to the project. It is common for an open source project to have a contributing guideline because it makes it easy for contributors to understand the software.

  3. License
    image.png You can recognise open-source software through the presence of a license. A license protects contributors and users. It allows the project's source code or design to be modified or shared under the defined terms and conditions. Some common licenses used by open source projects are MIT license and Apache license 2.0.

The Dos of contributing to open source software

  1. Keep your emotions in check
    Think of others when writing a comment; make human-readable comments only. Sometimes you may get frustrated by comments from maintainers; you shouldn't let this get to you. Don't regret contributing, do something different or take a break and try again.

  2. Follow the contribution guide
    Every open source project has a contribution guide for contributors to follow. It's important to stick to the guidelines before contributing to OSS; always check it out.

  3. Learn Git and Github
    If your reason for not contributing to OSS is about not being familiar with GitHub - you can learn it. Try pushing some of your codes to the platform - proficiency comes with practice. You can practice making pull requests and become more familiar with the tabs and tools. Doing this will give you the confidence to work on public contributions.

The Don'ts of contributing to open source software

  1. Opening one issue for different issues
    Avoid opening one issue for more than one issue. Instead, be specific and make the issues different. Also, ensure you give your issue a good title; if it's short and descriptive, your issue will have lesser chances of being ignored.

  2. Breaking the codebase
    When contributing, it is important to follow the consistency of the codebase. For someone like me that doesn't use semi-colons regularly, if the software's codebase uses semi-colons, do the same. The same thing goes for the casing, do not use a camel case for software that uses a snake case.

  3. Starting without approval
    If you have something you want to work on, make an issue before you start it. There may be cases where such an issue has already been assigned to another contributor working on it. On the other hand, if a user dropped the issue, you can comment on it and notify the maintainers about your interest in working on it. By doing this, you will avoid issues of your pull request not getting accepted.

Final thoughts

I'm hoping to take advantage of the endless opportunities offered by open source. I'm curious to know what you think. Are there other dos and don't you know about in open source? If you've read this far, do share your opinion!