  The notion of software ''fork'' has been shifting over time from the
(negative) phenomenon of community disagreements that result in the creation of
separate development lines and ultimately software products, to the (positive)
practice of using distributed version control system (VCS) repositories to
collaboratively improve a single product without stepping on each others toes.
In both cases the VCS repositories participating in a fork share parts of a
common development history. Studies of software forks generally rely on hosting
platform metadata, such as GitHub, as the source of truth for what constitutes
a fork. These ''forge forks'' however can only identify as forks repositories
that have been created on the platform, e.g., by clicking a ''fork'' button on
the platform user interface. The increased diversity in code hosting platforms
(e.g., GitLab) and the habits of significant development communities (e.g., the
Linux kernel, which is not primarily hosted on any single platform) call into
question the reliability of trusting code hosting platforms to identify forks.
Doing so might introduce selection and methodological biases in empirical
studies. In this article we explore various definitions of ''software forks'',
trying to capture forking workflows that exist in the real world. We quantify
the differences in how many repositories would be identified as forks on GitHub
according to the various definitions, confirming that a significant number
could be overlooked by only considering forge forks. We study the structure and
size of fork networks , observing how they are affected by the proposed
definitions and discuss the potential impact on empirical research.
