Contributing to an Opensource Project

Opensource software has been around since the 1950s with most of the software written by universities and shared in the public domain.  (Wikipedia, n.d.) Development and consumption of opensource software has fluctuated over the past 70 years or so.

In recent history, the adoption of cloud services and code-based management practices are driving increased development and consumption of opensource software. As businesses consume more opensource software, they need to understand the opensource community.

Opensource software depends on community contributions to projects, even projects maintained by organizations. Contributing back to a project improves the project for all.

There are different ways that you contribute to a project, and many do not require writing code. Sometimes the best contributions are those that have nothing to do with coding.

Before getting into the meat of the article, I’d like to point out that contributions do not have to be large to be impactful. Often smaller contributions are preferred to a few large ones. Smaller contributions are easier to review and typically less likely to conflict with work done by others. Here are some areas where you can help.

Documentation

My preferred method to get started when working on a new project is to review and help with documentation. I have found that it helps with opening a communication channel with the maintainers who can be especially helpful if you start contributing code.

You’ll find that contributions you made to projects consumed as part of your day job stem from issues that you’ve had to overcome. That means that the overhead required to contribute back to the community is low. However, ensure that you are not at risk of making private information public.

Maintaining accurate documentation is a difficult task and typically receives a low priority, which means that helping with documentation is highly appreciated. Reviewing documentation for spelling and language errors helps improve overall clarity for others.

Follow installation guides during deployment instead of ‘winging it’ and make notes of where the guide was inaccurate or unclear. Look for missing or unclear steps, sections that are out of date, or commands that are OS specific.

After making updates to documents (particularly guides), repeat the process following the updated guide explicitly to validate your work.

Check the documentation for broken links and fix where possible. These are a common problem and simple to fix. Raise issues when you’re unsure about broken links; sometimes the link is no longer needed and can just be removed.

Validation of comment blocks within the code is another good way to improve the documentation of a project; with the added advantage of helping you learn about the code used.

Code maintenance

Another good way to learn about the underlying code is to work on test suites. By improving testing quality and coverage, you are decreasing the risk from code changes breaking the application.  Tests are very valuable but can be challenging to write. Undertaking this work teaches you how the project functions.

Maintaining a consistent code style (linting) across a project improves readability and is generally good housekeeping. Most programming languages have tools available to find and correct linting violations. Linting rules are typically found in the contribution documentation. If the rules do not exist, talk to the maintainers first as some code styles have multiple options such as using tabs or spaces.

Issues

Popular projects are going to have open issues, and these are usually a combination of feature requests, bug reports, or general questions about the project. Just like regular tickets, these need to be validated, resolved, and closed off.

Using issues as a starting point is a double-edged sword. Some issues are straightforward and might require updating documentation for improved clarity. Other issues require a solid grasp of how the code functions and quality debugging skills.

When working on an issue that requires a code fix, it’s a good idea to comment that you are working on the issue to prevent conflicts between yourself and another person.

Summary

There a lot of different ways to contribute to an opensource project. If the project is used internally, the contribution can even be part of your standard workflow.

The opensource community depends on public contributions to operate and the more people who make contributions, the more the community grows.