A Beginner’s Guide to Open-Source Contribution for Developers

Pieces 🌟 - Jan 3 '23 - - Dev Community

New to open-source? This is a comprehensive guide to making your first open-source contribution.

Open-source contribution is a necessary skill for developers as it teaches new skills, collaboration and the ability to manage real-world applications. It presents an efficient way to develop software without complexities. This can be achieved with the use of version control systems and open-source software.

What is Open-Source?

Open source in software development indicates anything that can be accessed by the general public.

Open-Source Contribution

Open-source contribution involves working with open-source software (OSS). It encompasses collaboration with other developers to improve and develop new or existing projects built on OSS.

Common Terminologies Used in Open-Source

  • README: This is a written document that serves as the project’s exposition to new contributors and provides detailed information on how to use it.
  • Documentation: Every project has documentation. These are necessary files that attribute to making it an open-source project. They include an open-source license, a README file, contributing file and a code of conduct.
  • Repository: A repository or repo is a collection of a project’s files. It tracks all the changes made there and stores them.
  • Pull request (PR): Pull requests are used to discuss changes made to a branch in a repository.
  • Issue: This is a tracking system for repositories.
  • OSS: This means open-source software. This is software whose source code is available for public use and access. Commonly used version control software includes Git, Mercurial and Subversion. They support developers with source code management.

Contributing to Open-Source as a Developer

As developers, there are different parts of a project that can be contributed to. A project is built by different people in the tech space with different roles.

The popular issues developers like to contribute to are code issues. There are no-code issues, and they often fall under the following categories:

  • Design
  • Technical writing or documentation
  • Community management
  • Developer advocacy and relations
  • Mentorship

Roles in Open-Source Contribution

There are different types of individuals involved in an open-source project.

  • Creators: The people who came up with the idea for the project, got the license, built it, and put it on GitHub.
  • Maintainers: Those who are responsible for accepting requests for issue solutions and maintaining the project.
  • Contributors: These include the programmers and developers who have an interest in the project and want to contribute.
  • Users: These are people that make use of the project.
  • Working Groups: These include teams of developers that work together on an issue and contribute their solution collectively.
  • Sponsors: These might be individuals or companies that sponsor the developers who contribute to the project or support the building of the project directly.

Platforms for Open-Source Projects

The first one is GitHub Show Case. This is a platform that houses a compilation of projects created by developers new to the open-source space. Looking at the different projects on display can give you an idea of how to present your work, and perhaps spur you to create your work.

The second is GitHub Explore. This is very helpful as it has very easy navigation links. It contains projects that have been made by developers, and they can be found either by programming languages, trending repositories or projects with the most engagements— these can be identified by stars.

The third is GitHub Topics. This is similar to the previously discussed platform as it has filters to help ease your search.

Other platforms include Good First Issues, 24 Pull Requests and Code Triage.

The Phases of Open-Source Contribution

There are things to look out for before contributing to a project, including:

  • An open-source license
  • If the project is actively accepting contributions
  • The number of issues (open and closed), contributors, and pull requests
  • When the last commit was made
  • Discussions about the project

To be able to contribute to open source comfortably, you need to be sure of your skill sets and your level of expertise in that particular field. You cannot transfer non-existent knowledge!

Choose a Project

Endeavor to choose a project that requires skills that you possess. For instance, a developer with web development skills can fix a bug in the CSS file of a project. Go through the documentation, and look at the existing issues. If you find an issue you’d like to work on, indicate interest. Issues can be found on the /contribute page of the repository. Make sure to do this so the issue can be assigned to you and not someone else.

If there are specific problems you noticed in the project that have no existing issues, reach out to the project maintainer. An issue can be created after your request is confirmed.

In the discussion forum, talk about the problem you want to work on. Remember to keep all discussions public, as other contributors can learn from them.

Open an Issue

