Let's Go Shopping on Github, or 5 Tips to Pick the Right Software
There are literally thousands of open-source projects posted in GitHub. Depending on your use-cases, there may be tens if not more projects which deliver functionality to your project or company.
How, then, can you be sure to pick the right ones?
Check the License
Check the kind of open-source license (if any) this project is using. It might not be the best choice for you depending on your cases. Learn more about choosing projects with compatible licenses here:
This can become a complex topic depending on your Legal situation. That said, during a due diligence (pre-investment, acquisition, or vendor) you will face questions about what software you use and what licenses you are subject to).
Check compatibility with your stack
Make sure that the code is compatible with your current stack:
- Supported OS
- Language version support (Eg- python 2.7 vs 3.x, or Swift 2,3,4, PHP 5.x, 7.x, etc)
- Will it work with your chosen database (if required).
- Browser support
- Hardware and system requirements (Eg- do you have enough cores, ram, and disk space?)
Note: this library may have it’s own dependencies, which triggers its of list of compatibility requirements. This is why it could be best to use a dependency manager like Pip, Composer, NPM, Maven, or whatever depending on your chosen language.
Another issue for Python users out there: Python2 vs Python3 – it is 2020 and there are still some dependencies stuck on v2. Further complicating things could be that some libraries will only work in Python3 or 3.6 or greater. Beware.
Check the health of the project
Is the project alive, on life-support, or in the graveyard?
This is probably the most important metric I use when picking. Please note, this is subjective. Over time you will develop a “feel” for this kind of thing and set your own limits.
- Number of stars indicate interest from the broader community
- Number of open issues indicate engaged developers and users
- Number of closed issues indicate some kind of resolution processes are in place (eg — bugs are getting fixed and features delivered)
- Check the documentation. Is it up to date with the current code base?
- Date of the last public release
- Is the project under stewardship (eg - Apache incubated) or is it simply sponsored by a company or single developer (aka BDFL)?
Caveat: This generally holds true for me, but it is quite possible that some projects are considered stable and will not need updates for long periods of time.
Does it trigger any new hardware or infrastructure dependencies?
It might require deploying new backing services such as storage, caching, or authentication services. This can significantly increase your complexity or costs of the project.
One such anecdote is that we wanted a thumbnail-generating library for a website project. It just so happens that managing thumnails at scale brings significant speed, memory, and caching challenges. The chosen library offered more functionality but at the cost of adding caching services. This was not budgetd for (mentally or financially), and the library was scrapped.
What are the security risks?
Check the CVE and NVS databases for any unresolved security issues. This will have major implications of you maintain risk assessments, compliance records, or security audits.