HACKER Q&A
📣 asim

When is it appropriate to fork a project?


I've been thinking a lot about what leads to forking a project these days. I used to think it was a terrible idea, that it takes away valuable dev knowledge and man power from an existing project but having run things that are now close to a decade old I'm starting to revisit my past assumptions. It seems as though at a certain point in time it might make more sense that a project is forked and the two paths are divergent. I've seen this more and more where communities cannot agree on the path forward but also where a project reaches certain limitations and the only way to make progress is by stripping away much of the tech debt and starting again.

What are people's experiences with forks? What are some of the most successful forks? When is it appropriate to fork?

  👤 perrygeo Accepted Answer ✓
I don't think "fork" has a consistent meaning, at least not since the arrival of github. In the early days of open source, a fork was somewhat hostile and indicated a schism or lack of confidence in the original authors. Today, at least on github, a fork is a positive thing and is the primary mechanism by which people contribute to open source!

It's obvious that you're using the 1st meaning but it's worth clarifying because there's a lot of grey area here.

Are you forking the project to make a small change and submit it upstream? (the friendly fork)

Are you forking the project to have a playground for new ideas and experiments? (the playground fork)

Are you forking the project to deploy custom patches while you wait for upstream to fix a bug or add a feature or cut a release? (the pragmatic fork)

Are you forking with the intention of using that code to bootstrap the creation of a entirely new and unrelated product? (the bootstrap fork)

Are you forking with the intention of maintaining the existing product with a new direction because you don't agree with the authors? (the hostile fork)

Are you forking with intent to burn most of existing codebase to the ground and build it back up from scratch to compete in the original domain? (the competitive fork)

Of these, I think the friendly, playground, and pragmatic forks are generally seen as positive since the original project and its users can benefit directly. The bootstrap fork is neutral, no harm but there is an opportunity cost and occasional whining from rent-seekers or copyleft purists. The hostile and competitive forks are generally a negative since it implies a community schism and should be avoided unless there are solid technical benefits that cannot be achieved through existing means.