6 ms·

Ask HN: How do you assess the quality of open-source projects?

12 points by riyakhanna1983 8y ago

ishjoh 8y ago
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 8y ago
  Do you also evaluate its security posture?
  - ishjoh 8y ago
    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.
xfitm3 8y ago
Evaluate the quality of the documentation. I think it’s a litmus test for collaborative developers.
cbanek 8y ago
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.
thiagocsf 8y ago
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 8y ago
  What are some of the things that you like/dislike about libraries.io?
cimmanom 8y ago
One more very important signal that I haven’t noticed anyone else mention is whether it has a test suite.
tjkrusinski 8y ago
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.

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 8y ago
Do you also evaluate its security posture?
- ishjoh 8y ago
  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.

xfitm3 8y ago

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

cbanek 8y ago

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.

thiagocsf 8y ago

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 8y ago
What are some of the things that you like/dislike about libraries.io?

cimmanom 8y ago

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

tjkrusinski 8y ago

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.