3

I've made some changes to an open source project but I haven't (yet) been able to get those changes merged into the upstream project source control repo.

I'd like to publish my fork of the project repo but I'd like to disclaim that I'm creating a separate independent project. I intend on regularly merging any changes made to the upstream repo to my forked copy.

I thought that "soft fork" might cover what I'm doing but Google searches for that phrase are completely dominated by discussion of Bitcoin.

Is there an analogous or similar phrase that covers the type of fork I'd like to provide and maintain?

4

There's no specific term. “Fork” is sufficient. “Soft fork” will be understood as well. “Branch” is another alternative.

In fact, forking is the expected behaviour when using a distributed version control system such as Git. Once you've published your changes on a fork, you can make a formal or informal pull request to have the changes from your fork merged into the upstream repository.

To projects that use centralized version control such as SVN, or to projects that are not familiar with this pluralistic, Bazaar-style approach to open source development, publishing a fork may be perceived as a bit more hostile. But as long as you are exercising your rights in the open-source license you received, you're going to be fine. Note that many of these licenses require you to

  • clearly state your modifications from the original (though this might already be satisfied by the version control history)
  • keep legal notices about the original.

All of that should not be a problem for a soft fork.

If you fork a GitHub project via their web interface, they will automatically mark your repository as a fork and link to the original.

In contrast to normal forking, a hostile fork is intended to compete, not collaborate. It has no intention of contributing changes back to the original project, and/or wants to enforce a change in project direction or leadership. A few well-known examples include OpenOffice→LibreOffice, MySQL→MariaDB, and temporarily node.js→io.js.

  • 2
    Calling those forks 'hostile' is misleading. They may have been forked due to trademark issues or differences of opinion, but in free and open source software, this can indeed happen without any hostility (e.g. lawsuits). Of course, if they can be maintained as one project, that is the ideal, but if not, independent projects are fine, too. I remember there was once a Firefox fork that was supposedly more optimized for 64-bit architectures, but probably it fell out of favor because the official branch does this well enough now. – Brandin Feb 28 '18 at 15:53
  • I think 'fork' carries connotations of being a separate independent project. 'Branch', to me at least, is tied too closely to a branch in a single source/version control repository; which isn't the case for me. But I'm pleased to learn that at least someone else thinks 'soft fork' is clear enough. – Kenny Evitt Mar 1 '18 at 14:40
3

The phrase "friendly fork" is sometimes used when the intention is to merge back into the original project if possible, and to keep in synch with the original project until then. (These are not strict conditions, just a statement of intent.)

A typical use-case is forking a popular project that appears to have been abandoned by a sole developer.

  • btw in a software context, soft fork means the same thing, that's where the blockchain term comes from, although it has additional specific meaning in a blockchain context – david.libremone Apr 5 '18 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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