Forking FOSS projects

Forking open-source projects has been incredibly beneficial for me. It provides a way to take control when I disagree with the direction of the project or its maintainers, or when the project is simply interesting to me.

This decentralized approach allows me to collaborate with others and implement changes that align with my vision or address specific needs. It also serves as a safety net, ensuring the project's continuity if the original version is abandoned or takes an undesirable turn.

I love the freedom to experiment and customize the software to fit my specific requirements.

Decision graph

Naming strategy

When deciding to keep the name of the fork or to make up a new one think of what you want to do with the fork. In case you want to keep on fixing bugs or small improvements or feature additions with everything else staying as is, use the same name. In case you want to overhaul, redesign, refactor something dramatically, you might consider a new name as it will almost always end up in a separate, distinct piece of software.

1. Do I want to fix only bugs, docs & TD? → Fork it, keep the name.
2. Do I want to improve existing features? → Fork it, keep the name.
3. Do I want to add a few minor features (1-5)? → Fork it, keep the name.
4. Do I want to add a few major features (5+)? → Fork it, consider change.
5. Do I always get push-backs while contributing new features? → Fork it, change the name.
6. Do I want to overhaul the app while keeping the core as-is? → Fork it, change the name.
7. Do I want an entirely different product based on the codebase? → Don't fork, create new project.

Versioning strategy

When forking a project another question that arises is what should I do to the inherited version?

Discard

This method implies discarding the version to an initial one that suits the project.

If you consider the inherited project ready for release and you don't want any other changes

1. Is it ready for a public release as-is? → Discard to v1.0.0
2. Is it ready for a beta release as-is? → Discard to v1.0.0-beta
3. Is it ready for an alpha release as-is? → Discard to v1.0.0-alpha
4. Is it planned to overhaul major parts of it? → Discard to v0.1.0

Continue

This method implies continuing the version from the last one. Useful when extending with the new features without changing the core too much.

Release strategy

TODO

Managing strategy

TODO

Gathering & responding to feedback

TODO

Merging changes into our repository

TODO

Submitting changes into their repository

TODO