The DevOps methodology is becoming mainstream for good reason: 99% of practitioners say it has positively affected their organization.
While DevOps is foremost a way of collaborating, a lot of it is shaped by tools. And it turns out that many popular DevOps tools, such as Prometheus, Argo, Grafana, KubeFlow and Jenkins, are open source software (OSS).
While using OSS is free, assembling an OSS DevOps toolset — with an average of 15 tools per company — isn’t without challenges. Let’s take a look at what these hurdles are and how to avoid them.
Pick active, backed projects
Before adding an OSS project to your DevOps toolset, make sure to perform a full audit: How many contributors does the project have? Are they individuals or organizations? How quickly are issues resolved? Is their community forum, or Slack, active?
This will give you a picture of the overall activity and health of the project.
You must remember that while the software is free, operation costs are always a reality.
Even established OSS projects can be at risk. For example, logging tool Log4j has been in murky waters since last year. Numerous serious security breaches were found, and it took time for the community to develop security patches.
These patches themselves unfortunately brought in new security vulnerabilities. And because the tool is embedded in so many parts of the software stack, fixing issues is a tough task. For smaller organizations with a small IT budget or no exposure to security issues, the patching may never happen. The situation is so bad that the FTC is stepping in and threatening to start handing out fines.
Picking projects endorsed by leading OSS leaders such as CNCF and the Apache foundation is another good indicator. These organizations will perform security audits on projects they support, and, more broadly, ensure that they have reached a level of maturity based on clear criteria.