Our commitments to the community

Here’s why we bring a new open source DevOps tool

As we celebrated the initial release of driftctl 3 months ago, we certainly hoped for some sort of acknowledgement or favorable opinion from those who would use it, but we were not prepared for such a warm welcome.

Reflecting on the first steps of the project, the fast moving star history and the contributions and interactions we have benefited from, we are both grateful and humbled by the support we receive from the open source community.

Why we launched this DevOps tool in the first place

At CloudSkiff, we are all fans of GitOps. We are big believers in the power of Infrastructure as Code and all its benefits.

We like it so much that we decided to build a tool to help DevOps, SREs, infrastructure teams and all cloud practitioners, collaborate over Infrastructure as Code. As a team, we’re a bunch of seasoned people and we all gathered a lot of experience on cloud infrastructures automation. But we wanted to know more. We wanted to make sure that what we were building was truly helping.

So we decided to talk to as many people as possible. We interviewed dozens of IaC practitioners across several geographies: teams of various sizes, levels of expertise, and cloud automation progress status. They all had one thing in common: because Ops life is what it is, and despite their best efforts and process, they had a hard time reconciling their infrastructure code with the reality of their IaaS accounts. They were facing issues with drift.

Drift can be driven by human input, poor configuration, applications making unwanted changes, etc. It has consequences on toil and efficiency, forces teams to put in place strict controls that decrease flexibility, and can have security and compliance impacts. Even as an experienced Terraform user, as your infrastructure team and codebase grows, it often becomes harder to track drift.

Of course, we knew about drift, having oftentimes faced it ourselves, but we were not aware that it was such a widespread issue. So we decided to try and bring a solution to this problem with driftctl, a free and open-source CLI that tracks, analyzes, prioritizes, and warns of infrastructure drift.

What OSS means to us and why we went open source in the first place.

Being part of the DevOps ecosystem, we are very close to a community of tools situated within the Cloud Native Computing Foundation’s orbit. Those of you who had a glimpse at its landscape know that the CNCF drives a thriving ecosystem of tools in its wake, some of them open source.

Major open source projects such as Kubernetes, OPA (Open Policy Agent), Chef, Puppet, Ansible, Istio… paved the way for us and it was only natural to be in keeping with this trend and give back to the community.

But beyond that, it is our firm belief that an open source first approach is key not only to the widest diffusion of a solution to an issue, but more importantly to the best and most comprehensive elaboration of this solution.

Being only 3 month old, driftctl already benefits from contributions from all over the world with major commits, issues and discussions from Asia, Europe, North America… Only truly open projects can federate such goodwill and efficiency.

This is why we released driftctl under the Apache 2.0 license, and we already gathered the best retributions out of it.

Our commitments to the open source community.

In concrete terms, what does it mean for us to be an open source project? Well, being OSS means first and foremost transparency and sharing:

1) Full transparency from master to release

Obviously, our code is open source. But it is important to us that the on-going developments are also made publicly available. Anyone who wants to know what’s cooking can access master, and see real “work in progress” on our code and not some copy/paste of a finished version waiting to be released from a private repo.

2) Live coding sessions

Because we like coding and sharing, we open live coding sessions on a regular basis. Almost daily, anyone on our community discord server and/or on Twitch can see someone from the engineering team live coding and sharing his screen. Feel free to come say “Hi!”.

3) Live release demos

Transparency also means showing and discussing what we do, which is why each major release comes with a live release demo where we showcase new features, discuss the most interesting issues we had, and talk about what is coming next on the roadmap. Those releases happen on Twitch and YouTube live and are available on replay.

4) Live chats within the engineering team

Being a remote first (and remote only) organization, we do not have any offices or headquarters, which means that any member from the Engineering team can work from any place of his/her liking and that sync and async communication is paramount.

While most of the asynchronous communication within the team goes through our GitHub repositories where we store and share all of our resources, we found that a simple engineering chat does the trick to ensure live exchanges within the team whenever we need to work together on something, or even often do some pair programming. Those chats are also publicly accessible to all on our community discord server.

5) Open issues and roadmap discussions

Our foreseeable roadmap is accessible to all in the ROADMAP.md file on GitHub. All issues (internal and external) are also listed and accessible on this account. Anyone can join in a discussion to propose or upvote a feature.

Indeed, we also try to prioritize items on the roadmap according to the feedback we get. Typically, so far driftctl supports both the AWS and the GitHub providers and we see a lot of discussions around which provider should come next (Azure or GCP). You are welcome to take part to the vote here.

6) Extended support time frame

In this early phase of the project, it is critical that we clearly understand what people expect from the tool, how they use it and what kind of issues they face (not to mention the usual early phase debugging period…). This is why we are extremely grateful for any feedback, any question, any suggestion from our users.

Being still a young organization with limited geographical outreach we decided to set up support on call rotation within the team to cover as many time zones across the globe as possible, and make sure we make the most out of each interaction we can get on our community discord server. This is why you are sure to have someone answering your questions from 7:00 am to 11:00 pm CET.

What’s coming next?

While we know that there are a lot more actions to take, so far we’ve sincerely tried to do our best to share our project with the open source community.

Raising awareness on the issue is one of our very strong focuses. Over the last months, we were lucky enough to be invited to talk about drift issues at some major conferences, such as Fosdem, Hashitalks or the CNCF London meetup and it was really great to share our views and experience on this topic. For those who would like to catch up, most of the talks are accessible on replay.

As we move forward in the process of building driftctl, we frequently discover new potential security threats due to forgotten or unnoticed changes on infrastructures. This is why our next efforts will be centered on demonstrating how teams need to complement their DevSecOps Day 2 toolbox and how ensuring the parity of their code and their infras is a prerequisite to shifting security to the left.