How To Choose Open Source Package
Tags: opensource, webdev, tutorial, git
Published: 2020-05-19 22:02:04

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
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/r8nr9yt93cuo3p4vv4hx.png)

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](https://github.com/axios/axios) , [moment](https://github.com/moment/moment), [loadash](https://github.com/lodash/lodash) . 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
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hhg6lbe3u2keh1836a84.png)

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
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/utcfq9jb480zfku4jw8s.png)

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
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kqj5m83zpqssvmay4xhe.png)

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
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yqcan61a52ubqts4ajic.png)

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.

#### if you have other opinions or suggestions leave a comment and let's discuss.