Blog header with title "Tips for Evaluating Third-Party Libraries" by Will Shawn, Software Engineer. The background is gradient of light to royal blue hues. The text is bold, white and in the background on the right side is opaque white line art of a laptop with a list and checks or X on the list.

Evaluating Third-Party Libraries: Good, Bad & Tips for Effective Usage

The rise in popularity of open-source software has made the usage of third-party libraries nearly universal. Projects often use dozens of them and those, in turn, use dozens more. We want to avoid reinventing the wheel and if someone else has already solved a problem, it doesn’t make sense for us to solve it again.

The Good and the Not-So-Good

At its best, open-source software provides solutions that have been thoroughly vetted by hundreds or thousands of users. Bugs have been found and squashed. Edge cases have been considered. An API has emerged that’s general enough to be useful in a variety of ways across different types of projects.

At its worst, the experience with third-party libraries can be quite different. Most of us have found ourselves in situations where a poorly chosen library ends up causing more trouble than it’s worth. Instead of saving time, a bad library can actually cost time in the long run. 

Maybe it was poorly designed and a bad fit for anything beyond the author’s own use case. Or maybe an absentee maintainer won’t fix bugs, accept pull requests or answer any questions. This can have the effect of dragging down your other development efforts. Time you could’ve spent on new features instead goes toward hunting down bugs in a library. 

It can also make it harder to update other parts of your stack if those updates don’t play nicely with the library, which can open up security vulnerabilities. It’s impossible to completely prevent this from happening, but a little bit of due diligence can minimize the risk significantly.

Let’s go through what you need to think about as you’re considering a third-party library.

Scope the Scale

First thing’s first: before selecting a third-party library, get a sense of the scale of the project and where it fits into its ecosystem. In every ecosystem, there are the standard libraries that everyone seems to be using. Is the library you’re considering one of these standards, or is it relatively unknown? If it’s been around for a while and it’s fairly popular, you should be able to find people talking about their experiences with it. If it’s one of several competing libraries, find reviews comparing and contrasting them. Make sure you understand the community’s general consensus about the library you are considering and where it fits in.

The scale is important because the smaller the project is, the easier it will be for you to understand. This will allow you to step in to fix bugs or add enhancements when needed. These considerations become less important as the project scale gets smaller. Also, consider the risks inherent to the part of the stack where you will be using the third-party library. If it’s authentication or security related, be extra careful. If it’s a UI widget, you can be less careful.

Maintenance Matters

A lot of the risk stems from how the third-party library is managed, so you want to get a sense of how well everything is maintained. Spend some time browsing through the repository. Figure out who the main contributors are and how active they are with their projects. 

Platforms like Github give us a window in the inner workings of open-source software projects that we’ve never had before. Look at the issues list to see what people are reporting. If an issue seems quite popular with a lot of discussion going back many months (or even years) without a lot of input from maintainers of the project, that can be a red flag. If maintainers drop in and are defensive or dismissive, that’s also a red flag.

Some of the best small third-party libraries I’ve ever used have had maintainers who kept popping up all over the place. In addition to their Github pages, I would also see them answering questions in Stack Overflow, on Reddit, in a Discord channel, in an IRC channel, on Twitter, etc. Seeing this level of engagement out of a maintainer is a very good sign.

Look at the open PRs, dates and discussion. Is there a simple bug fix that’s been open for a long time, with a lot of users chiming in that they need the fix too? Probably a bad sign. Look at the closed PRs and try to get a sense of the rate at which the library has been changing. 

It’s not uncommon for people to be excited and engaged at the beginning of a project, only to lose interest later on as new things compete for their attention. A long track record of sustained attention by maintainers is a very good sign, and something you want to look for.

Contributor Competence

Look for indications of professionalism of third-party libraries you are considering. Are there specs written for the library? Is it well documented? Is the code well organized and easy to read? Other than making it easier for you to use the library, all of these things also make it easier for the community to jump in and contribute. In turn, this makes it less likely that the library will be abandoned later. If it’s easy to contribute to, the maintainer can hand off control if they ever lose interest. A member of the community can fork it and continue development. A serious maintainer will make sure all of these things are in order so that a community can grow around their work.

Wrapping Up

Taking the time up front to holistically evaluate a third-party library you want to use won’t only make it easier for you to get up and running, it will also help you avoid making a mistake that might come back to haunt you down the road.