Selecting the Best Open-Source Software for Your Project
Especially for Enterprises
While using Open Source Software (OSS) saves time and resources, choosing the wrong one can negatively impact your project, from legal and security risks to the inability to fix bugs or customize it. Preventing these setbacks requires research.
The first thing developers tend to do is check the project’s star rating. In spite of the fact that it might indicate some interest from a community, it may not always be genuine. A useful tool for tracking a project’s growth is star-history.com, which lets you distinguish between organic growth and spikes after marketing campaigns. In this article, I will discuss the top factors to take into consideration when examining an OSS.
Legal
The first thing to ask yourself is whether the license fits my needs. A good tool that explains software licenses in plain English is tldrlegal.com. In addition, you should verify whether the software itself respects third-party copyright and licensing of any supplied dependencies.
Documentation
Good user and developer documentation is a must. Ask yourself: Are the prerequisites of the software well-defined and straightforward to obtain and deploy, and do they fit your requirements? Is there only API documentation or does it have code samples/tutorials? Is it clear what each version contains?
Liveness
Is it being actively developed and supported? Are the maintainers adding new functionality, or just fixing bugs and security vulnerabilities?
For that you have the “pulse” where you can see stats of last month/week: how many new PRs were opened and merged, e.g facebook/react pulse:
You can verify that the commits rate hasn’t dropped recently for some reason by navigating to “insights” → “contributors”, e.g helm/helm commits:
The presence of an active and sizeable user/developer community can be a positive indicator.
The next thing to check is the releases, their frequency, and the content. Frequent breaking changes might indicate that developers do not care about the library users.
Versions
How mature is the project? Is it in alpha? Beta? Pre-release? Check out the version of the OSS and see how frequent and active the updates are. If bugs are fixed actively, upgrades are done periodically, etc. We need to keep in mind that version numbers contain little meaning when it comes to OSS. Version 1.0 of the OSS need not necessarily be a production-use software. There are no norms attached to the version numbers, and therefore checking out the proper version by reading and researching alone helps determine the latest and current version.
Support
Support for OSS is vital. Don’t hesitate to ask maintainers questions. It’s a good sign if the developers are friendly and approachable.
Contribution
At some point, there might come a time when you will find a bug that is critical for you but less urgent to the OSS community and you will need to fix it yourself. For that you will need to fork the repo, build/debug the code and create a PR with your changes. The number of forks indicates potential external contributors like you. Check how fast a PR is merged in the repo. Do they have a PR template? How easy is it to build the code and does it have appropriate documentation?
Security
Check for open security vulnerabilities in open issues. Scan the package with SAST tools like snyk.io. Don’t incline to accept any updates to your source code automatically. If you do, read the story about colors.js lib first.
Bonus Factors
Test Coverage
How much coverage does it have? Some of the repos post their codcov report with a label in the Readme like vuejs/vue:
Owner
The owner sometimes can indicate how seriously the maintainers take the code, whether is it an enterprise like facebook/react or privately held like igorgov/auto-inc-ver.
Library Adoption
Which products use it? How many downloads does it have?
Maintainers
You can do due diligence on the maintainers, navigate to their GitHub profile and search for them on LinkedIn. See where they work and how experienced they are with the languages, technology, and domain.
Usage Trends
It’s interesting to know if the library grew in popularity or not. For that, you can use Google Trends and discover the evolution of the library over the years. Here’s a trend of React javascript library:
Summary
Here are the vital questions you should ask yourself before integrating an OSS into your project:
- Does the license suit me?
- Am I pleased with the documentation?
- Will I continue to get bug fixes and security updates?
- Is it production- use the software?
- By what projects is it adopted and how?
- How supportive is the community?
- Will you be able to contribute to the repo?
- What open security vulnerabilities are there?
