Permanently forking a library is something I’ve observed on several teams. The ability to fork an open-source project is a technological and social marvel. But, there are tradeoffs that aren’t always obvious.
My Mental Model
Here’s my mental model for evaluating this choice:
- 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.
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.
It’s a product decision that might be right for your team.
Note: this was originally posted on LinkedIn.