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...
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 ..."
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.
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.