Rules/Guidelines about forking a project vs. creating a new one?

Question

After reading these lines:

• make a new github project (not a fork).
• merge in the original repository.

In this Answer, I was wondering if there are any rules or guidelines when to fork a project and when to create a new one. If this turns out to be just a matter of personal taste: what are the advantages and disadvantages of both approaches that one should keep in mind.

Since we are talking about open source projects, I think we can assume that either both or none of the approaches are permissible by the original license.

Answer 1

You should (github) fork when:

1. You intend on submitting pull requests back upstream.
2. The maintainer doesn't like your new feature set, so you decide to add them anyway, and maintain the fork in parallel, routinely merging in changes from upstream as an alternative to the main branch. (Note that you may be required to change the name due to trademark restrictions. I'm not real clear on this.)

You should create a new project when:

1. When a project is abandoned.
2. You want to use the project as a starting point for some other project with a completely different goal.
3. When your version of the project will not be regularly merging in changes from the original, upstream, branch.

But that's honestly just my opinion on the matter.

The other important thing to note here is that both of these are technically "forking" the project. One just remains closer to the original project and utilizes the GitHub feature of the same name.

Answer 2

Don't be too bothered by etiquette here if it stands in the way of your project.

There are roughly three scenarios you can follow, each with its pros and cons.

1. The straight GitHub Fork. This gives you

   • Easy pull requests, with lots of tooling around it.
   • Stats gathered by GitHub, able to track your contributions in the tree graph
   • A note on the project that it was forked from the original project
   • Web search of your fork only if it has more stars than the original project

2. The straight merge into your project. This gives you

   • Web search of your code

3. Why not both? Your own project where the source is merged in to, and a fork you use to shuttle pull requests in/out of.

   • All advantages of one and two, but
   • Higher maintenance
   • You could use single-use throwaway forks for this as well if you want

If you want to contribute back to upstream, it's possible and even likely that they'll accept your contribution only as a GitHub pull request. In that case you must have a GitHub fork.

If you want to diverge a lot from upstream, having your own project may be worth it for the code search and the mildly unpretty "forked from" note on your project.

If you want to diverge a lot and want to submit pull requests, you could consider a hybrid approach where maintain a GitHub fork that you sync the changes to that you want to pull-request to the upstream.

In the end, git and GitHub are tools for you as a developer to be useful and productive. Nobody is going to hold it against you if you use tools as they work best for you.

There are no licensing differences between the different scenarios.

Answer 3

The answer that you linked to spoke specifically about seemingly inactive open source projects, not necessarily those that are active. I'm going to take the perspective if this were an inactive project.

The answer that you had linked has many useful guidelines. I personally like that answer: it provides many concrete points that you should understand when finding an inactive project.

I was wondering if there are any rules or guidelines when to fork a project and when to create a new one.

There aren't really any "rules" when forking an open source project. All that you really need to do is make sure that you respect the terms and conditions from the original license.

As long as you follow the license, you're in good hands. You won't get into any legal troubles or anything.

So what about guidelines?

Your quoted guidelines are really just steps, to form a single general guideline. If that's still confusing, think about baking cookies. First, you get the ingredients. Then you mix them. And then you put it into the oven. Same idea here.

1. Create a new repository.

   If you find an inactive project, don't fork it. Forking on GitHub was more designed with the idea that you would submit a pull request - that is, that you would make improvements, and submit them back to the original project. Since you're not doing it, there's no need to "fork" it, as you will link to the original project, and you're contributions won't be measured on GitHub. By "forking", you give people the impression that this is for yourself, and you are intending to push it back to the original project. You are now maintaining the project, and you have full ownership of it.

2. Copy the original project into your new repository.

   This is when you get all the contents from the original project, and you put them into your new project. Pretty simple, eh?

---

How does the license affect me?

I'm adding this part because it will likely be helpful, and of interest to you.

If the license is a permissive license, then you don't need to worry as much. These licenses give you many freedoms for your project, including assigning the project a different license. Some notable examples include the MIT and the Apache licenses.

If the license is a copyleft license, then you're going to have to keep your project under the original license. Some notable examples include the GNU General Public License, and the Mozilla Public License.