How software development works

Most free software projects are developed by many collaborators. To do this, they usually use a program called a version control system (VCS), which records the history of changes and intelligently merges their contributions together.

From a contributor's point of view, it works like this:

Use the VCS to get the latest version of the project
Improve the code
Use the VCS to generate a 'diff' or 'patch' which describes the change they made
Send their patch to the maintainers (people who control what actually gets accepted) for review and merging

That last part can be done in different ways. For many old projects, like the Linux kernel itself, you send your patch as an email to a mailing list.

More common is the use of web-based "forges" - websites where you click a button to open a "pull request" or "merge request" requesting the maintainers to merge your changes.

By far the most common version control system is named git, and was actually invented by the same person as Linux! Teaching you how to use git is far outside the scope of this tutorial, but you'll definitely need to learn it at some point to contribute to free software projects (or to get a job as a programmer, for that matter!).

The most common web forge is github.com, which is unfortunately itself a proprietary (but free to use) service owned by Microsoft. There are many alternatives. My favorite is sourcehut (sr.ht).

Forks

What happens when someone fiercely disagrees with the project maintainers? If the project maintainers misbehave, or if they reject good patches or merge bad ones? Or maybe they are just inactive, so the project has stopped receiving needed improvements. Or maybe someone just wants to take the software a radically different direction, to make it more suitable for a different use case.

In these cases, someone might (and anyone can) copy the code, publish it somewhere else and start making changes independently of the original developers. This is called a fork. If enough people are dissatisfied with the previous maintainers, they'll start using this fork instead and sending their patches to it.

Sometimes forks change the name of the project to distinguish it from the original. Other times they effectively replace the original as the canonical version.