Permanently forking a library is something I’ve observed on several teams. But, there are tradeoffs that aren’t always obvious.
When to Fork: My Mental Model
Here’s my mental model for evaluating when to fork:
- Dead project: this is the easy one. If the software is open-source and has an accommodating license, this can be a great solution to the “Build vs. Buy” question.
- Capable team that can maintain it: Got a team of pros who want to maintain a fork of a popular library for years? This might work.
- The library won’t merge or engage with your patch: You need the project to do X, but it won’t. After a reasonable effort, you might want to fork it.
The Risks of Forking
When you fork, until you pull from upstream or shut down your forked project, you own the code. You don’t have the maintainer(s) to help you, you don’t have new features from active contributors, and you don’t have enough eyeballs to make most bugs shallow.
You’re cutting down the number of people who are watching your code from hundreds or thousands to however many people are on your team now. It’s a bit like copying the HTML and CSS from a popular website; you have the assets, but not the thinking that created them.
Crucially, you don’t have help addressing vulnerabilities, so its on your team to identify it and remediate them alone. Ideally, you’re adding a patch to your upstream project and pulling down.
Conclusion
The ability to fork an open-source project is a technological and social marvel. It comes with significant risk, and it’s a product decision that might be right for your team.