6 things to consider before committing to that Open Source Library

How often you wanted some feature while working on your project that you had to google for a particular library and you settled for the one that showed on top without giving much of initial thought, later only to find out that, that was one of the bad decisions you made. Software Development is becoming extremely easy with the explosion of numerous amounts of free tutorials available online. On top of it, structured instructions from learning friendly websites like Lynda, Pluralsight and Youtube only make the job of a hungry software developer easier with spoon-feed quality tutorials.

Most of the current software development has a lot of dependencies in them in terms of libraries. My job as a software developer is to keep the core Architecture as lean as possible. That means to reduce the amount of dependencies one keeps adding to their own codebase. Libraries are very essential in that they are designed to solve a huge part of your otherwise time consuming efforts and let you focus more on the business problem you are expected to solve.

It is very important to have these 6 points in mind before finalising on the library. (I am going to use Github as the primary example for each of these)

1. The contributors - First and foremost, look at the number of “top” contributors a library has. This becomes a crucial factor because a library may have a large amount of commits and it could even have a lot of favourites, still the number of contributors is a liability that ‘your’ core software is relying on. Often a healthy library would look somewhat like shown below. It is taken from Apache Spark where you can see the top 10–20+ contributors are very very active.

A healthy Apache spark — contributors galore!

Whereas there are projects having only top contributor which could mean disaster. The best example I could pick is Ryan Bates’s famous cancan library which was huge hit for a small period of time. (Although it was no longer maintained, the community brought it back to life with the forked cancancan)

You can see Ryan Bate did most of the heavy lifting initially and went silent and so did this production quality library.

2. Commit Activity - You should be wary of the commit activity aka the busy periods. Libraries would have once had a healthy commit activity but would have patches of dry runs here and there which means either the collaborators/owners are not caring about them anymore or it simply does not have enough adoption.

Below is taken again from Apache’ Lucene library where the library is beaming with Commit activity for just 1 week!

3. Favorites - The number of stars is directly proportional to the number of active followers that the library has. More the fans, more the adoption and more the chances for the crucial issues/bugs to be caught and reported on a timely basis. However, this should not be taken at face Value. Some projects would have had a surge of stars but then would have gone dead because the owner of the library would have gotten busy. One example I could cite here is my ex.colleague’s Mancy Library

Although it had a surge of stars at the initial period, it kind of went silent and could not catch up. This is still a great library REPL for Javascript, but the future is obviously bleak unless the author or the community can adopt and run it.

4. Issues list — This is again an important area I would look into. What are the open/close issues that the library has. It is okay if the library has a lot of open issues, but then it should also have contributors actively committing to it. I am a little bit embarrassed to show this, yet I am one of the collaborator/library owner of this amazing and widely used library - Sunspot. One can observe the stale nature of issues causing frustration among the users.

Sunspot library for SOLR having a growing number increased and unaddressed issues

5. Code Quality - It is difficult to assess a libraries’ code quality. However it is important to at least skim through to see how it is structured. Does it have a build lifecycle? Does it have enough tests? Does it have a proper demo page? Below is an example of an organised front end framework - Materializecss

One of the libraries where Quality gets a prime importance — materializeCSS

Another example of a not actively maintained yet properly written library to calculate horoscope. Yes, its mine :)

bragboy’s horoscope library showing a combination healthy and ailing set of parameters

6. Version support - How good is the library in supporting various versions of the language or tool that you are using. This becomes critical when you are planning for upgrades of your software. Some of the libraries I’ve seen either don’t care for future releases or they don’t care to support the backward compatible items. Below is a best example I could pick. I totally empathize with the author of this library supporting two different versions of Angular and Materializecss. The Author is destined to give up as it too much to ask of him.

I agree that most of the open source libraries are done by Engineers like you and me out of passion and drive. And they pour a lot of love on it. However, they are still prone to vicissitudes of a typical software lifecycle - they will have bugs, they will have performance issues, they will have scalability concerns. It is very important to analyse all these factors before picking or committing on that juicy library. Because if you don’t it will cause you more problems than solve it which is why you went for it in the first place!

Happy Coding!

Francium Tech is a technology company laser focused on delivering top quality software of scale at extreme speeds. Numbers and Size of the data don’t scare us. If you have any requirements or want a free health check of your systems or architecture, feel free to shoot an email to contact@francium.tech, we will get in touch with you!