We are all moving toward an OpenSource world. Whether we like it or not we are becoming dependent on
<bower|package>.json files. Some have learned, others are waiting to get burned by the
<library>: "*'. It's happened to most "node/bower" dependents. Some idiot developer pushes a new build and tags it with some minor version. He did this because he was by node to follow the "X.Y.Z" versioning format. Then some member of your team had the nerve to type
npm update && bower update. Nothing works and you scramble to figure out why.
Now the example I give just hints to one of the pains of development these days. I actually want to talk about a more serious one. It's almost too easy these days to include a Github project in our code. We need to make sure the code we are including is "good." As in its going to be more useful OOTB or we are prepared to fork and own. The goal of this post is to teach you what you should look for when "vetting" an OpenSource library.
Whenever you introduce an OpenSource library to your team be prepare to own it. If people hate it, it is buggy, or doesn't do everything, they will point their fingers at you fix it. This is why it is vital todo some homework before adding it to your project. What do I look for?
In effort to show you want to look for I want you to look at two separate Github repos:
Commits - When was the last time someone committed something to this repo?
What did I notice? SugarJS had a commit less than a month ago. And best yet it was a pull request which tells me there is community support. ng-Iscroll has not been touched in over a year... YIKES.
While we are here... what else do I know? Statistically:
ngIScroll: Watch:15, Star:84, Fork:51
sugarJS: Watch:104, Star:2243, Fork:235
The community is using sugar, its bored with ngIScroll.
Issues are an indication of quality, but also in activity. When was the last time someone submitted an issue? How long did it take you to respond? How many issues have you addressed? Yet again most of these screenshots speak for themselves:
I saw the "out of date minified version" and got really scared. There are 341 closed issues. Thats a lot of work!
Take away here is take a glance at how long it takes for people to respond to issues. Look at how the repo resolves issue. And then look at the issue that has been around the longest.
Contributors - Do you respect these people? And how active are the contributors. This is one of my favorite views for Github. This tells me instantly how active a particular repo is.
the code Oh last but not least. Does this project have a really good documentation (ghpages)? ReadMe.md up to date? And most important is the source professional? Now this is one that is not easily contrasted with screenshots. But what do I not want to see?
What? They are abusing parent & root scope. Anytime you see people avoiding best practices avoid them at all costs. ng-iscroll is an easy target because it is a rotten project. Grunt doesn't work, node doesn't work, no tests, etc. . Its too easy.
If you look at sugar it has tests! They even have a performance section. Grunt works, they correctly maintain
min versions. It almost seems to simple of a choice?
I'm advocating common sense. Sometimes repos get neglected. In the ngIscroll case ,someone path paved the way, and I don't mind helping resurrect it. It took me less than two hours to repair all the broken windows. ng-Iscroll builds correctly, bugs are fixed, grunt/bower has been bootstrapped, and I hope people start using it again.
If you take one thing way:
be prepared to own any library you introduce.
If anyone is interested in my fork of ng-iscrol. It can be found here ng-iscrol ncapito