Is there a common way to describe an actively-maintained open-source fork that wants to remain a fork because it makes changes that don't align with the upstream maintainer's desires?

Example: Alice is creating a relatively popular GPL-licensed DJing software that only works with a specific brand of controllers. It is clear from the README that supporting other controllers is out-of-scope, at least on the repository she maintains. Bob likes Alice's program but would like to adapt it to another brand of controllers. He makes a public fork, and wishes to continuously merge changes from Alice's version so his doesn't diverge too much and remains up-to-date with non-hardware changes. Bob isn't doing this in a hostile way, and may as well contribute back to Alice's branch (which actually relieves Bob from complex merge conflicts too, so it's beneficial for both of them).

How would you call this? A "soft fork", as mentioned here? I insist on the fact that Bob has no intent to open a PR on Alice's repository at any point in time.

  • 1
    Longlived fork, perhaps?
    – ecm
    Commented May 26, 2023 at 16:02
  • 1
    That's the definition of a fork Commented May 27, 2023 at 6:56
  • @planetmaker That's wrong. If I fork a piece of software to suggest changes to the upstream repository, I still consider that a fork even if I'm going to delete it after it is merged. What I'm describing is a specific kind of fork, but is not the definition of a fork.
    – MrAnima
    Commented May 27, 2023 at 8:49
  • @ecm that's a very fitting term, I found it used like what I'm describing at least here. I'll accept it immediately if you want to make a real stack exchange answer (or write it myself later if you don't).
    – MrAnima
    Commented May 27, 2023 at 8:55
  • I also stumbled on a repository calling itself "A re-entrant fork of LuaJ" with no further explanation. I understand the usual meaning of reentrancy in CS, and I'm wondering if this is a figurative meaning for what I'm trying to describe.
    – MrAnima
    Commented May 27, 2023 at 9:07

1 Answer 1


This is about language, language is evolving and is not used everywhere the same.

Cloning a repository in order to submit a patch sure enough creates another copy of the project, and there are some changes not yet found in a released version of the project whose code you cloned - yet that does not constitute a fork in the classical sense. Copies made and edited in order to submit patches and changes are just that: branches or different versions of the very same project.

A fork in the usual or original sense is a project which took a specific version of a project and developed it independently. Thus at a later point in time, they share a common history up to a certain revision, but then the code diverged. The cause for the creation of a fork often are differences in the governance of a project (e.g. LibreOffice was forked from OpenOffice, or Jenkins from Hudson). For these cases the projects diverge often increasingly so that after a certain time the exchange of patches becomes increasingly more cumbersome.

More generally a fork often is created when the direction a project takes with including or not including certain features. These forks with a slightly different code base are somewhat common for most major projects as not everyone can agree on every feature or omission - yet exactly this is the beauty of open source: you can and are allowed to fork it and create your own versions.

Thus depending on how permanent this separation is perceived, one might call these modified versions with some additional features, or patches or left-out patches not forks, but just "version" or "branches". A typical example for such a long- or medium-term lived version would be an project which rejected a suggested implementation of a much-asked-for feature which did not meet its quality or other guidelines for inclusion - but which is maintained by one or some interested individuals, but not diverging much beyond maintaining this feature branch. Call it fork, call it feature-branch - it's the same, just with a slight different take on the relation between the core developers and the ones of that feature branch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.