Open-source software is a set of software projects with a permissive license that can allow anyone to modify and customize the code. Depending on the license, copyleft or copyright may be enforced. Licensing software can be a conundrum, so this article is not about them.
Joining an open-source project can be overwhelming, as the process of onboarding is not as straightforward as in a traditional brick-and-mortar software shop.
### How to start contributing to open-source software
The primary contributions are usually in the form of code that enhances the functionality of the project.
+ Read the documentation.
+ Try the software on your local machine.
- Build from source.
- Set up your local development.
+ Familiarize yourself with the essential git commands.
- How to clone the repo
- How can the local repo be updated to be in sync with remote
- How to make a pull request (PR)
+ Read the coding standard
+ Join the discussion forum
+ Understand the culture from reading code reviews on old or stalled PRs.
+ Read the source code
There are other ways to contribute
- Writing tests
- Writing document
- Doing code reviews
- Improving the build system
- Answering questions in the forum
### After Making a PR
You will be asked to make changes. Your design choices will be criticized. Keep in mind that the suggestions are in line with the philosophy of the current maintainers. Be patient, as many open source maintainers are volunteers with full-time jobs. There is a case of a person waiting for 7 years to get his PR merged into [Linux master](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d).
Your PR may be declined or rejected. These are some reasons that come to mind. We are in a politically correct world, so people will not tell you exactly how they feel. You can infer intent and what comes to my mind includes but is not limited to:
- Solving an irrelevant issue (that no one has or will ever have).
- Poor code quality.
- Huge technical debt.
- Untested module.
The rule of thumb to minimize rejection is to choose from open issues and ask in the forum before working on the problem. Every PR must come with a detailed description of the contribution, so the merits of the PR can be properly evaluated. The code quality can be improved by reading the coding standard and obeying rules typical of a software craftsman. The likelihood of stalled PR tends to increase with mature open source problems. My definition is based on the popularity of use and the large companies relying on it. This is because maintainers know that keeping the code maintainable minimizes sleepless nights. Try to add tests to every PR and ensure that every existing test passes to increase confidence and reduce the likelihood of rejection.
### How to handle rejection
There is no real rejection as your contribution remains public in your GitHub account for the world to see. However, there is a misconception among a few individuals that every PR has to be merged to be a valid contribution. This myth is flawed on multiple levels, as it is perpetuated by those who unknowingly misunderstand that PR is a medium of communication. Not every PR has to be merged. For example, a PR may be showing why an approach is flawed or even why an idea is dangerous. These kinds of PRs are very useful for their educational content and should, therefore, remain open. The words of Albert Einstein come in handy, "Insanity is repeating the same mistakes and expecting a different result".
Kenneth Emeka Odoh is a Software Engineer based in the beautiful city of Vancouver, Canada. I have started contributing to the [sympy](https://www.sympy.org/en/index.html) project and have written my observations based on my first attempt at making an open-source contribution.
16/16
Please feel free to donate to support my work by clicking
