In software terms, a fork is a copy of a project’s full codebase taken so that it can be developed independently of the original. The word covers two quite different situations: a permanent split from a project, and the everyday, routine copy that platforms like GitHub make a normal first step in contributing.
The classic permanent fork is a new project that diverges for good. The Document Foundation’s own blog records one of the best-known examples: “LibreOffice was launched as a fork of OpenOffice.org on September 28, 2010, by a tiny group of people representing the community.” Contributors split from OpenOffice.org over concerns about its future under Oracle, carrying the code into an independent, community-governed project.
The other meaning is mundane and friendly. GitHub’s documentation defines a fork as “a new repository that shares code and visibility settings with the original ‘upstream’ repository,” describing forks as “independent copies of repositories” that let people experiment without affecting the original. Crucially, “changes from forks can be merged back into the upstream repository via pull requests.”
That second sense reshaped open-source collaboration. By making a fork cheap and reversible, and pairing it with the pull request, hosting platforms turned what had once been a dramatic, sometimes hostile act of separation into the ordinary mechanism by which outside contributors propose changes to a project they do not control.