Posted on October 26, 2023

OpenTofu - Is Hashicorp in trouble now?

OpenTofu is the result of a group of industry leaders that came together in response to Terraform changing its license from the open-source Mozilla Public License (MPL) to a non-open source Business Source License (BUSL) earlier this year. Since Terraform has been an essential tool in the community, and many companies have adopted it precisely for its open-source nature, this decision had a significant impact for many organizations. You can read more about that here.

A group called OpenTF was established, releasing a manifesto that declared its commitment to preserving Terraform as a free open-source tool appealing to HashiCorp to revert the license change and announcing that in case that became unfeasible, they were prepared to fork the Terraform project, guaranteeing the community continues to have access to an open-source tool in the future. The OpenTF initiative was publicly backed by hundreds of companies, some of those pledging significant resources to the project.

The manifesto was enacted some time later leading to the forking of the Terraform project into a new project called OpenTofu. Not so long ago, it was announced that OpenTofu will be maintained by the Linux Foundation as a way to ensure that OpenTofu remains truly open source and neutral and not at the whim of a single company.

OpenTofu aims to build on top of the great work that’s been done by HashiCorp over the years to grow Terraform into the tool that it is today and to ensure that it can continue to innovate and grow as a truly open source solution.

What is OpenTofu

OpenTofu is an Infrastructure as Code (IaC) tool for building, handling, and versioning infrastructure safely and efficiently. It allows you to define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and maintain in Git.

With OpenTofu you can provision and manage all of your infrastructure throughout its lifecycle by using a consistent workflow. It can manage low-level components (e.g. compute, storage, networking resources) as well as high-level components (e.g. DNS entries, SaaS features).

OpenTofu is hosted by the Linux Foundation (LF) and can manage existing and popular service providers as well as custom in-house solutions.

How does OpenTofu work?

OpenTofu creates and manages resources on IaaS/PaaS/SaaS using their application programming interfaces (APIs) via so-called providers. Through these providers, OpenTofu can interface with almost any platform or service that offers an accessible API.

There are already thousands of providers to handle a diverse range of resources and services that have been developed by members of the OpenTofu community.

All publicly accessible providers can be located on the Public Terraform Registry. This includes those for Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Openstack, Splunk, DataDog and many others.

There are 3 main stages at the core of OpenTofu workflow, namely Write, Plan and Apply. Let’s talk about each:

Write: predefine infrastructure as code
You define resources, which may be across multiple cloud providers and services. For example, you might create a configuration to deploy an application on Kubernetes running virtual machines in a Virtual Private Cloud (VPC) network with security groups and an Ingress.
Plan: preview changes before applying
OpenTofu creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration. You can think of it as a diff in Git, but for the infrastructure resources.
Apply: provision reproducible infrastructure
On approval, OpenTofu performs the proposed operations in the correct order, respecting any resource dependencies. For example, if you update the properties of a VPC and change the number of virtual machines in that VPC, OpenTofu will update the VPC before scaling the virtual machines.

OpenTofu features

The distinct qualities of open source such as creativity, flexibility, openness, and collaboration, are often hard to find in proprietary systems. OpenTofu matches Terraform in its features but at the same time it introduces new distinct capabilities. It caters to an extensive array of cloud providers and boasts a solid plugin framework.

Infrastructure as Code: Infrastructure is described using high-level configuration syntax, enabling you to version and manage your datacenter blueprint like any code piece. This infrastructure code can easily be shared and repurposed.

Execution Plans: OpenTofu incorporates a ‘planning’ phase, during which an action plan is generated. This plan clearly displays the actions OpenTofu will undertake when the ‘apply’ command is given, ensuring no unexpected outcomes during infrastructure adjustments.

Resource Graph: OpenTofu builds a graph of all your resources, and runs the creation and modification of any non-dependent resources in parallel. As a result, OpenTofu builds infrastructure as efficiently as possible, granting operators insight into dependencies in their infrastructure.

Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. Together with the execution plan and resource graph, you know exactly what OpenTofu will change and in what order, avoiding many possible human errors.

Why use OpenTofu?

With OpenTofu you can access providers for numerous platforms in the Public OpenTofu Registry or create your own.
Its immutable approach simplifies infrastructure updates and service modifications.
OpenTofu lays out a plan and asks your approval before any changes.
It keeps track of your real infrastructure in a state file, which acts as a source of truth for your environment.
It uses a state file as a reliable record of your actual infrastructure, guiding necessary adjustments to align with your desired setup.
Its declarative configurations specify your infrastructure’s desired state, eliminating the need for detailed instructions.
It uses a resource graph to discern dependencies and processes independent resources simultaneously for optimal efficiency.
OpenTofu promotes configuration standardization through modules, which are reusable components encapsulating infrastructure designs.
You can employ ready-made modules from the OpenTofu Registry or craft your own.
State of configuration is stored in files, facilitating integration with Version Control Systems (VCS) and Cloud providers.
This ensures consistent OpenTofu workflow management across teams and offers features like secure access to shared data, role-based permissions, a private registry, and more.

