Stop hate-forking projects
Why Adam Innes believes forking is the highest form of flattery in the world of open-source software
Adam Innes believes forking is the highest form of flattery in the world of open-source
The open-source philosophy lets anyone take a project in a new direction by changing the original to create something unique. That philosophy is the reason we have projects like Firefox, a project originally forked from the Mozilla Application Suite. In Firefox’s case, the developers felt the software was too bloated, so they used the original codebase to create a more streamlined browsing experience. As a result, Firefox has become one of the most used browsers in the world. Forking a project is a sacred and important function of the open-source model, which is why it’s important to know when to do it right.
When it comes to proper forking etiquette, there are best practices in regards to publishing forks. To be clear, fork privately any way you want. Experimenting with new features and code is part of the fun of programming. Even though guiding principles of open source ensure developers have the right to publish a fork, it doesn’t mean that is always the correct choice. Forking to make a small insignificant change or to add a single feature without properly attempting to participate in and contribute to the open source community is bad form.
The original project maintainers have put their code out there because they believe in it and they know that other people may have ideas to improve on what they’ve made. To them, the project is probably something they’re passionate about. Before bastardising their hard work and effort, one option is to submit a feature request. Open source projects typically have a system in place to accept feedback and code, so we recommend using it. If you’ve already coded the change, submit the new code in a pull request. This approach helps ensure that developers not publish a fork and just walk away.
Submitting a pull request in lieu of a fork is especially important if you’re improving the security of the code. Open Source software relies on the ‘many eyes’ approach to security, meaning the more people looking through the code base, the better. Don’t hide your security tweak in an unseen and forgotten fork. Instead push it with pride and your efforts will likely be much appreciated by the maintainers plus you’ll be making the code more secure for all those who use it.
If you’re passionate about the project and have a vision for the future, become an active contributor. This is also a great way to hone your development skills. Participating in the project gives the maintainers an opportunity to make the feature or change available to everyone who uses that project by incorporating it into the original. Not only does this please users through the thoughtful improvement of the overall user experience, the practice of joining a project can help introduce you to a world of coding opportunities. When you build relationships with fellow programmers, the resulting sense of community uplifts everyone.
If you’re passionate about the project and have a vision for the future, become an active contributor. Sometimes you will find that the project has been abandoned and is no longer actively maintained. In this case, you should reach out to the maintainer and ask to take it over, which would afford you the option of building on the project framework while taking it in a new direction. A good example of this is when Jeff Atwood, the co-founder of StackOverflow, publicly asked to take over the Markdown project from John Gruber or to have Gruber participate in a new version. Receiving no response, he created CommonMark. CommonMark was forked with the intent to create a new, better version of the original. Atwood attempted to participate in the original project and reached out to the original maintainer. That’s how you fork.