Taking a DevOps perspective on open source can help to incorporate an OSS project into your environment. DevOps engineers are comfortable with using third-party integrations, and they align with the open source mindset of breaking down barriers between different groups and promoting teamwork.
Hila Fish will give a talk about the DevOps perspective on open source at DEV: Challenge Accepted 2023. This conference will be held on September 30 in Sofia, Bulgaria.
While developers think about open source from the functional side of things, Fish believes that DevOps engineers should think about it from the operational and environmental side of things, for instance, how will the OSS tool/project benefit the environment and get integrated into it, and what other peripheral things are needed in order to do so, like security and maintenance considerations.
According to Fish, DevOps engineers are not afraid of integrating open source tools.
A lot of DevOps engineers come with a system admin/engineer background, which means that the notion of 3rd-party integrations are not strange to them:
We welcome it as it helps us achieve a lot of important and needed things like process automation, code delivery, introducing certain capabilities, etc.
DevOps is all about breaking down silos between development and operations teams and fostering collaboration, Fish argues. Open source projects embody this spirit by encouraging contributions from a diverse range of individuals and organizations. DevOps teams can leverage the collaborative nature of open source to create tools, frameworks, and platforms that align with their specific needs.
According to Fish, open source projects provide opportunities for team members to learn new skills and gain exposure to a broader set of technologies. Engaging with open source communities can help DevOps professionals stay updated on industry trends and best practices.
InfoQ interviewed Hila Fish about the DevOps perspective on open source.
InfoQ: What are the challenges of searching for suitable open source projects?
Hila Fish: There are a lot of projects out there. You need to choose the right one that is the most suitable for your use case.
You’d also want to make sure it’s serving most or all of the following benefits:
- It is a mature enough product that won’t require too much maintenance and won’t have too many bugs.
- It is regularly maintained so if bugs are encountered and found, they’ll be fixed rather quickly.
- It has a big enough ecosystem so others can help you in case of issues (also know that a big enough ecosystem usually means that a lot of use cases are already covered in the current state of that project), and be aware that you’re not the only one using it.
InfoQ: What’s your perspective on open source software?
Fish: Since DevOps engineers are oftentimes the production gatekeepers, we want to strive to introduce the best solution possible. The common ground between DevOps and open source is collaboration. And as we know, in most cases, collaboration leads to better conclusions and solutions/implementations.
When communities, like OSS users, form around shared challenges, a lot of ideas naturally emerge, leading to better solutions. As production gatekeepers, we want to make sure we choose the best solution possible for our environment, so this common ground helps us achieve that.
InfoQ: How can we know when it’s appropriate to integrate OSS projects and when not?
Fish: There’s no right or wrong when it comes to adopting an OSS project. It’s a matter of perspective. But there are things you can and should think about before going forward with the integration, to make sure this is the best fit, and that it could potentially last for long.
Things like - if the project is active, you know that it will address issues and bugs in a frequent manner. So, if you expect to be a heavy user of that tool, you should put a lot of weight into the activity metric. Otherwise, you would find yourself with an obsolete tool that you’d either need to maintain yourself (where you didn’t plan for), or to plan a migration for another tool.
Also, if the tool’s ecosystem is small, you’ll feel it in your engineering day-to-day. It’ll be harder to introduce new capabilities because the tool doesn’t support them. Since the ecosystem is small, there are not a lot of users who made it work or asked for these features before you. Also, there might not be enough users for you to reach out for help, for instance in community channels like discord/slack, or in online presence like blog posts, or stackoverflow answers.
