Choosing a software library is not always an easy task, specially if many concurrent libraries exist for a specific need. Many factors could influence a developement team to choose a library, here are some of them:
1- Licensing
The library license is the first thing to check, it’s very important to verify if the license is compatible with your using in your project, before going further and discover the library capabilities.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2- Is the library satisfy your needs?
It’s a trivial factor, but how many devlopers realized a mini proof of concept to check that all their needs are satistified by the library. Sometimes we discover very early that the library is not good for some reasons.
3- The community is active
Many problems could occurs when using a library, if its community is active, it will be very easy to find quickly a solution.
4- What about the trend of using the library?
It’s interesting to know if the library grow on popularity or not? for that you can use google trends and discover the evolution of the library over years.
Here’s for example the trend of d3.js API:
5- Is the library has a break changes in the past?
Before adopting a library, take a few minutes and search in the web for “LibraryName breaking changes” to check if for a specific version a breaking changes was done.
It could help you for the following reasons:
– Avoid using library examples from older versions.
– it’s not good sign if a library has a big breaking change. It means the developers does not care about the library users, and it could happen again in next versions.
6- Constraints and limitations of using a library.
Sometimes a library is awesome for a specific needs, but has one killer limitation which could force you to not use it.
Let’s take as example the google chart api, it’s a versy useful chart library. However, it has one annoying limitation, the user must have an internet connection.
Before choosing a library, be sure that no limitation could affect its using, you have just to search in the web for “LibraryName limtations”.
7- Documentation
A well documented library will helps you considerably when you use it. specially if it contains many samples of using it.
8- Did you care about performence when using the library?
If you plan to use a library in a context where the performence is very important, don’t only trust the benchmarks found in the web. It’s preferable to make a POC with your specific constraints to have a better idea of how the library behaves in your specific context.
9- Is your application multiplatform?
If you application must works in many platform, don’t test mostly in one platform, after finishing the developement test for all the other platforms.
Always test from the begining on all the targeted plateforms, some libraries are very good implemented for an OS and very bad implemented for the others.
10- is there any other serious alternative to the library chose, and you have a doubt?
In some cases you could find two awesome libraries for the same needs, and you have a doubt of using one of them. In this case never let your code highly coupled with the library. Prefer using wrappers and facade patterns to isolate it’s use.
Of course there are many other factors that could influence your choice. and to minimise the risk of using a bad library which we must change it after. It’s always a good practice to isolate its use in some few places in the code, by using wrappers and facades.
Try to evaluate the coupling of your application with all the libraries used, identify the libraries highly coupled with your code, and progressivly try as possible to decouple its use.
Many tools could be used to detect easily the coupling of external libraries, we can enumerate JDepend and JArchitect for java, CppDepend for C/C++ and NDepend for dotnet.
Comments are closed.