Ask HN: How do you assess the quality of open-source projects? - riyakhanna1983
======
ishjoh
The first signal I look for is how well will it actually solve my problem. Do
I have to hack around how it works to integrate it or is it straight forward.

The second signal I look at is activity. If a project hasn't had a commit
somewhat recently, then there is a good chance it's not actively worked on, or
does not serve a very large audience.

To be clear, not having a large audience isn't always an issue, every project
starts with 0 forks, but it's always tough relying on a project that has open
Pull Requests sit un-merged simply because the original author has abandoned
the project.

If the project has a small user base, the third signal I try to use is to look
through some of the code base and documentation. Can I jump in and make a fix,
or is the code style so esoteric that it would take me a long time to grok.

~~~
riyakhanna1983
Do you also evaluate its security posture?

~~~
ishjoh
I try to, unfortunately security is typically the hardest to measure. If the
projects documentation specifies security as a goal of the project, I always
look at that kindly, but most projects don't list that as a major goal.

------
cbanek
Does it solve my problem out of the box? If so, and it works out of the box,
then it's a winner. All software has bugs, but if you have a specific use
case, and it works for that, it's good for me.

If it is close to what I need, I submit a pull request against it. Depending
on the reception and how people take it, and how easy it is to get it accepted
is good signal on how easy it is to work with the project.

When doing the PR, you get a feeling of how the code looks. Is it
straightforward? Commented? Do you like the style, do you see obvious errors?
Any red flags should be noted.

At any point, if you think you can do better, you can fork it or start over
from scratch and do it yourself, with a lot more information on what you need,
and what the possible pitfalls are.

------
tjkrusinski
Reading the source tends to be the most valuable way to assess the quality.
Other factors like contribution frequency, ownership, contributing guidelines,
documentation etc are important as well.

I think many people spend too little time on qualifying open-source
dependencies or tools that they will use on a project. It'll do you a lot of
good to dig into the source for an hour or so. If nothing else, read through
the source that makes up the surface of the API that you are going to be
using.

------
cimmanom
One more very important signal that I haven’t noticed anyone else mention is
whether it has a test suite.

------
xfitm3
Evaluate the quality of the documentation. I think it’s a litmus test for
collaborative developers.

------
thiagocsf
I’ve been using [https://libraries.io/](https://libraries.io/) to get at-a-
glance stats on age, activity, number of dependent projects and other metrics
that, arguably, are a good proxy for quality.

~~~
riyakhanna1983
What are some of the things that you like/dislike about libraries.io?

