You probably use open-source libraries and frameworks on a daily basis. They’re incredibly handy for solving common problems, like how to build an administrative dashboard or how to manage global state in a JavaScript application. One could easily argue that open-source licensing and distribution is the main reason that computers are so ubiquitous today.
If you do use open-source code on a daily basis, you probably also know what a pain it can be to adapt someone else’s solution to your own specialized problem. Personally, I’ve regretted a handful of times when I spent multiple days integrating an open-source solution, only to realize that I should have simply created my own. Sometimes OSS simply isn’t worth the hassle.
But how do you know when to embrace or avoid OSS? There are so many unknowns at the beginning of a new feature, but if you don’t spend some time assessing the situation, you might not have an answer until you’ve already finished the work.
I think you can make a very reasonable guess up-front by weighing two factors: cost and control. The rest of this post will be a simple guide to using these factors to make your decision.
(By the way, I discovered this shortcut after reading my coworker’s post on deciding whether you should purchase off-the-shelf software. It turns out the decision process is very similar—score one for abstraction! Thanks for the inspiration, Mike.)
Your Two Options
Whether you’re creating an admin panel, building an audio driver, or specifying the API for an HTTP service, you probably have the opportunity to incorporate some open-source code that’s been written and maintained by someone else (or many people). Of course, you also have the opportunity to write whatever you need from scratch, or at least without the help of a big library or framework. How do these two choices compare?
1. Roll your own solution: more control and more cost
There are many types of control to maximize. Here are a few:
- Documentation content and quality
- Testing coverage and quality
- APIs (how you interface with the code)
- Feature precision (getting the code to do exactly what you want, and nothing more)
- Tradeoffs between memory usage and speed
- Maintainability (how much effort it takes to fix a bug or add a feature)
- Distribution channels (NPM repo, emailing ZIP files back and forth, etc.)
2. Utilize open-source code: less cost and less control
Here are some types of cost you want to minimize when choosing an open-source solution (measured in time):
- Comparing the many open-source solutions
- Getting familiar with the API and documentation
- Actually integrating the code into your own
- Debugging and testing
- Performing updates (changing package versions and fixing whatever breaks as a result)
As Mike said in regard to custom software versus off-the-shelf software, “Cost and control rise in tandem.” The same is generally true in our scenario. Conversely, if a library takes less time to integrate into your software, then that probably means it has a less flexible API.
It all comes down to one big question.
How Much Control Are You Willing to Sacrifice to Save Time?
We can break this down into a few steps:
1. Figure the cost to integrate open-source code.
Take some time to research possible solutions. Different open-source codebases will offer a spectrum of APIs, documentation quality, etc. You have some heuristics available, too. When considering a library on GitHub, for example, check out the project’s age, number of stars, CI status, issues, and README quality.
2. Figure the cost of implementing your own solution.
This step should be fairly straightforward. It’s essentially the same process as agile estimation for a single story, but with the assumption that you can’t simply integrate some open-source code to meet your acceptance criteria.
3. Gauge your need for control.
First, examine the code that needs to interface with the component that you’ll be building or reusing. Think about how easy or hard it would be to re-work that code so you could integrate an open-source component. For example, if you need a new React component to put inside of a component that you’ve already built, will it be hard to pass down any new properties that the new component might need?
Next, consider how much control you’ll need in the future. If you already know that the section of code you’re thinking about will change in unpredictable ways, then having control over all of the related code is extra-valuable.
You should also consider any strict business or technical constraints. How much control do you need over executable sizes, IP licenses, speed, security, and compatibility with hardware or platforms? Open-source solutions will often introduce severe limits over control in these areas.
4. Compare and evaluate.
The decision mostly comes down to how much time you’ll need to invest (immediately and in the future) to solve a problem. If you need lots of control, don’t try to cut corners by reusing code. If you can’t afford to spend the time, and control isn’t a major factor, then go for the open-source solution.
The decision doesn’t end there, however. As you start to integrate an open-source library or build your own solution, be mindful that you have the option of turning back and trying again. Don’t fall for the sunk cost fallacy!
Balancing all of the pros, cons, and constraints of the solutions in front of you can be exhausting, but it’s all part of the job. I hope that you can avoid some frustration with some up-front planning and by following the steps listed here.
Happy coding!