If you request an issue to be assigned to you, there is no need to open another issue. A new issue can be opened if there is a particular problem you want to work on, or if there is a new idea that you want to add to the project. Ensure that an issue has been assigned to you.

Go ahead to work on the issue after these conditions have been met.

Open a Pull Request (PR)

  • Fork the main repository of the project.
  • Clone it locally.
  • Create a branch to work with.
  • Link your local repository to the main by setting it as remote.
  • Pull in changes from the main repository often to stay updated with recent merges and issues. This will prevent merge contradictions.
  • Include references, images and files used in your pull request. This shows the authenticity of your contribution.
  • Test the changes made after adding your contribution. This is to ensure that your pull request does not contradict the existing project.
  • Examine your pull request to see if it fits the contribution guidelines of the project.

Submit Contribution

Submit the pull request and wait for a response from the maintainers. One of these incidents might occur during this time:

  • A request is made to edit from the maintainer to edit the pull request.
  • There is no response from the owners or maintainers of the project.
  • The pull request is labeled unacceptable.
  • The pull request gets accepted and merged.

An open-source contribution is only complete after a successful pull request (PR) merge.

Version Control

Version control is an efficient way to manage software development without making permanent changes to the source code of a project. The source code is an accumulation of a project’s versions, progress, documentation, and solutions. It cannot be seen by the users of that product.

Developers build projects to solve the problems of their target audience. These projects often need to be updated to meet user demands. Version control supports collaboration and tracks changes made to the source code while making it accessible to the public. When developers work together on a project and make conflicting changes, version control detects the issues. Team members further tackle it by working on the source of the problem.

Version Control Systems

Version control systems (VCS) track changes made to files. There are several version control systems.

  • Centralized version control system: On this version control system, the users work on the same repository, which can be located on a local machine or a server.
  • Distributed version control system:This is a type of version control system that enables users to access the same file system from several locations. It is ideal for projects with team members based in different places and supports remote work and virtual collaboration.
  • Lock-based version control system: As the name entails, this version control system employs the use of locks to regulate access to files and resources. This method prevents users from making conflicting changes to the same file.
  • Optimistic version control system: This control system supports the ownership of private file systems. When a user of this VCS wishes to share their modification of the product with the rest of the team, a request is made. The server then reviews this request and integrates it into the already existing project if it is a right fit.

Git

Git is a distributed version control system. It is the most common and widely used open-source version control software among developers. It works on different operating systems, including Windows, macOS, and Ubuntu. It is also compatible with IDEs, e.g., VS Code and IntelliJ. It is easy to learn and can be used to host a variety of projects with static efficiency. The open-source platforms Git collaborates with are GitHub, Bitbucket, and GitLab.

How to Use Git

  • Download Git: The first step is to download it to your computer. The official Git page has download links for different operating systems.
  • Install Git: After installing Git, the next step is configuration. This is done with a command line interface (CLI) in your terminal. On Windows OS, GitBash is the command shell that comes with Git, while macOS and Linux systems have built-in terminals.
  • Configure Git: Confirm if Git is properly installed with this command: git --version.
  • User identification: Set up your username and email address. It is necessary to use a functional email address as this will be associated with your GitHub account and other open-source projects.

The command used for this is: git config

git config –global user.name “your name”
git config --global user.email “your email address”
Enter fullscreen mode Exit fullscreen mode

Other commands can be carried out to set up your default text editor, default open-source platform and other secondary changes.

To check out the changes made in the terminal, use git config --list.

GitHub

GitHub is an open-source platform used for project team development and collaboration. It was founded in 2018 and is owned by Microsoft. It hosts a large percentage of source code in the world and is used by a lot of developers. Developers can present their GitHub profiles as resumes to prospective employers because it hosts projects they own or work on as collaborators. It is also open to the public.

Setting Up A GitHub Profile

  • Sign up for an account: There are free and premium accounts. A free account can be created here; you can upgrade to premium later.
  • Install Git: GitHub runs on Git, which has to be installed on your computer system, as above.

