How To Choose Open Source Package

#opensource #webdev #tutorial #git

In this post I will show you what consideration to take when pulling open source packages into your project.

as pulling an unmaintained or badly designed package may be a costly decision for your project.

Number Of Stars

I tend to think the number of stars as likes for a tweet. I know there are many unuseful tweets that have tons of likes. but in the dev community, the case is different.

if you take a look on popular packages like axios , moment, loadash . you will find they have tons of stars (likes) which is a good indicator that other developers may have used them and decided to give star (like) for the package.

so before pulling a package check Number Of Stars . as probably no one would star a package that caused him pain in his project.

Number Of Used By

number of used by means other developers have pulled down the package and used it in their projects.

while this metric may not be very useful . as you may find many hobby projects that pulled down this package for experimenting it. but keep an eye on this metric when choosing a package.

Number Of Opened Issues

issues mostly mean bugs that appeared in the package and need to be fixed. but also it could mean a question or feature suggestion or etc...

the higher number of opened issues may indicate that this package is less frequently maintained.

the lower number of opened issues means wither the author of the package is active and closes them frequently or the package is solid enough and it solves the current problem without any further updates.

Number Of Opened Pull Requests

pull request means other developers are helping the author to maintain the package by fixing bugs, adding new features, enhancing the code quality, etc...

but a higher number of opened pull requests . could mean a higher number of unsolved bugs or the maintainer lost his interest in this package.

so a lower number of opened pull requests could be a good indicator that the author is listening to what developers need and accepting their contribution.

Last Commit Date

last commit date indicates if this package getting periodically updates and keeping up with what's changing in the dev community or not.

for example if a package has last commit a year ago. this means you will depend on a package that isn't updated from a year. pulling it may be a costly decision. so make sure to take a look at the last commit date

Code Quality

last thing i tend to do is to check if this package has acceptable quality code for me or not.

as judging on package quality is subjective from developer to other.

but for me i like to check:-

wither the package has tests or not .
is the code easy to read and understand by quickly checking a couple of classes. as when the package is written in an understandable way this means the author of the package can easily update it. or even me can contribute to the package .
the package API is friendly and flexible enough to cover my use case or not.
last thing if I am not sure to wither pull it or not. I quickly pull it and do some proof of concept.

hope you enjoyed these suggestions 😉 and keep your eyes on these metrics when pulling a new package into your project.