DevOps engineers judge software communities the same way people judge each other’s cultures. As a member of an operations team, it’s common to hear things like: This community is quite friendly to feedback, This project is not to be trusted when new releases are cut, things always break, This community has great documentation. Software and the communities working on this software are often put into buckets in order to make it easier to reason about them. Just like in the case human cultures, these grouping provides guidance when it comes to setting expectations about a software running live.

Decisions that may sound simple, like whether you will trust pulling Docker images straight from the community’s repository or whether you will host it yourself, often depend on these judgements. This makes knowing the community that maintains the software you use quite critical as it will not only have an impact on how you run and do maintenance of that piece of software you are deploying but it will also help you decided whether to deploy it at all. A common example is checking whether the community is active before you deploy anything.

What makes this topic more interesting is how diverse these communities are. They may share common characteristics like release cadence, versioning strategies, etc. but they all have enough differentiators that can make this exchange challenging for Devops. Because consistency makes the work simpler, it’s expected to err in favor of what’s known already, rather than adopting software from a community we have never worked with. We tend to pick software from communities we know over others, even if that software doesn’t meet all of our requirements.

Integrating in a new community can take a significant amount of time, depending on the circumstances. Just like in real life, you have to spend time getting to know the community, you have to make your way into it fast enough so that you can gain value from the time spent there but also slowly enough so that the community members don’t feel invaded. You have to learn the customs of the community, and contribute so that people get used to seeing you around.

Being part of the community that maintains the software you run is not always needed. It depends on how core the software is to your business, the complexity of it, etc. If I was a cloud provider relying on OpenStack, I would definitely want to be part of the community. In addition to making my job simpler, it would also provide an opportunity for me to give feedback and contribute to the stability of the software.

All the above said, I gotta admit that my case is simpler than what I have described above, tho. Our infrastructure, while complex in terms architecture and uptime requirements, it’s balanced in terms of software we run in production and the communities we interact with. It may seem like these speaks well of the communities we interact with but I think it speaks more about our biases in terms of what our preferences are and how we reason about the software we run.

A company’s culture can influence operational decisions as much as the characteristics of the communities maintaining the software you want to run. The decisions you make will eventually change the way you do operations, your biases, and your culture. It’s a cycle that requires one to be in constant watch, to be aware of one’s culture, and to welcome other’s… just like in real life.