September 6, 2017

How Do You Choose a Library?

By Tyler Evert

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 - Developer
Graham Mueller
Developer

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 - Developer
Patrick Maddox
Developer

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 - Developer
Duane Raiche
Developer

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?


Tyler Evert - DevOps Consultant

About Tyler Evert

Tyler is a DevOps consultant who enjoys teaching and championing for better ways of doing things. Whether it be better testing practices, automation tooling, or core agile principles, the way forward always lies in small steps of improvement.