Feel confident navigating the open source world

Collaboration is an essential part of software development - whether with a small team, or a global community in the open-source space. In this post I wanted to cover the 3 basic concepts that make software collaboration at scale possible.

Git hosting services

Open-source projects can have hundreds of contributors from around the world, and are typically hosted on platforms like GitHub or GitLab. These platforms offer features that sit on top of vanilla version control like permissions and collaboration tools.

The key thing to know about these services is that behind-the-scenes the hard work is done by Git itself. Managing file changes, branching, merging, and even interfacing with remote repositories can all be done entirely with Git through your command-line or IDE. In fact, hosting Git repositories on personal servers rather than a corporate cloud provider is probably more aligned with the ethos of open-source.

That being said, these hosting services streamline certain workflows that make collaboration using Git much easier. Features like: repository read/write permissions, discussion forums, and code review tools are advantageous when we’re talking about making projects accessible to a global audience. That’s why the rest of this post will focus on Git collaboration using these hosting services.

For a high-level explanation of Git hosting services see this video.

The forking workflow

After an open-source repository is uploaded to a hosting service, giving every contributor write access to that repository (also called the “upstream” repository) would be far too chaotic. That’s why the core development team protects the upstream repository with read-only access for outsiders. Only trusted maintainers can directly modify the code. In order to create a safe path for contributions, potential collaborations must start by forking this upstream repository.

When you fork a repository, you create a server-side clone under your own account. You have full control over this new copy - you can modify it, push to it, and even delete it.

Importantly though, the fork retains a connection to the original upstream repository. This relationship enables a key collaborative workflow: pull requests.

you can make changes to your fork, then open a pull request asking the original maintainers to review and merge your contributions.

This model is essential for open-source collaboration. It keeps the original repository protected, while still allowing outside developers to contribute.

Pull requests

A pull request is a polite ask to incorporate changes into a repository owned by someone else. Pull requests also provide an opportunity for community feedback (i.e. code review). Project maintainers, and others in the community, can:

• View each commit and line of code you changed.
• Ask questions or request improvements.
• Discuss your contribution and share new ideas.

If everything looks good, the core maintainer group can merge the changes from your fork into the upstream repository. Congratulations! You’ve just made a contribution to an open source project.

Tips

Open source projects (especially large ones) sometimes have guidance for potential contributors. These guidelines are typically posted somewhere in the project’s README file, and dictate best practices on how to contribute to that particular project. Make sure to be respectful of these guidelines.

Further reading & watching

• Forking vs cloning explained [video]