If you are into infrastructure automation, you may have heard about driftctl: a free and open-source CLI that detects changes outside of your regular IaC workflow and warns of infrastructure drift. Recently, CloudSkiff (the company behind driftctl) decided to join forces with Snyk and accelerate its mission to deliver the full gains of infrastructure automation for developers and their cloud deployments.
Living this evolution from the driver’s seat was an excellent opportunity to reflect on the key opportunities and challenges of joining a new organization as an open-source project.
When debating what is open-source or not, you often get into loud and passionate discussions. That is probably because there are as many definitions of what is the true nature of open-source as there are people discussing it.
Some will bluntly state that open-source software (OSS) is a work where the source code is open for all to view. To others, open-source is clearly a matter of price (or absence thereof), meaning that OSS software should be free to use. And what should “free” mean? Free as in beer or free as in free speech? Digging further, most developers will appreciate the fact that an open-source project is built in the open and allows for external contributions (issues, discussions on the roadmap, or commits to enhance the code). While there is probably an official definition of what really is “open-source”, chances are that there is no consensus on that question.
The point here is to introduce what we had in mind while building driftctl as an open-source solution. We clearly wanted to solve problems for developers with their cloud deployments, and help them achieve a better IaC quality. The tool had to be free for them to use, and open in it’s construction. This would enable precious feedback on what should be prioritized on our roadmap and would hopefully let us enjoy some external contributions to the code.
If you are going to build something in the long run, open-source or not, you need to have the financial resources to do so. When we started building driftctl, we wanted to do something great. It was clear to us that, at some point, we would need to build a paid version of the tool on top of the open-source CLI and try to monetize some additional features. We were aiming for an open-core model (defined as: “offering a core or feature-limited version of a software product as free and open-source software, while offering commercial versions or add-ons as proprietary software.”) This model offers a kind of balance and makes it possible to turn a “cool project” into something greater by making it sustainable with the resources necessary to achieve its goals, but we were aware that this would take time.
The first discussions we had with Snyk about integrations got us thinking: “Hey this is a very cool recognition of what we have achieved so far”. Product-wise, there was an obvious synergy between driftctl and the Snyk platform and thinking about integrations totally made sense. But joining Snyk as one team was another level we had not anticipated.
At this point, the very first question that comes to mind is: if we join them, is the tool that we’ve built going to remain open-source? There is some sort of urgency that you feel. Like the weird need to make sure that you are not going to betray anyone: not the project that you’ve been building, nor the team and most importantly, not the community of early adopters that were so supportive around you.
What clearly tipped the scales for us, was that we felt a very strong commitment from Snyk that the development of driftctl should continue in the open as a standalone, open-source, community-supported tool. With that in mind, the next natural step was to start anticipating all the benefits that come with such a situation.
Let’s stay down to earth: joining forces with a bigger organization brings one major and immediate benefit: more people and more power to develop your project. All of a sudden, your team is growing 2 or 3-fold. New maintainers come in, with new skills and new ideas that will make your project all the better. Provided a strong cultural and technical fit, you can make wonders. And behold! Within less than 10 days post announcement, we already celebrated a first commit from a new maintainer to the project, highlighting the fact that we were indeed converging as one team around one project.
The other cool thing that you can leverage when joining an organization that is bigger than you, is that the new team is usually one or several steps ahead in their development: globally distributed, with more team members, more users, more paying customers, more partners, etc… This means more social media outreach, more people talking about the tool and all in all more credibility.
The feedback you receive is all the richer too. When building a tool, talking to users is key. It is crucial that you maintain a brutally honest feedback loop. This is incredibly time consuming and requires a lot of connections with relevant teams that will fit your user profiles. Joining a bigger organization gives you the unique opportunity to fuel this pipeline.
Last but not least, in our case the team will start working on Snyk Infrastructure as Code as well. That’s an amazing opportunity to gain different insights and develop new skills. At the end of the day, this additional experience is bound to benefit the original open-source project.
As a team, merging with another one brings some serious challenges. One of the first that comes to mind is about roadmap and technical discussions. As you share the ownership of your original project and prepare for future integrations, you need to align everyone on decisions with strong consequences.
One of the other pressing concerns directly related to open-source projects joining a bigger organization lies in the culture of building in the open. That’s a very tricky issue. Typically, we had decided to build driftctl as a fully transparent open-source project. This means that not only the code was fully available for everyone, but the way we built it as well: issues and discussions are public on GitHub. PRs are open for anyone to review. All internal engineering discussions around the project are public on our community discord. This culture of full transparency was something we wanted and were comfortable with, because it was built upon our belief of what open-source should look like. Joining another organization with a more mature product can make a dent in this culture of building in the open, because protecting the paying product secret sauce is part of the very DNA of the company (especially if this company is part of the key infosec players in the world).
On another level, keeping the community involved, and with a feeling of empowerment and part-ownership of the project is probably one of the most important and difficult challenges. As an individual, it is only too natural to feel some sincere sympathy for a small team solving one of your real issues with an open-source tool. You would naturally wish to help and encourage them as much as you could. Seeing them join a bigger organization might make it lose some of the candid attraction you felt. On the other side of the mirror, as a team member and maintainer of the project, you first need to deal with the period of uncertainty before joining forces and the changes in the new organization afterwards, which makes it very easy to lose your concentration and not take care of your community as much as you should. Again, feeling a genuine support from Snyk to maintain and grow this community is a real help and lets you keep the right focus.
As a conclusion, you could say that making the best of two worlds is all about teamwork and balance. Embracing all upsides from this new situation is easy. To face the challenges, the key is to keep a default positive attitude. As long as you know that everyone shares the same mission, you just need to find the right balance between the constraints of your new organization and what needs to be done. Feeding yourself with the good practices and new projects from the organization you are joining is an amazing opportunity to learn and grow. Keep pushing further.
If you want to read more about that theme, here’s the story of our journey from the creation of an OSS tool to joining forces with Snyk.
Get product updates and occasional news.