Rules to use open source solutions?

question.md

If I create new solutions, libraries then is often my task to search for existing solutions to use them or use them as library to create faster and more solid the goal. The current status is more feeling, a mind set on my side to decide is this repository useful and still active in maintenance. So I look at the project is it a 'one man show' or a lot of committers, an organization. This entirely depends on my priorities and field. The more experimental or niche work my do. Different languages may also exhibit different technical traits here which makes this more or less of a concern. In the end I will have to decide for myself, but a list of helping points is more transparent and supporting my decision.

So I want to create clues and indications (not really rules) to get an easier decision to use or not use this library in my project.

Maybe you had also thought about or you have the same problem.

How you decide about the dependencies in your project? What's your rules for or again usage of an existing solution?

Thanks to all your time!

Below is a list (in no particular order) of some traits I look for.

It is important to note that some of these are very superficial and only serve as basic indicators as you assess multiple criteria. They certainly are not rules so take what works best for you. Sometimes well authored packages come from new and unknown (within the community) authors so I don't shy away from that because everyone starts somewhere in their OSS contributions.

Recentness, tests and source code quality are probably the major deciding factors for me, assuming an API meets what is required or can be extended to meet additional needs.

• LAST COMMIT

  • not always indicative of quality/worth — yet the more recent the last commit, the greater likelihood it will be more compatible with your project base requirements (e.g. minimum version of underlying language, other packages)
  • greater likelihood the author(s) follows modern development practices

• COMMIT FREQUENCY

  • useful as an indicator in dedication towards package but can be interpreted incorrectly as some packages require little attention

• TESTS

  • does the package have test coverage?
  • test coverage usually means the author(s) care about the correctness of their work (positive indicator)

• SOURCE CODE

  • inspect the source code, make sure it resembles what you may expect for the time and period in which it applies
  • can be good indicator of extensibility

• STARS

  • superficial but can be an indicator/vote of confidence from other developers
  • some packages with multiples of thousands (stars) usually speak for themselves
  • stars are a visual cue as you scan a page, they are useless on their own

• WATCHERS

  • can be indicative of some importance if people are happy enough to be notified via email and within their feed (often I forget to look at this because we are often trained [incorrectly] to give weight to "stars" on psychological level)

• FORKS

  • many forks can be indicative of community contribution or self-experimentation and that can usually arise from someone creating something useful enough that warranted some participation (I less frequently, if ever look at this as a metric)

• ISSUES/PULL REQUESTS

  • what are the outstanding issues if any, is there any discourse
  • same for PRs, are they getting attention
  • NOTE: it should not be expected in OSS that authors "MUST" be forever active swatting issues and PRs like flies, they have a life too, so I tend to use this as a non-judgemental indicator or whether the project is still supported and am I happy to take on any issues that may pre-exist.

• AUTHOR

  • who authored the package? (are they known in the community or do you recognize them) [should not be used as a primary deciding factor]
  • do they have other packages and if so what are those packages like/what do they cover?