How Do You Choose a Library?

The massive and rapid growth of the open-source community has made our lives a lot easier, saving us time and effort with a plethora of freely available packages. However, the same growth has caused problems. There's not just a library for everything, there's three or four of them. It's up to us to figure out which one to run with. Here's how some of our developers think about open-source libraies...

For small tasks (like file zipping), how do you go about choosing an open-source library from many options? Where do you draw the line between using a library vs. writing your own?

Graham Mueller


When I'm working on a project and need a library, I'll usually have some idea of things I've used with success in the past. If those fit the needs of the project, I'll default to using that before taking a risk and trying something new. In the case that I've either not enjoyed a tool, or don't have one that fits my needs for the current project, I'll typically start with a Google. This usually yields some StackOverflow posts and GitHub projects to look through.

Step one is to identify whether it's actually solving the issue I want, as many projects seem to have some similar tags, but ultimately solve slightly different problems. Next, and perhaps even more importantly, is whether or not it has the right ergonomics I'm seeking. If the library's interface and interaction is much different than the project I'm working on, it can make it hard to integrate, or kind of break the flow. That often results in needing to wrap it in some interface of our own which isn't ideal (although it can make switching out libraries easier). Assuming that it integrates smoothly, the final concern is if and how well it works. Open source libraries are great, but frequently have bugs (or "features" if you ask their developers) that can either again be wrapped by code you write, or just plain old force you out of using that library. Hopefully you're able to find these early on into an integration and not months down the line when you run into "this one weird scenario where ..."


Patrick Maddox


When running into small tasks, my initial instinct is to grab a library that someone else has written and try not to re-invent the wheel! When I find a potential candidate, it is very important to me to search for potential problems or shortcomings with the solution and what current users think of it before I am ready to adopt. I find it rare that a solution of some description has not been implemented and available for most small tasks. Even using an open source solution that does not quite meet the criteria you are looking for as a stepping stone can be beneficial at times.


Duane Raiche


If possible, I like to run a few different proof of concepts and see how each one works and if any has an obvious advantages or disadvantages compared to another. Oftentimes reading documentation on how to get started is very helpful; but the quality of that documentation can also be a big factor in which library I choose. It's far too easy to commit to a library and then after hours of implementation you start figuring out that it's hard to use due to a lack of documentation.

When deciding if I should just write the functionality myself, I look at how much time it would take to write my own versus setting up the library, how many edge cases I have to account for (timezones), and how big of an impact it would have on the end user. If it's a JavaScript library that every user has to download to visit a webpage, that can rule out a lot of bigger libraries off the bat if I only need a small piece of functionality from it.


What's your selection process for libraries?

Get your project started today

Get in Touch