Overview

In software development, a fork occurs when developers create an independent copy of an existing codebase and continue its development separately. A fork differs from a simple branch: while a branch remains part of the same project history and governance, a fork implies a lasting split in direction, maintenance and community support. For background on the broader practice and tooling in software engineering, and on how a copy of a project is produced from its source code, see related guides.

Characteristics and types

Forks vary by intent and governance. Some are cooperative: a team may fork to experiment and later merge improvements back upstream. Others are oppositional, created when contributors disagree with project leadership or policy. Key distinctions include whether the fork remains compatible with the original, whether it adopts new goals or APIs, and whether it attracts a distinct community of maintainers.

Open projects commonly permit forks; for example, many free and open-source software communities expect forks to be part of their ecosystem. A fork can be created by anyone who has access to the code and the right to copy it, including people outside the original development team.

A fork's legality depends primarily on licensing. Permissive and copyleft open-source licenses explicitly allow copying, modification and redistribution, so forking under these licenses typically does not breach copyright. Copyright owners and licensors may still impose conditions via license terms; consult the license text and, when necessary, legal advice. Broader statutory frameworks such as copyright law govern how code may be reused, while trademark or patent claims can affect the distribution and branding of a fork.

History, examples and notable facts

Forks have shaped software history, from early operating system lineages to modern web frameworks. Some forks are created under contractual arrangements: licensed forks of proprietary code can occur when companies obtain source rights. Classic ecosystem stories include multiple descendants of projects like Unix and of large open-source projects where governance decisions led to new, independently maintained variants.

Uses, consequences and guidance

People fork projects for many reasons:

  • To pursue different technical goals or priorities than upstream;
  • To fix bugs or security issues when upstream is inactive;
  • To experiment with breaking architectural changes without affecting users;
  • To preserve a working state when a project is abandoned.

Forking can accelerate innovation but also fragment communities and duplicate effort. Best practice is to try collaboration with upstream maintainers first, document the fork's purpose clearly, respect license obligations, and maintain transparent governance for the new project.