Most common questions

Since its recent release, there are a lot of questions that we are sure many of us have. Let’s address those questions:

Why did the Linux Foundation launch OpenTofu?
The OpenTF initiative’s commitment was to keep Terraform (or a fork of it) a truly open-source tool that is guided by the community and not biased in favor of commercial interests. The only way to achieve that was to donate the project to a Foundation that could ensure that the governance remains impartial and rooted in Open Source principles.

This is why OpenTofu was launched under the Linux Foundation, which is known in the open-source world for its integrity and for serving as custodians for many of the open-source tools that we use today including the Linux Kernel itself. Many other Foundation projects exist under the umbrella of the Linux Foundation, one of those is the CNCF.

Being maintained and governed by the Linux Foundation ensures that OpenTofu has the trust, support and resources of the community to drive adoption and innovation that we all benefit from.

Is OpenTofu a complete replacement for Terraform?
Yes, OpenTofu will be a full drop-in replacement for Terraform and the migration should be seamless. The first release of OpenTofu will be 100% compatible with the latest MPL release of Terraform which is 1.5.5.

This means that all the features and compatibility that you find in Terraform 1.5 today will be matched in OpenTofu as it releases. It is not necessary to make any changes to your code when you migrate to OpenTofu if you’re coming from Terraform 1.5. The only foreseeable difference when you switch from Terraform to OpenTofu will be the binary on the CLI.

In the future, OpenTofu plans to adopt semantic versioning. This means that as long as the project stays within the 1.x major version spectrum, it won’t introduce changes that disrupt backward compatibility with open-source Terraform releases.

Does OpenTofu work with my existing state files?
Yes, both OpenTofu and Terraform state files are identical, which means you don’t need to perform any migration tasks when it comes to your state when you migrate from Terraform to OpenTofu. Since OpenTofu’s first release is completely compatible with Terraform 1.5, you can just drop it in place and it will read in your existing state file exactly the same as Terraform would have done.

OpenTofu intends to build extra features around state files such as end-to-end encryption which is a feature that many users have been pushing for a long time. Some of these features might be added to the early releases or OpenTofu, however, it won’t be done in a way that introduces any breaking changes to how your state file is read.

Do Terraform modules and providers work with OpenTofu?
Yes, OpenTofu is forked from the last MPL release of Terraform, maintaining all the integration capabilities including modules and providers. OpenTofu will consistently support all the providers and modules you currently use, eliminating any concerns about switching to other options.

Does OpenTofu host its own registry?
Yes! OpenTofu is set to run its own registry for modules and providers, ensuring the ecosystem remains self-contained. By managing its own registry, OpenTofu enables users to seamlessly integrate modules and providers, akin to their prior experience with Terraform.

Who decides future functionality and feature changes to OpenTofu?
OpenTofu operates under the governance of the Linux Foundation, rather than being managed by a singular entity. Consequently, decisions regarding future editions and other directional matters will be determined by a committee. Meaning, anyone can suggest a modification or feature by submitting an RFC for the projects. A standard procedure will then be initiated to deliberate upon the proposal, considering its merits and value to the community. Ultimately, the community will predominantly guide decisions on new features and project changes, with the foundation providing some oversight.

Although it’s challenging to meet everyone’s expectations regarding feature additions and implementations, this approach ensures that modifications are made in the best interest of the broader community’s needs.

Reasons to switch to OpenTofu?

Terraform is no longer open source: If having an open-source Infrastructure as Code (IaC) tool is pivotal for your selection criteria, then a tool released under a BSL might not be for you.
Community oriented changes: OpenTofu’s evolution in terms of features and modifications will be wholly directed by its user community, free from any potential biases of a commercial organization.
Certainty: There is no certainty that Terraform will not keep changing its license terms over time. Relying on a tool with such uncertainties, especially if it is foundational to your IT infrastructure, can be quite risky. OpenTofu is likely to remain open-source indefinitely, and its developments are genuinely community-driven.

How do I migrate from Terraform to OpenTofu?
Transitioning from Terraform to OpenTofu mainly requires swapping out the Terraform binary for the OpenTofu binary in your pipeline.

If you’re using Terraform on your local machine, you can incorporate the OpenTofu binary into your PATH. This allows both OpenTofu and Terraform to function side by side, if needed for any reason.

Ready to transition from Terraform to OpenTofu but need guidance?
Reach out to us! Our experts are here to ensure a smooth migration. Give us a call today and let’s make your transition seamless and efficient.