How to Use GitHub for Open-Source Contribution

The following are steps to follow while contributing to an open-source project using GitHub. After configuring Git on your machine and setting up a GitHub profile, the next step is to contribute.

  • Choose a project. Choose a repository and click on the Issues link. This will lead you to the issues section. Go through all of the issues listed there and indicate interest in any that suit your preference. This is necessary to ensure that the issue is assigned to you. If this is not done, another developer who has indicated interest will contribute to that before you do. Make sure to read their documentation, README files and contributing guide to get more information on the project. This will provide a wider scope of information on the work you are to do.
  • Ask for permission. Request an assignment to an issue. If this is not possible, because there is no issue to work on or none suits your fancy, it’s okay to create an issue. This isn’t to stir up trouble, but to talk about a potential problem with the project that you think needs fixing. This can be done by analyzing the project. For web applications, Lighthouse in Developer tools can help identify these. Go to the Issues section and create a new issue. Give it a name, discuss the problem you brought up, and remember to write it in Markdown. If there are images to support your claim and to add more context, add them to your issue.
  • Wait for feedback. It’s important to wait for feedback from the creators or maintainers of the project, as it would be a waste of time to work on the issue and the not get permission to add it from the owners of the project. After the project has been assigned to you, the next thing to do is fork the repository. This is done to create a copy of the issue in that project to your GitHub account. That way, all of the changes you make will be on your main server.
  • Work on the issue. Click on code, a green button, and copy the URL to clone the issue. Go back to the terminal on your machine.
  • Use the terminal. cd desktop.

Create a new folder with mkdir and the name of the folder.

Run cd folder to open the folder in the terminal.

Run git clone. Paste the URL link copied after this and press enter.

Allow it to download.

Run git pull. This automatically updates the local version of the repository with recent changes, pull requests and merges. It’s necessary to avoid merge conflicts!

Set it up locally, that is, on your machine, using code. It opens the repository on the IDE or text editor on your machine. Make a new branch on the terminal using git branch and git checkout.

Do this before modifying the file and making your changes.

After this, save your changes and source it on the terminal using git add public/ and the name of your file from the text editor.

Run git status to check the file. It will show here if it is ready to be committed. Assuming it is, run git commit –-m “fix: and the sentence showing the changes you made.” Run git status again to confirm that a commit has been made.

If this is positive, it means that the file has been moved to the staging area. It’s not ready to be added to the repository. At this time, the branch does not exist on the main server, so it is to be set as an upstream branch with this command:

git push –set-upstream origin and the name of the file.

This resolves all of the problems that prevent the file from leaving the terminal.

After this, run git push. You can see it works just fine. It pushes your changes.

Go back to the repository and reload the web page of your GitHub account where the repository was forked. You’ll see the newest addition at the top. Click on the button that says compare and pull request.

This enables you to make a pull request to the original repository. After this is done, add comments to the pull request you made to inform the maintainer about the changes you made.

It might take a while to get a response or feedback on the pull request you made.

Feedback may not always come back in a positive light, as you cannot tell what the maintainer would make of the changes you made to their project. It’s okay to feel burdened by very thorough feedback, but don’t let it overwhelm you! Instead, work on the response.

Take some time to thank the people that you worked with for their suggestions and feedback. This promotes a healthy working environment.

If it’s your first time pushing a project to GitHub using Git, you may encounter a problem with the password. It may ask you to input your password for the process to go smoothly.

To fix this so you don’t have to battle this problem every time you want to contribute, store your password on your machine using this command:

git config --global credential.helper store
Enter fullscreen mode Exit fullscreen mode

There you go! You have completed an open-source contribution project on Github.

Conclusion

There are endless opportunities to make open-source contributions. Google Summer of Code, Hacktoberfest and Outreachy are programs solely focused on open-source contributions. Get started by becoming a contributor today!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .