.svg)
We’re proud to sponsor KubeCon Europe, happening April 2-4 at the Excel London.
Come see us at Booth S710 to explore the latest trends in cloud management and Infrastructure as Code (IaC) best practices with env0. Don’t forget to grab some great swag and enter our daily raffle—details below!
If you’d like to see envzero in action or discuss your infrastructure management needs, pre-schedule a meeting with our team here.
Explore Our Roadmap and New Features
Drop by to meet our team, including CTO Omry Hay, and discover the latest upgrades to our drift management features. Plus, get an exclusive look at our roadmap and upcoming features.
Don’t Miss OpenTofu Day
We’re excited to sponsor OpenTofu Day, taking place on April 1st. This is a unique opportunity to connect with the OpenTofu community and hear firsthand about the latest developments and real-world use cases.
Be sure to check out these sessions featuring our team:
Grab Some Swag and Join the Raffle
Don’t miss out on our limited-edition swag, including custom T-shirts, stickers, and other surprises. Be sure to enter our raffle for a chance to win a Mercedes-AMG F1 W14 E Performance Race Car LEGO set. Stop by early to secure your swag and get more chances to win!
We’re looking forward to seeing you in London for KubeCon EU 2025! Let’s make this event one to remember!
Related Content
With DevOps Tech Stacks In Flux, Can OpenTofu Maintain Its Growth Momentum?
Why The Collaborative DevOps Community Is Keen On IBM, HashiCorp
The Open Source Summit this year really came at quite the time. The community is truly walking in terra incognita on the heels of OpenTofu’s rise and Terraform’s license change. The issue clearly dominated the thoughts of the speakers, but keynote presentations delivered their own share of news and insights that will have an impact for the foreseeable future.
These are just a few of the things that I personally found interesting from such a long but varied keynote presentation.
1. The Open Source Model is More Resilient Than I Thought
Throughout the keynote, multiple appearances from open-source software (OSS) contributors and enterprise execs showed both a commitment to and maybe even dependency on open-source models for software development. Crowdsourced projects are so pervasive now that they are both impossible to ignore and are embedded into many companies’ own strategies for growth.
Examples were pervasive throughout the conference. For one, Terraform’s licensing change sent ripple effects throughout the business world, provoking an enthusiastic response for OpenTofu.
Other noticeable effects were the several major initiatives that are turning lofty goals into accessible action items. New foundations are forming based on the success (and clear influence) of others like the Linux Foundation and the CNCF.
2. BSL License Changes Could Be A Blessing In Disguise
They’re definitely not good per se, but it’s important to put into perspective just how much risk the BSL license change poses to the free and open-source software (FOSS) ecosystem’s future.
This was Jim Zemlin’s premise on stage when he whipped out a graph showing only nine instances of “a commercial company that owned the copyright in a popular open source project, that changed it from an open-source license to a commercial license.”
The number is much more modest than I expected. That said, I don’t want to minimize the impact of who made these changes: Elastic.co, Hashicorp and other there are all BIG names with consequential software in the industry.
Notably, Elastic’s change brought about OpenSearch, backed by AWS, and this strongly parallels what’s happening now with HashiCorp and OpenTofu. So the context here is important, and the number of companies is only a part of a bigger story, and sometimes closing the door means opening a window (or a fork).
It’s also worth noting that having full copyright control over something was a big qualifier here, so less-than-total changes weren’t on the list. For instance, this ends up excluding Red Hat’s unpopular changes to its Linux distribution in July (and a $10 million commitment from SUSE to fork that distro). In 2020, Anaconda introduced a version with a commercial license that capped how many downloads you could make for free.
3. Allianz and ExpressVPN Plan to Migrate to OpenTofu
These are the two big names to join the project. Terraform’s license change took the business world by surprise, forcing companies to think fast and to follow their engineers’ lead in forming an open-source response.
Reps from Allianz and ExpressVPN took the stage to talk about how the Terraform announcement pushed them into the arms of OpenTofu as well as doubling down a commitment to other open-source projects. ExpressVPN brought up how it open-sourced its own VPN protocol, Lightway.
The most important quote came from Allianz’s David Bejar (and should be quoted by other pro-OSS companies going forward):
“We had invested millions of euros developing Terraform code. So when there was this change of license, we were wondering, ‘Is this still the right way to secure the future of our customers... Now with the announcement of OpenTofu, we are so happy to be contributing and to pivot to OpenTofu.”
4. The UXL Foundation (Unified Acceleration Foundation)
With the growth of LLMs, demand for accelerated computing is eclipsing that for general-purpose computing. As a result, there’s a new initiative to organize accelerated computing development as the industry breaks out.
The foundation unifies standards around accelerated computing and already includes Samsung, Google Cloud, Intel, Qualcomm, Fujitsu, Imagination, and Arm. It’s an outgrowth of the oneAPI initiative that has pushed for standardizing API specs for open-source projects.
.png)
5. The Linux Foundation Committing to Sustainability
It was unexpected to hear how open-source software is actually having a measurable influence in fighting poverty and hunger, among other objectives. The Linux Foundation has noticed that their incubated projects are having that kind of impact, now aligning itself with contributing to the United Nations Sustainable Development Goals (SDGs).
Linux presented its Open Source for Sustainability report, using it to map how its open-source projects can make a direct impact in reducing poverty, satiating hunger, and accessing education. The list of organizations and companies contributing to those projects includes the AgStack Foundation and OS-Climate.
6. Governments are Investing into Open Source
Fiona Krakenburger and Tara Tarakiyee spoke about Germany’s Sovereign Tech Fund, contributing around €3.5 million per year to major infrastructure projects. They also offer €300,000 for companies/organizations participating in special challenges to sure up FOSS developer tools, software production, and infra documentation.
It only launched in 2022, born from Germany’s realization that open-source-based infrastructure was everywhere or that open-source tech is really at the heart of pervasive software that’s having an impact culturally and in people’s day-to-day lives.
Their biggest contribution to date has been a €875,000 grant to the OpenJS Foundation to bolster the Javascript ecosystem in particular. They’ve also given to OpenSSH, Bundler/RubyGems, Fortran Lang, OpenBGPd, OpenMLS, Wireguard, Curl, SequoiaPGP, and OpenPGP.js.
It’s refreshing — and a relief — to know the role of OSS is finally getting a chance to shine. Open-source is reliant on the time and resources volunteers have, and the growth of public funding is a sure sign it can become a permanent budget priority for other countries around the world.
Bonus: Hearing Community Reactions to OpenTofu
I didn’t get to Bilbao in person but my colleagues were there as reps for the OpenTofu project, including Omry Hay — our CTO who is now part of the project’s steering committee.
One of the things they did was to interview some of the experts from across the industry who were on hand at the conference, asking them about their thoughts and hopes for the Terraform fork. Here is what they had to say:
I think this takeaway from Andrew Martin, the CEO of ControlPlane, wraps things up nicely for me:
“It is the community's imperative to take that code that sits open and in the commons and do with it as they will…to open up the fork for the free usage of everybody and to move the project forward in the way that the community desires.”
What the Fork?! My 6 Takeaways from the Linux Foundation Keynote at OSS 2023
Updates:
----------------------------------
September 12th, 2024: OpenTofu registry UI goes live!
July 29th, 2024: OpenTofu v1.8 adds variables support in backend configurations, .tofu files and other new features.
April 30th, 2024: OpenTofu v1.7 is live, introducing state file encryption!
January 10th, 2024: OpenTofu hits GA. env zero rolls out CI Testing (utilizing [.code]tofu test[.code]).
December 19th, 2023: OpenTofu stable release candidate is out, sights set on January 10 for GA release!
Nov 30th, 2023: OpenTofu 1.6.0 beta release brings with it anew public open-source registry.
October 4th, 2023: OpenTofu alpha goes live. env zero rolls out a 3-cick integration option for testing.
September 20th, 2023: OpenTF joins the Linux Foundation and changes it's name to OpenTofu.
September 5th, 2023: The OpenTF repo goes public, after our manifesto reaches over 32K GitHub stars.
August 25th, 2023: The OpenTF initiative officially announces an open-source fork of Terraform.
----------------------------------
On August 10, 2023, HashiCorp announced a change of license for its products, including Terraform. After ~9 years of Terraform being open source under the MPL v2 license, it was to move under a non-open source BSL v1.1 license, starting from the next (1.6) version.
It is our belief that under the business license, the future of Terraform looks bleak. Community focus will shift, businesses will start looking for OSS alternatives, and independent tooling will gradually disappear.
Simply put, the license is a poison pill for the Terraform ecosystem. One that will also have a ripple effect on other open-source projects, and undermine the credibility of open-source as a concept.
With this in mind, we are proud to be one of the first companies to join together in OpenTF, an initiative to keep Terraform open source–forever. So far we are joined by over 100 organizations, and hundreds of individual developers, all of whom pledged to contribute to the project. The GitHub repo hosting the OpenTF manifest has over 2,200 stars as of August 23rd.
As for our platform (unless HashiCorp reverts their decision), env zero will not work with any BSL-licensed versions of Terraform, which means that:
- As long as you use Terraform 1.5.x or older, you don’t need to take any action, as these versions are all MPL licensed.
- For future versions of Terraform, as OpenTF will be compatible with Terraform, you won’t need to change any code. The only difference is that env zero will run the OpenTF binary in the background, instead of the Terraform binary.
The Open Source Future of Terraform
We are proud to help make OpenTF a reality. The future of OSS Terraform is:
- Truly open source - under a well-known and widely-accepted license that companies can trust, and isn't subject to the whims of a single vendor
- Community-driven - so that the community governs the project and pull requests are regularly reviewed and accepted, based on merit
- Impartial - so that valuable features and fixes are accepted based on their value to the community, regardless of their impact on any particular vendor
- Layered and modular - with a programmer-friendly project structure to encourage building on top, enabling a new vibrant ecosystem of tools and integrations
- Backwards-compatible - so that the existing code can drive value for years to come
Together with other key OpenTF supporters, we will commit our resources to ensure this open, sustainable, and inclusive future for an open-source Terraform.
Stay tuned.
What HashiCorp's License Change Means for env zero Customers
When it comes to deploying applications in Kubernetes, it's like having your own Swiss Army knife; you've got a tool for every task. That's where Terraform and Helm come into play, joining Kubernetes to form a mighty trio that can tackle both infrastructure provisioning and application deployment with finesse.
In this post, I’ll demonstrate how these three tools come together, using env zero to create a unified platform that combines Kubernetes scalability with Terraform's provisioning strength and Helm's deployment dexterity.
Terraform, Kubernetes, and Helm: Better Together
The advantage of using Terraform, Kubernetes, and Helm together lies in their synergy, with each tool playing it own part:
- Terraform excels at setting up and managing the infrastructure that Kubernetes runs on, especially with services such as AWS EKS.
- Kubernetes provides the orchestration and management layer for your containerized applications, ensuring they run as intended.
- Helm takes over the application deployment aspect, making it easy to package, deploy, and manage applications in Kubernetes.
Granted, Terraform can deploy applications directly into Kubernetes clusters using its Helm provider, so technically speaking, you can manage both your infrastructure and applications through Terraform scripts.
However, for more effective lifecycle management of applications, it's advisable to keep the responsibilities of infrastructure setup and application deployment distinct, because:
- It aligns with the best practices of modern development, allowing for a clear division of concerns and making it easier to manage changes and updates between teams.
- It establishes a seamless workflow with Terraform, used to automate the creation of Kubernetes clusters, Kubernetes serving as the runtime environment, and Helm working to streamline the deployment process.
- It enables us to use Kubernetes-native tools (in our case, Helm), that are finely tuned to “understand” Kubernetes' architecture, offering the ability to perform rollbacks, conduct easy updates, manage application releases effectively, etc.
How to Streamline Kubernetes Deployments with env0
Requirements
- A GitHub account
- Access to an AWS account
- An env zero account
TLDR: You can find the main repo here.
Note: Terraform can deploy applications directly into Kubernetes clusters using its Helm provider or its Kubernetes provider, so technically speaking, you can manage both your infrastructure and applications through Terraform scripts. However, you will find this tedious and not as efficient, and also not aligned to the k8s best practices I describe below.
Integrating Terraform and Helm with env0
Now let’s jump into a demo in which we’ll use Terraform to provision a managed Kubernetes cluster in AWS (EKS) and then utilize Helm to deploy the Prometheus and Grafana applications, with env zero providing the common workflow for both, like so:
For further reference, below is our repo's folder structure. Notice that we have a folder that contains all of our Terraform configuration files.
EKS cluster provisioning with Terraform template
Let's start by creating a new project in env zero and calling it Env0-Kubernetes-Prometheus-Grafana.
Next, create a Terraform template for setting up an EKS cluster. Head over to the Templates tab on the left navigation bar create a new Template of type Terraform and fill out the fields as required.
Select the GitHub Repo and remember to select Terraform in the Terraform Folder field.
You won't need to fill out anything in the variables tab. Finally, add this template to the project.
Make sure to add your AWS credentials in the organization settings and then reference them in the Credentials tab in the Project Settings section.
Now go ahead and create a new environment referencing this newly created template from the Project Environments tab within your Project.
Of course, you will need to approve the Terraform plan before the [.code]terraform apply[.code] could run. This process will take over 20 minutes so grab a coffee while you wait for your cluster, or continue with the Helm templates below.
Application deployment via Helm template
It's now time to create our Helm templates in env zero for both Prometheus and Grafana.
1. Create the Helm templates in env0
Similar to what we did for the Terraform template, do the same for Prometheus first then Grafana.
Note that now we will select the Helm template and under the VCS tab, you will need to reference the Helm Repo and specify the Helm chart repository along with the Helm chart version and chart name as shown below for Prometheus.
And here is what it looks like for Grafana:
Once again, you won't need to fill out any variables. If you need to modify the values file for the helm release you can add Environment variables in env0, but we won't need that for our demo.
Make sure to add these two templates to your project.
2. Add k8s cluster credentials
Once the Environment we created with Terraform is complete and the EKS cluster is created, we can add the Kubernetes credentials as shown below:
Notice that the cluster name needs to match the cluster name we created in EKS and needs to be in the same region. You can read more about this in env0's documentation.
Your project Settings page and the Credentials tab should look like the image above.
3. Use Helm templates to create two environments
Now we can create two more environments in our project using the two Helm templates we created.
This will deploy our Prometheus and Grafana applications. Just make sure to leave the Namespace field empty as shown below and give a name to the release. This will deploy the applications to the default namespace in our Kubernetes cluster.
4. Review project environments
By now you should have three active environments: one from the Terraform template and two from the Helm templates, as shown below.
Also, your organization templates should look like this:
4. Connect the EKS cluster
From the Grafana or the Prometheus environment deployment log, you can find the [.code]aws cli[.code]command to access the cluster:
Let's run some commands from our cli to check on our cluster. Get the nodes:
Check the running pods. You can see Grafana and Prometheus pods running.
Check the Helm charts installed.
Check the status of the Grafana chart to retrieve the initial admin password.
Retrieve the password.
Expose port 3000 on your host machine to access the Grafana dashboard.
5. Access the Grafana dashboard
Now let's connect Grafana to Prometheus. First, we'll need to log in. Go to [.code]http://127.0.0.1:3000[.code] in your browser and you'll be greeted with the login page for Grafana:
6. Connect Prometheus as a data source for Grafana
Next, go to the Data sources tab under Connections on the left navigation bar to add Prometheus as a data source for Grafana. Make sure to use the Prometheus server URL of: [.code]http://prometheus-server[.code] then click the Save and Test button at the bottom.
7. Run a query to test
Let's finally run a query in Grafana to see that the application is working. Go to the Explore tab on the left navigation bar and select a metric. I selected [.code]node_memory_Active_file_bytes[.code] as an example. Then hit the blue button at the top right called Run Query. You should get a graph at the bottom showing that our application is working.
Congratulations!! You've just automated the process of creating an EKS cluster with Terraform and deployed a monitoring stack into the cluster using Helm charts. Moreover, this was all done with one platform, env0, that offers the same workflow for infrastructure provisioning and application deployment.
Clean-Up
You can simply destroy the environments in reverse order of how we created them. So go ahead and destroy the Grafana and Prometheus environments, then the Terraform one. That will clean up everything nicely for you.
Best Practices for Kubernetes Deployments
In the above demo, we saw how env zero stepped in to make managing Kubernetes infrastructure and application deployment a breeze. By providing a cohesive environment for leveraging Terraform and Helm, env zero ensures your deployments are streamlined and efficient.
Here is how this plays into general Kubernetes best practices:
1. Embracing a Layered Deployment Strategy
env zero amplifies the effectiveness of using a layered deployment strategy. By managing Terraform for infrastructure and Helm for applications through env0, you establish a clear division of responsibilities. This not only aids in maintenance and updates but also ensures that each layer is optimized for its specific role in the deployment process. env0's dashboard and automation capabilities provide a unified view and control over these layers, making it easier to manage complex Kubernetes environments and Kubrenetes resources.
2. Streamlining Costs and Performance
With env0, you can monitor and optimize your deployments directly. env zero provides insights into resource utilization and costs, helping you make informed decisions on scaling and optimizing your infrastructure for both performance and cost-effectiveness. This means you're not just deploying efficiently with Terraform and Helm; you're also continuously improving your deployments based on real-world data.
3. Enhancing Security and Compliance
Leveraging env0's capabilities ensures that security is baked into your deployment process from the start. With env0, you can enforce policies and ensure that every deployment adheres to your security standards, including the use of minimal base images, implementing RBAC, and encrypting sensitive data. env0's policy enforcement ensures that your Kubernetes resources and deployments are not just efficient and cost-effective, but also secure.
4. Seamless Workflow Integration
env zero integrates into your existing workflows, connecting with Terraform to automate Kubernetes cluster creation and with Helm to streamline application deployments. This establishes a seamless workflow where infrastructure creation, application deployment, and management are all automated, reducing manual errors and saving valuable time.
Conclusion
To wrap up: leveraging env zero alongside Terraform and Helm not only aligns with but also enhances best practices for managing Kubernetes resources and deployments. From embracing GitOps to optimizing for cost and performance, and ensuring a secure, layered deployment strategy, env zero acts as the linchpin that brings it all together. It’s about making your Kubernetes deployments not just possible, but efficient, manageable, and aligned with the best practices that drive modern cloud-native development.
By integrating env zero into your Kubernetes deployment strategy, you're not just following best practices; you're setting a new standard for excellence in deployment and management, ensuring your infrastructure and applications are as robust, efficient, and secure as possible.
Using Terraform, Kubernetes, and Helm: The Power Trio
Just about a week ago, we hosted a panel of industry experts to discuss the GA release of OpenTofu. The panel of experts included our CEO Ohad Maislish, Dotan Horovitz from Logz.io, Andrew Martin from ControlPlane, and Anders Eknert from Styra.
The ensuing discussion unfolded as an interesting and engaging exchange, with topics spanning from evaluating open-source tools to considerations for licensing in engineering activities, and the potential macro implications of Terrafrom’s licensing shift.
It was a great listen! In case you missed it, check out the recording below.
PS, The Q&A session was particularly interesting. If you only have a moment, jump straight to [55:50] and enjoy!
---------------
Transcript
Sharone Zitzman:
This is a community discussion. This isn't anything overly formal. So, anybody who wants to chime in and share their thoughts and speak about what's happening in the open source community, the OpenTofu community is welcome to request to speak. I will be more than happy to have to hear from our entire community.
We're gathered here today to mark a very significant milestone in the evolution of open source. I historically have been known to be an open source and outspoken open source advocate with the posts in the new stack and things when open search dropped and other things. And I've had, you know, opinions on the sustainability of open source on the changing of business licenses and other trends that are impacting the world of open source.
And if you've been involved in the DevOps cloud, native open source community space, like our panelists who are joining us and I'll introduce shortly, it was very hard to miss a major moment for our community, which was the changing of the HashiCorp open source license from MPL version two to BSL, version 1.1 in August, which is a source available. I believe were considered less open source, and HashiCorp is historically been kind of the poster child of open source.
So this was a major moment and out of this came the OpenTofu project, which is essentially the Terraform fork. In August it was forked and then it was contributed to the Linux foundation. If I believe I'm correct, in September, you can find all of that historical information on opentofu.org and other folks have been covering it too.
We have Ohad Maislish from env zero who were posted about it and Dotan Horovits is on this call, also posted about the forking of the project. And here we are a few months later, and we're thrilled to announce that OpenTofu is now generally available with GA today. So congrats to everyone who contributed. It's a big milestone. It was an incredible journey. Really incredible to see this project GA so quickly.
So today we're going to talk a little bit about what it takes to build a successful open source project, the trials and tribulations of open source. And we have an incredibly esteemed panel with us and folks that we'd love to have chime in.
So as we get started, let's introduce our panelists. So the ones that are here with us, we have a few more that are supposed to be joining. I see that Andrew actually is here. So he's been invited to speak. And so without further ado, I'd like to introduce the folks that are going to be on the panel today and other folks are welcome to join and chime in.
So Dotan Horovits, Tell us a little bit about yourself, your journey in the open source space and why you're excited about OpenTofu. Then we're going to go to Ohad and then Dotan. Ohad.
Ohad Maislish @env0:
He might be on mute. So hi, everybody. Great seeing y'all here. My name is Ohad Maislish, co-founder and CEO at env0. Yeah, we are from like 2 hours after the license change announcement of HashiCorp started working on the OpenTF, then OpenTofu, and I'm extremely, extremely excited that today our boy is going to a high school or university or something like that graduated and now being part of a mature community of successful open source projects, it's a very important day for the open source community.
Sharone Zitzman:
Yes, I couldn't agree more. I think this is a huge milestone. I think some of us are open source folks. We're a little bit skeptical. When we first heard about OpenTofu. But this journey has been truly remarkable. And so without further ado, I'd like to introduce Anders Eknert who is from Styra.
Styra are the folks behind OPA, right, Open Policy. So tell us a little bit about yourself and kind of your journey also in the open source space, a little bit behind your work for the CNCF and OPA and other.
Anders Eknert @Styra:
I've been involved in the OPA project for at least four years, I think almost five. I started out looking for something to solve, offer a session, and I kind of opened at the KubeCon in Barcelona. Was it 2019, I think. And yeah, continue down that path. Ever since.
So so yeah. And of course like my relationship to with Terraform or OpenTofu also comes from kind of from that angle since OPA has been like insta less pervasive basically everywhere in there and the IaC community. So we're I'd say were the policy engine of choice for most people working with Terraform or OpenTofu so and that's me.
Sharone Zitzman:
Andrew on to you from Control Plane CEO and also deeply involved in CNCF community. love to hear a little bit more about your journey and thoughts and other things.
Andrew Martin @Control Plane:
Good evening from London. I've been a long time Terraform user. I've been deeply technical throughout my career and the advent of Infrastructure-as-Code and at the class of sense as opposed to this balance between the class from procedural always swings one way or the other.
Terraform turned up and gave us something to base security, static analysis, and ultimately a more effective way of detecting configuration drift. And it has become such a centralized part of so many deployments that seeing this community reaction, seeing the open source advocates gather around and jump on what is ultimately probably one of the quickest release cycles in the history of software in general, especially something that is considered critical so many organizations is astounding.
Super stoked to see this linchpin of so many different organizations back to being open source, not just open. What was it source available, I think. Is this the new framing?
Open source involves freedom. Free and open source is what we dedicate our careers and our spare time to. So very, very pleased. I'm very happy to be here.
Sharone Zitzman:
I know that Dotan is an avid podcaster, so I expect him to give us a really good opening. And so Dotan doesn't need much introduction, but I personally am proud of Dotan as our personal CNCF ambassador in Tel Aviv. So take it away Dotan.
Dotan Horovitz @Logz.io:
Great to be here. And yeah, we're following this project for since it's initiation and so excited I think is set for me incredibly fast to reach from the original. Not even the fork.
Even the manifesto, when it came out all the way through to GA, especially through also teaming up with the foundation. And, you know, also CNCF ambassadors and laying the foundations inside and out. It tells you that marriage, but also with its bureaucracy and the process of crossing this chasm as well and being able to achieve the GA within the Linux Foundation, it's a foundation, open source. That's a tremendous achievement, so way to go, everyone.
Sharone Zitzman:
So, yes, really exciting time for everyone here. I guess we're going to touch a little bit on everything that's involved with getting an open source project from like, you know, theory to GA especially in a foundation model, which also has its own challenges.
But I think just to kick it off, I think I'm just even going to read from the OpenTofu GA blog post today. It's a little bit about the things that were released, the new features and things to look forward to. And then I'm going to ask Ohad, who's actually an integral part of the project, and he can also identify anybody in the crowd who's contributing to the project to maybe tell us a little bit about what was involved with rolling out all of this and what's coming next. So much to look forward to in all of that.
So just to quickly quote from the blog post, the new features being released in OpenTofu 1.6.0, that comes with a bunch of new stuff. So there is the testing feature that lets you test your OpenTofu configurations and lets module authors test those modules, which is awesome.
The S3 state back end, which is a big deal to the community. Who is really looking forward to it. That's pretty awesome. And the new provider and module registry which follows a Homebrew-like architecture and is fully based on a git repository. So very cool stuff coming out in the very first GA.
I want to unpack those a little for us Ohad, and tell us a little bit about why those are exciting, what went into building those and what we can look forward to in the next versions?
Ohad Maislish @env0:
I think what the community has seen today is the ability to deliver. It's very important to gradually and carefully build credibility with the community. And everything you mentioned, I think is extremely important for us to prove that we deliver as a new entity.
You know, for us, it was a new experience to join other amazing companies.
I'd like to shout out some of our official competition, but here we collaborate extremely well on behalf of this project Spacelift, Scalr, Harness. It is also very important to mention the folks behind Terragrunt and many others who decided to keep the Terraform ecosystem open source forever.
I think maybe even more important than what we are doing here in OpenTofu is to see other projects and other companies embrace OpenTofu. I think very important projects are Alpine and Brew, so if you're using Mac and you use Brew Install in order to install your software, Brew Install now supports OpenTofu and actually limits the Terraform installation to the latest open source, which is 1.7. So everybody is using Brew. If you write Brew Install Terraform, you get 1.5 right? Brew Install OpenTofu, you get 1.6 and later 1.7 and so on and so on.
So I think it's very important to see not just what's going on within the OpenTofu project but in the entire ecosystem and how everybody is going with the trajectory of open source. And not like what Andrew said earlier, he mentioned the source available, which is kind of a new concept that it was being used. And I think the power of open source compared to source available exactly as Andrew mentioned and is now something that we cannot see the results of.
Sharone Zitzman:
It's awesome. So we'll get to what's coming next also. That's all really exciting. And I agree the delivery is extremely important. I'd like to tap into our other panelists and I guess you guys can determine what you think? What do you think about the kind of forks that have come out of the HashiCorp change? So one is OpenTofu that was that was GA today. There's also OpenBao from IBM. And how do you see this all playing out? Happy to hear your thoughts, Anders.
Anders Eknert @Styra:
I think, like others said, it's an exciting development. I've always been a strong supporter of open source and like, yeah, it's to me it's like that. This whole community aspect.
I understand like organizations need to make money as well, but it just didn't sit right with me with this whole change of license, no matter like I know it's in there for the right. But I think to kind of to build a community on the premise of open source and then kind of pull that rug and it didn't sit right with me.
So I'm very excited to see these projects continuing on and on the open source trajectory, although under different stewardship. So super, super excited about it, even though I'm not currently like I'm a big user of any of these projects, but I'm definitely involved in the larger ecosystem around them. So very excited and big congratulations to everyone involved.
Sharone Zitzman:
Dotan, I'd love to hear your thoughts on you guys kind of at logz.io and you know, as CNCF ambassador in an open source person in the community have also undergone other similar stories with ElasticSearch and their change of licenses, I'd love to hear your thoughts on kind of that evolution in this space and what's happening and what you see going forward.
Dotan Horovitz @Logz.io:
We've been through that also with my current company, with logz.io more than once. You mentioned that with ElasticSearch, that was quite an adventure. And then also with a change of license and a different type of change of license within the open source realm to a copyleft type of license, which is another piece there. And in some others. So definitely been through the cycle a few times before. And by the way, for those who don't know with ElasticSearch, it also ended up with a fork called Open Search. So similar but also different in some respects.
So I think it's something that I expect us to see not less of this year now that we are at the beginning of 2024. It is something that seems to be a trend, a defensive way of companies, as soon as they reach a certain maturity level to switch over from open source. Obviously I'm saying that with every growth being an open source ambassador but it seems to be sort of something. I don't know if it's the pressure from it, from the venture capital world or, the financial situation or what.
But on the other hand, I think the encouraging thing is to see the community stepping up, and this is an incredible opportunity. Ohad mentioned that you can actually see competitors on the commercial side of the house, then teaming up and joining forces to keep this Terraform open. This is the power of hope. It's the ability to bring together different vendors and also end users. And we see Harness and others joining later on in the OpenTofu realm. And building up an incredible pace really in less than half the year to reach stability is incredible.
So I think the most important thing is to realize this is something that is not sporadic, by the way, and others, each one with its own domain. And I think we need to as users, also as end users for those out there we know, evaluate open source and use open source to do that. With this in mind, just like you take other considerations in mind when you choose an open source and use it like security and operability and other things. This should also be part of your evaluation and part of your way of creating automations. Guardrails.
Sharone Zitzman:
Interesting to tap into it a little bit in a little bit, but I also would want to hear your thoughts on kind of what OpenTofu can learn from the open source, Open Search work and other kind of things that you've learned on the way. But I'd love to hear your take, Andrew, as well. Like what you're seeing, what you're thinking. How do you feel about forks and what do you expect to happen going forward kind of in the open source ecosystem?
Andrew Martin @Control Plane:
I am all for forks. We saw the same kind of thing happened with node.js maybe 2016, I guess, where Node.js was already managed in a community sense. So it was truly community project that the stewardship was agreed by committee. There were structures in place that actually would OpenTofu into the Linux Foundation.
The advantages in terms of open governance and freedom of contribution, vendor neutrality, were all broadly there and in the Node.js world. But there were some fundamental differences and there was an IO.js fork now that really brought into sharp relief the differences between the two groups of maintainers and they were able to go forward. This was on a technical basis and then they got a license, they were able to go forward and then reunify the code bases and join the contributors back up and essentially maintain and bring the velocity of the project onwards.
So forking can be very useful in some cases. In this case, looking at OpenBao, it's an interesting one. Vault is such as I keep using the term critical, but Vault is such a critical part of so many secrets management solutions. And for regulated industries, especially, the cost of deploying a Vault cluster is north of $100,000.
And that's while there's a small amount of extra enterprise feature sparkles on top actually for something so critical that a lack of availability to take down production and give you the expiry length of your keys before everything's got everything is an operable, then I suspect banks will continue to pay for those licenses because they get direct access to HashiCorp support.
So OpenBao, I think, has a lot more necessary conviction just because it's such a mission critical piece of infrastructure more broadly. I mean, when we see these license change escapades where we have a vibrant community, we have people contributing in advocating building tutorials, giving their free time into the project. And then we see this concept of, well, we've got to change. The license is free for you to use until you start making money from your startup. That seems like a bait and switch to the entire open source community.
It's interesting to compare this to the Elastic and cosigner pieces because in those cases we saw major cloud providers re hosting those projects and, you know, barely contributing back upstream, not being good open source contributions in general and making hundreds of millions of dollars from direct competition.
In this case, these forks happens, I think, well before competitors have made significant money at that kind of quantum from Terraform in general. And hashiCorp certainly makes a lot of money from licensing Vault.
So it does make you wonder if this is now a VC-backed play, as Dotan alluded to, There's also the sum of the comments made straight out at the top of HashiCorp. suggest that they don't really understand that the inherent success of these projects has been brought about by the open source ecosystem. And had it not been open source, they would probably not have got to this point.
So big fan of forks - OpenTofu is probably the most successful one that has ever driven stratospherically. So that number of stars. OpenBao sort of remains to be seen instead see how that progresses.
Sharone Zitzman:
I think there's also something to be said about the kind of companies that are backing the initiative. And I think that Open Search was actually quite successful because it had quite a strong backing, corporate backing from a bunch of companies from logz.io to AWS and others. And OpenTofu also has commitment of resources and time and that's and you can see that in the delivery and so OpenBao, well now that was forked by IBM we have to see what is where it's going to go. And so I agree it is yet to be seen how that's going to play out.
Dotan Horovitz @Logz.io:
Parallel here for me. To share on and if I might just chime in for OpenBao it's actually even more interesting because I thought IBM is as corporate as the company. This is a group within IBM that engages in another open source projects under the Linux Foundation and actually found themselves in a very awkward position when the change occurred, when the license change occurred that they couldn't no longer use that within their own project. So they needed to find an alternative and they ultimately went down the path of actually forking and creating this alternative.
So this is actually something that is really, really the classic bottoms up, almost individuals, although they're IBM employees. So I'm just saying it's not. IBM is very interesting to see if IBM takes more formal position in this and obviously if others join. But this is the case. It also exemplifies very well that relicensing is also a problem not just for commercial organizations that make money out of these projects. And therefore and they obviously also blamed for for maybe playing unfair.
This is actually a problem for the open source community itself because if I'm and in the sense if we see that broadly, because in the sense that the policy is largely around the Apache to do so and if any dependency doesn't matter, if it's a library or a tool or anything else, does not adhere to this license, even, by the way, within the realms of other OSI approved licenses, it's still a problem.
And then other open source projects find themselves imposed, especially if it's a copyleft license by a constraints that they haven't chosen. So I'm just saying very, very interesting case that just shows the complexity of this new situation that we're coming into.
Sharone Zitzman:
That's actually a really good point that you bring up, that those dependencies are cascading and then the, you know, the outcomes, everything that happens around these sort of license changes that has so many, you know, has so much impact.
I'd like to actually tap into Anders and Andrew as well, who are both of, I guess, popular open source projects and that are hosted in the CNCF. Andrew Yours is a sandbox project, so be or am I wrong about that? Am I right? I don't remember. But Anders OPA has actually graduated right? It's a it's a longstanding graduated project. Tell us a little bit about the trials and tribulations of having a CNCF guardians and practices.
Anders Eknert @Styra:
So yeah, graduated two years ago, I think, which was after quite a long process of I don't remember all the steps, but there was a long list of requirements and things you had to do, things you had to prove, and so on and so forth. So yeah, that took a lot of, a lot of hard work and effort, but it was, yeah, obviously worth it.
So we've been I think I don't know when, when it became like when, when it joined the CNCF that is, that is before my time and I think like the level of that kind of collaboration or so on depends a lot but like, some of these project they do, like if they do a webinar, they do it under the CNCF, or hosted by CNCF. If they write a blog, they write it under CNCF, properties and so on.
So it really depends a lot of or it really differs a lot between projects, how much you can work with the CNCF and how much you don't. I think we're probably could probably be even better in our collaboration with that. But it’s never been like anything anyone regretted. I think it's been a fruitful collaboration.
Sharone Zitzman:
Thank you it's fantastic. Andrew what are your thoughts and just correct me if I'm wrong, do you guys have a hosted CNCF project? Am I right about that?
Andrew Martin @Control Plane:
We do not. As a result of seeing how much effort it is to maintain things, open source. We've got a flurry of bits of open source security tooling around Kubernetes and network testing and the like. But actually most of the work that I do in the space is via tech security. We've got Eddie Knight here as well, who is a collaborator there. And the goal of tech security is to help to assess and recommend security practices to projects. The looking to ascend through the CNCF.
Governance process, this is, again, one of the key points of having a vendor neutrality and foundational membership, which is that the way we proceed with these is a community of people external to the project coming through, have a high level demo. They'll then go and dig into the docs, they will use the projects and they will build out what they believe is the beginnings of security assessment. They get back to the project and then collaborate on a joint assessment which is then submitted to the technical Oversight Committee and is used as one of the barriers of maturity in order for that project to ascend through the ranks.
This is one of the, as I say, major delineations between running something as an open source project which sits on GitHub with a closed sponsor panel, actually funding the developers doing the work and ultimately with complete control and the ability to make these kind of license changes and something that sits in a foundation.
So the way that the Linux Foundation and specifically the CNCF governs these projects is in order for something to graduate, there must be evidence of multiple contributions from multiple different companies, evidence of community impartiality. The things that we almost take for granted in these well-curated communities that would go a long way to, for example, robust defying.
Not that the project necessarily needs it, but the Terraform open source code and also offering a direct path of mitigation in cases such as this.
Now actually OpenTofu went straight into the Linux Foundation. They reached out and were welcomed with open arms, so we can now look forward to that kind of stewardship for the project.
Sharone Zitzman:
This is where I want to tap into Ohad and I kind of ask him a little bit about his experience with contributing with being on the team that contributes to OpenTofu to the Linux Foundation, some of the challenges you encountered and what do you think will impact your stewardship of this project and the other companies involved in terms of navigating it through this through the Linux Foundation?
Ohad Maislish @env0:
Yeah, thanks, Sharone. I think we're all positioned in the ideal situation here. We already have a very mature ecosystem of providers and let's say the AWS provider, which is open source, with Datadog and Okta providers and so on, so on. The modules, all of the AWS modules and other modules already existing as open source, they all ready work as is with OpenTofu. So we are already in a very good place to continue and support this, this project.
Besides the resources of OpenTofu as I mentioned the providers and modules, there other things that work hand in hand. OPA is a great example that works with Terraform and same with OpenTofu InfraCost, for cost estimation, Checkov tfsec, Terrascan. So OpenTofu is a unique example of something that from day one already has a very mature ecosystem of adjacent solutions and technologies. So that's really important to mention when we think about the future of such a project and to look at that in that context.
And another thing I think it's really important to share with our audience is how OpenTofu works as a project. So besides just announcing 1.6 GA another thing that the team had to do is to create the alternative for the Terraform Registry. Not sure if you're all aware of a few days after the license change of Terraform Framework itself, the HashiCorp also announced that actually they didn’t announce but they just changed the terms and conditions of the Terraform Registry.
And the beautiful thing that happened is that in OpenTofu there were, if I remember correctly, four ideas, different ideas on how to implement the new registry, the open registry that anybody can use without any limitations. And we went to the community and read our request for comments and we gave about 10 or 14 days for everybody to try to suggest how they think the new registry should be implemented. And we acted accordingly.
Also we have a technical steering committee and everything is so transparent and impartial and community driven. So I think now that we see that we have all of those foundations within this project, I am 1,000% assured that this will continue in the right direction, working hand in hand with the community.
Sharone Zitzman:
Incredible work to everyone who contributed. We have some really awesome folks in the audience and I thought that this is going to be a community discussion. So for those who would like to chime in and kind of give your thoughts on what you think about kind of what's happening in the OpenTofu kind of ecosystem or even the CNCF landscape and a little bit on the OpenTofu GA dropping.
Eddie Knight thanks for joining us. I see that you're requested to speak. Feel free to let us know what you're thinking about. You know, the OpenTofu community and maybe adoption or in general kind of the new project. And what are your thoughts and experiences?
Eddie Knight (OSPO Lead @Sonatype):
Hey, so in addition to collaborating with Andrew, inside of CNCF if I'm a maintainer for FINOS, which is a another Linux foundation focused on financial services, financial services vertical. So I used to work inside of a couple of different major investment banks and now I work for Sonatype or open source security, but because I'm still a maintainer for the FINOS organization, I'm doing a lot of work related to infrastructure deployment for financial services.
The interesting thing for me is that there hasn't been a strong response to the license change, but there has been a lot of strong interest, especially in the potential for reducing spend on things such as Terraform Enterprise. And so I was curious if anybody wanted to spend a few seconds just kind of an update or kind of casting vision for OpenBao, if that's something that we could talk about a little bit?
Sharone Zitzman:
Sure. I don't consider myself very knowledgeable. It sounds like Dotan is a little bit about OpenBao, so feel free to go for it Dotan, if you have answers there.
Dotan Horovitz @Logz.io:
Well, first of all, I'm not a security expert. I think here are actually Andrew and others, but also from the security angle and the best approach, obviously. But in terms of the open source path, I think the challenge there is, as I said, that there's still no major entity that stepped up to to address it.
I guess a side benefit is the fact that since it came out of the project that is under the Linux Foundation or under the LF edge for those who know Linux Foundation edge that discusses these technologies. So in a way it's by definition somehow under the umbrella of the Linux Foundation, but it's very technical administrative aspect in the real sense.
I think it still needs to be to prove itself that other join and similar dynamics as we've seen very successfully hearing with OpenTofu with vendors that are deeply vested, that actually put full time engineering development resources and other types of resources, marketing and so on to to make it successful.
This is, I think from my experience with open source and also looking at my capacity within the CNCF the a core pillar of the sustainability of projects, let alone in the very early stages when it's really trying to make its first steps in the world is about creating this this momentum and later on the the diversity. So it's great to see that with OpenTofu and with OpenBao we’re way earlier in the stages. And we need to see even if as I said even if IBM itself as a corporate tool will back it up formally and not just these individuals that are involved through the open LF, the LF project.
That's my take on the open source. But if you're talking about like feature set and capabilities around the the security, I’ll leave it for the security experts here in the crowd.
Eddie Knight @Sonatype:
No. that answers my question very, very well. I think the biggest focus is more on what is the trajectory for this whole ecosystem. Right. To be able to enable the adoption at those higher level organizations that are looking for that full feature set. And so this step today is huge, huge, huge. And I'm wondering what's next. And I think you just answered that really clearly. Thank you.
Sharone Zitzman:
Sure. Awesome. Thanks so much for chiming in and thanks for that excellent answer. I think one of the things that a lot of folks are probably asking this goes to everyone kind of on the panel, Ohad, probably because you're inside the project, and Dotan as the CNCF ambassador and Andrew and Anders.
But what do you think would be involved? You know, this is even almost a DevOps question, I guess. And IaC question what is involved with migrating to OpenTofu? What is the likelihood, what you what are the barriers or the blockers for people to actually start adopting OpenTofu?
What do you think needs to kind of happen in order for this to gain a little bit more momentum in terms of more more so the kind of what you're speaking about enterprise adoption versus like open source projects and things like that, which I also think is already impressive as it is that some projects are already moving ahead and adopting OpenTofu. But in terms of more widespread adoption, I guess.
Ohad Maislish @env0:
So the beautiful thing is that those organizations actually don't need to do anything in order to start using OpenTofu. And it's the same protocol, it's the same kind of language that is Terraform.
I remember Kelsey Hightower writing in his Twitter posting on his Twitter after we announced the fork that it's like a HTP protocol in browser. And so you have different browsers that implement the same protocol. I think all in all and you will see now with the GA more and more adoption of using an open source framework binary that is fully compatible, that has no and legalized whatsoever and adopted by the community.
And as time goes by, We're going to see more and more innovation and more and more community-driven involvement in this project. And this will gradually bring more and more enterprises by default. Enterprises are in their wait and see mode, and I think Terragrant and OPA are great examples of amazing open sources that were created by and supported not by an AWS or IBM, but just by a smart group of people and enterprises gradually implemented those technologies in production.
So I'm sure that we're going to see the same here because unlike migrating from Terraform to Pulumi or from Terraform to CrossPlane, which is a lot of work and education for the engineers that need to learn different concepts and different providers and to be aware of so many different technologies to migrate that I'm not sure that's the right tool to migrate from. Terraform from OpenTofu basically means just execute a different command.
Sharone Zitzman:
Interesting. And do you think that there are going to be any concerns around, I guess, fragmentation going forward at some point? I mean, it's called a fork because I mean, it is kind of a fork in the road. Do you think that there's going to be a point at which, you know, it's not going to be backward compatible with Terraform or where there will be those types of kind of decisions that you'll need to make?
Ohad Maislish @env0:
It's important to remind us all that Terraform is already nine years old. If you just look at the GitHub insights of this project, you're going to see a lot of development in the past. But in the last few years, it has been a pretty stable project. So there is actually not that much complexity in order to continue pushing this project forward.
And I think whatever happens in Terraform, which makes sense for the community, the community will push forward the right decisions for OpenTofu. So, I believe that it will be compatible plus meaning whatever is needed in Terraform will exist in OpenTofu thanks to our developers and the community.
And more than that, for example, state encryption, I think is a very, very interesting example of something that is, let's say, probably coming to OpenTofu sooner than Terraform, and that's due to the fact that we have fabulous folks from the community who just wanted to put that inside OpenTofu, and it makes sense to have this capability in the in this framework.
So we going to see, I think, both compatible and additional innovation in case you want to use specific capabilities of OpenTofu. I think it's a very reasonable challenge for us behind OpenTofu because as I mentioned, it's not as complicated as it used to be a few years ago.
And also if we look at the providers, AWS provider, Azure provider. AWS and Azure always have new resources, so you always have to work in order to maintain those providers due to the innovation of the cloud vendors themselves. In Terraform framework, in Terraform core the situation is different. AWS Innovation doesn't affect the capabilities of Terraform core, Terraform core, just has its own innovation.
Again, as I mentioned, nine years old, it's very mature. So my personal opinion is that we're going to see both compatibility due to the reasonable challenge that we have here and innovation coming from the community.
Sharone Zitzman:
Very interesting. I guess I did want to come back to this question. So I feel like I asked in the context of the CNCF, so I'm going to direct this one to you Dotan, but a little bit about what OpenTofu can learn from other projects. Like you've been very experienced in what you said, like open Open Search and all of that kind of landscape. If you have a few tips for the OpenTofu maintainers and things to pay attention to.
Dotan Horovitz @Logz.io:
Certainly. So first of all, I think many other efforts can learn from OpenTofu, as I said, like the speed and the like very early on identifying that the path through that foundation, open source or very keen insights, OpenSearch just as an example up till now more veteran and still has not joined the foundation and is opening up slower than that.
So definitely these are success stories. I think that diversity I touched and eluded to that before is very important, a healthy mix between vendors and end users is something I think I highlighted earlier. I you know, in OpenTofu’s journey as well in one of my tweets, but essentially making sure that it's not just vendors discussing between themselves and mitigating the needs of their own respective products into the project, but rather also factoring in the directly the end users and making them an essential part of that.
I think these are the main things to the sustainability of the projects in going forward and was the initial, I think you touched about a bit about that before in your questions because the initial statement was about compatibility with Terraform, not just on the first version, but also going forward like will it be compatible? Is this like a mission statement of OpenTofu, or OpenTF, as it was originally coined? And it's something that I was concerned about at the beginning.
I told him it doesn't make sense to even claim that these are going to be independent projects and trying to create this tight coupling will actually cripple the project. So I'm glad to see now what Ohad said a much more coherent message saying we will very discriminately examine the value of each of the features that is added to Terraform.
And if there's relevance to our community then we'll see how to adopt it. I think by the way, a great example with the testing capability that was added to Terraform at 1.6 that was obviously not able to fork, but it was adapted to OpenTofu in this version. I think it's a good example as well.
So I think these are the main things to make sure that the project goes on and maybe worthwhile saying a few words if Ohad wishes to say about the roadmap ahead what we expected. So now it's for alignment with the 1.6 obviously, plus the things that we mentioned. But where do they see this heading forward? The list of the main themes that would be maybe interesting for our audience?
Ohad Maislish @env0:
Yeah, thanks Dotan. Although I'm heavily involved supporting OpenTofu, I'm not in the technical steering committee but what I can say is that everything is fully transparent. We have weekly or biweekly updates in GitHub, on the website, and we share things on our blog. We have a Slack community, workspace with about 1700 people asking questions and influencing the future off of OpenTofu.
So sorry for a political kind of answer, but I think, you know, it's not for me to personally share what's going on. There are official forums, governance forums with all the right process in order to make sure it's being handled properly by the leadership of this project.
Dotan Horovitz @Logz.io:
Okay, It makes sense. And then anyway, maybe one more point that was interesting from the get go. Now that it's part of the Linux Foundation, I think from the get go the project aim to actually join the CNCF the Cloud Native Computing Foundation.
So this yet another something that is interesting to see how the project evolves and how this converges actually I saw just earlier today a post by Chris Aniszczyk, the CTO of the CNCF, very enthusiastic and supportive of this major milestone. So hearing the executive leadership of the CNCF supportive of this is also encouraging.
And I don't know if anyone here in the audience is involved enough to comment on this, but definitely both in my capacity on the CNCF, but also generally I think the fit between Terraform and the cloud native ecosystem is it lends itself to just being under the same, the same foundation. Curious to see how this works out.
Sharone Zitzman:
Now that's an interesting question. I'd also be curious to hear. There's the OpenTofu Twitter - X now and the Slack that Ohad mentioned and the website opentofu.org. You can probably find all the information there and be able to track the project and get involved.
If you'd like to be more meaningfully involved and contribute to the project and open source projects can always use more hands on deck. So I'm sure that they would be more than happy to have more contributors.
I guess I will wrap up with just some last thoughts on the Infrastructure-as-Code landscape itself and how it's evolved over the years. And even Ohad said this project itself is nine years old.
I mean, I remember configuration management, injection puppet and things and all that, and now we're on CDK, now we're in all kinds of things and I'm just wondering where it's all going, kind of what are your predictions for what's happening in the IaC landscape and where it's going to evolve from here? Andrew, go right ahead.
Andrew Martin @Control Plane:
Thanks. I wanted to chime in just on the previous point about HTTP of IaC. Essentially, while currently HCL is a commonality, if we look at the blog post that Dotan referenced from the Linux Foundation, they mentioned the 1.7 candidate features. So client side stage encryption, awesome, transparent, looking great. Parameterizable backends, providers and modules to enable more readable DRY code.
So that potentially means that a module in OpenTofu will not be compatible with Terraform. The nightmare situation for an enterprise is for HashiCorp to change the license on HCL. So now it's not really clear whether that's even entirely possible, but potentially there's something there that would then be a hard fork and we'd be looking for maintainers in the community again to decide which way to go.
I think everyone on this space is confident that the community would rally around at the more open side of that fork. But this is broadly where I see the Infrastructure-as-Code piece going as well because we have more or less standardized around the declarative nature of infrastructure configuration management.
We generate a plan, we have the ability to run static analysis on it, and then we apply it to our cloud infrastructure. That is compared to what we used to do, which was gaffer tape and string. Even through, again, the procedural configuration management. We're in such a beautiful place compared to, you know, the beginning of my career and how I used to stand up and rack and stack servers.
So I see as a foundational piece to build the infrastructure for all the apps and systems that we use seem to have reasonably commoditized before this. My hope is that it maintains that stability because it is important for the systems currently running on it. And the ease of migration between forks at this point is a major selling point. I do wonder if HashiCorp will pull that card at some point in the future.
Anders Eknert @Styra:
One thing that struck me is not just in the IaC space, but kind of the industry at large is of course like what... What impact does this fork and OpenBao, these types of forks, now that we know? Like that's probably what's going to happen. Like it must have a chilling effect on anyone else considering a license, which at this point knowing that that’s likely the outcome of doing this.
So I feel this fork has benefits outside of the even the IaC space just knowing that anyone considering this at this point must know now that this is a likely outcome that somebody is going to fork the project at one point it’s bound to diverge and there's going to be fragmentation, which is probably not what's that the outlook of that or like the it's not as appealing as.
And I'm sure like, I don't think HashiCorp saw this coming. I'm not sure if anyone knows, so I could be wrong there. But now, like anybody, anybody is going to see this coming like this.
So I'm super excited about that or just like this whole prospect of knowing like and where Andrew said like forks are great, but obviously they're not great from the perspective of whoever wanted to pull the rug under the community and change something to a proprietary license.
So it's obviously not a desirable outcome for them. And I'm very happy that this likely has a chilling effect on anyone else, considering this.
Sharone Zitzman:
Yeah, that makes a lot of sense. I actually see that somebody from our community has accepted speaker invitation, so Engin. I'd love to hear your thoughts on kind of the evolution of the IaC space and what you see coming and a little bit thoughts going forward.
Engin Diri @Pulumi:
Thanks. First of all, Sharone, for organizing this great space. It's always interesting to hear what people in the same space thinks. First of all, a disclaimer. Yes, I'm working for Pulumi, so I may be a little bit biased in some of my points, but I just wanted to continue what Anders mentioned.
I found this very interesting because this is something we at Pulumi could also feel was an increase of people looking around. Let me say it like this. So not saying, Hey, I'm going to switch, but just started to reevaluate the situation because there is now uncertainty and fear what's going on with the tools they're using. So that's one of the things that people start to ask the questions or maybe redue their diligence.
They may be missed before because they saw open sources always for granted and paid license change is something that cannot happen.So yes, we saw people coming with these concerns or coming and saying, hey, we're going to use now the opportunity with this license change to look around to create a new shortlist of possible other solutions.
That was one of the things, and I think the whole licensing change makes the situation that people, when they decide for something new, they look a little bit more deeply. It even went so far that our CEO Joe, for example, he presented a YouTube video where he had to assure the people to say, Hey, Pulumi, as for now, will stay open source, is open source in its core. There's nothing planned.
Any license changes since then because people ask about everything. What we sometimes said, like, are you going to be the next? you know, so that's a thing I saw. So they're a little bit shaking on the culture of people, how they consume before open source tools.
So people are now aware there are different licenses, that people are aware that there can be a license change, and they are looking more during their evaluation of tools, which license is underneath because not every open source license, as we saw now, is the same and could even have an impact on some of the companies ad hoc.
I mean, Ohad with env zero and so on, and they saw this firsthand what could mean for a company when a license of a core element of their business model changed. So just some insight from me.
Sharone Zitzman:
Yeah, I couldn't agree more. Actually. One thing that I recall seeing that when the license changed in the same way that Dotan mentioned OpenBao, and that eventually was just because they had that dependency that they literally had to fork the project in order to continue a different project.
I even saw in the security space and we the some of that Andrew can attest to after we just finished this specific question but that they were even considering it almost like a supply chain attack. Once your license changes and you have this dependency and you suddenly have this package that's tightly coupled in your stack, it really can wreak havoc.
So it's interesting to see how those sorts of things can be perceived. An impact, an engineering stack that's running and in production when these things are pulled out from under you. So all these points are really interesting. I'm going to ask Dotan and Ohad to chime in.
Dotan Horovitz @Logz.io:
I think that what Engin said is very, very true. I think looking now not as maintainers or open source enthusiasts but as plain users, that the vast majority just use, again, libraries or tools in their day to day. And it's very important to get into the usage in a more mature fashion.
We do a thorough evaluation of tools for many respects and the performance and the cost and the security is now much more conscious. People are more conscious of security aspects. This should be one of the elements as well. I don't say it's the most important, but it is a different element. Seems to be not top of mind for everyone.
And it's not just the license - People by now are already fairly familiar with open source licensing. It's fine, but look beyond the licensing. You can ask additional questions like who's the who's behind the open source? If you see a single entity behind an open source, we saw what could happen. We saw that your, it's it could flip on you.
You can also ask, what's the governance policy? The governance policy is the thing that will determine who can change the license or many other things and who can be promoted. How can people be promoted to contributors, to maintainers, to approvers, to whatnot, and all this process and the transparency around that.
So it's very important to ask these questions from the get go and understand - if you have two options, two open source tools that are equally on the same level in other aspects, this should definitely be a factor for your decision.
So just make sure and obviously when you use the tool, still also use it wisely. So just like when you, in security, manage your third-party licensing exposure, you need to use security exposure. You should do the same with the licensing exposure we mentioned like copyleft licenses. It can be spread virally with your code. So you need to understand that and mitigate that.
You need to take care with automation, for example, so that you don't automatically upgrade. We all love automations; we're all engineers. But if you upgrade, then suddenly the license changed, and you haven't put guardrails in that process.
Suddenly, within this automation, you find yourself adopting a license that you didn't plan on just because of the automation. So lots of things that I would say make sure that it's in your day-to-day engineering activity, both when deciding on choosing a tool and when using it in your day-to-day.
Sharone Zitzman:
I’ll let Nati chime in. I'd love to hear what he has to say. First of all, also on the future of open source. I'm so happy you're here, Nati. First of all, welcome, tell us a little bit on the future of IaC, open source.
And I historically remember you kind of saying things around predicting the end of Terraform as the Golden Hammer. That was kind of how you phrased it, and I thought that was a really interesting phrasing. So I'd love to hear your thoughts on everything that's played out since then.
Nati Shalom @Cloudify:
I think what you also remember is the saying the only constant is change, that I think was also in our shirts and whatever. And I think it applies here as well. I heard a lot of examples of open source, I think project that was mentioned here.
One thing that I didn't hear is Docker, and I think those remember the days of Docker and how it started in a storm and looked like the only constant is no change, that it's going to be there forever. You can look and see even you know, how much a dominant project, very successful one can be too successful. And there is something that is called too successful. And I think the case of Terraform really reminds me of that example.
There is something that is called being too successful and Docker is a great example for that and I think Terraform is very closely... I think in that of too many companies, pretty big companies and pretty big projects and that the, I would say that force of fork, so to speak, is almost inevitable.
And the same thing that happened with Docker when they became greedy and wanted to move up the stack and kind of dictate how things will work, that force of fork became stronger and stronger.
You know, joining Google that actually created another project called Kubernetes which kind of killed Storm Swarm and so forth. So I think there's enough profit to be at the momentum. And what I think the community needs to realize is that it's going to take time to build that momentum and that it needs to be patient, for patience.
And that's the second point. You need funding. And I think one of the things that I think we're still lacking is a good business model behind those open source projects, because what we're seeing is that every time that there is a successful open source, it becomes greedy and therefore change license. And that kind of makes a lot of people relatively skeptic about the nature of open source as it appeared in that.
And I think, I'm hoping that something that comes out of this OpenTofu experience is also a better business model that I think would be viable for both the maintainers that obviously need funding to maintain things. It doesn't come for free, but it wouldn't really have to go through this greediness phase where everything becomes closed, etc.. So that's a mindset and something to live with the community.
Sharone Zitzman:
Yeah, yeah, 100%. I couldn't agree more that something must be broken in the system if this is the outcome of all of these successful open source projects. Maybe we do need to rethink what that model actually looks like going forward.
Ohad I’ll let you wrap it up and also give us some, you know, some teasers looking forward in terms of the project, what we can expect in terms of the rollout and and I guess time frames for releases and the and just take it away and our space.
Ohad Maislish @env0:
So thanks Sharone, thanks everybody. I would mainly like to echo what Dotan just said earlier and for me it was also a learning experience because up until a few months ago I thought open source is open source. So mostly open source. But I think now engineering leaders, when choosing new technologies to use that are open source need to look at two other criterias.
One is who is behind the legally license open source? Is it a company or is it the CNCF, Linux Foundation or something like that? Because that's totally different. There is no pull one if it's under the CNCF or the Linux Foundation.
The second thing, if it's not under the Linux Foundation or CNCF or something like that, is how this project, the Open Source project, behaves. So for example, couple of years ago in September 21 HashiCorp announced that they were no longer accepting a community pull request to Terraform code. So that's a huge signal of how this project is being managed. It was open source license back then, but it was not community driven.
So after looking at both the license itself from a legal point of view, but also my point the community aspects of how you can, how you can influence, how you can affect the progress of this project and who controls this project, whether it's impartial within the Linux Foundation, CNCF or not as impartial as you wanted it to be, because things can change.
And we have learned that from HashiCorp license change and other license changes that were discussed here as well. So yeah, I think we all learned and I think a lot of folks, a lot of engineers also learned a very important lesson and will take the future decisions accordingly. And I think some things will change.
And back to your question about the teasers and things like that. So again, It's not something that is special to us. It's a community-driven project that the questions are being asked in those forums.
So again, a boring answer to an important question is just to follow the official website and Slack channel. Social media of OpenTofu. And learn from there exactly what's going on with the weekly updates and the you know, this is how it should be done in the community. I don't have any important information that others don't have.
Sharone Zitzman:
Fantastic. That's I guess that's the way it should be. I could go on all night talking about open source, one of the topics that are near and dear to my heart.
But guess we will wrap up…
I am going to thank my co-host, Matan Buganim from env zero and Andrew Martin from ControlPlane, Dotan Horovitz from logz.io, Ohad Maislish from env0, and Anders Eknert from Styra, and all of the speakers, Nati, Eddie, Engin. Thank you so much for chiming in and being a meaningful part of our community.
We will keep you posted. And you can definitely follow both myself, the TLV community, and the OpenTofu community for more updates. DevOps days, Tel Aviv and any of those handles and communities and get involved.
We hope to be able to meet up in person sometime soon, and hopefully, I'll see all of you on the community circuit. Thanks so much for being here. Have a good evening!
Unpacking OpenTofu: Expert Panel on GA Release, Licensing, and OSS Future
