OpenTF - WTF Does It All Mean

If your business has been using infrastructure as code solutions, you have either looked at or are a current user of Terraform. Over the last number of years, it's become a sort of de-facto standard for IAC implementations. Of course - alternatives, and reasons to use those alternatives exist, but Terraform can easily be called the 800 pound gorilla of the IAC tooling world.

 

This August, Hashicorp announced a significant change in licensing to most of their products. This has generated a large amount of discussion in the open source and technical communities and has resulted in the creation of the OpenTF foundation and the subsequent announcement and release of the OpenTF fork. The repository was released last Monday and already has garnered significant industry interest.

 

To ease any potential confusion of the reader, let's get clear on our terms. The Hashicorp-maintained Terraform will always be referred to as such. The fork, OpenTF, will be referred to as OpenTF. The author pledges to stay away from the discussion of the actual language itself for the purposes of this article to not cause additional confusion and fear with the audience for fear of his own terraform plan producing an unknown error.

 

In the open source world, forks generally fall into one of three major categories.

 

In the case of OpenTF, it's firmly a "category two" fork, focused on the preservation of the openness of a tool. There's been a few of those before, but the biggest one that comes to mind for me is actually not the MySQL/MariaDB split from a few years back. It is (and I'm going to date myself here) the split of Illumos from OpenSolaris. History in many way rhymes, and much like Terraform, OpenSolaris was licensed under the CDDL (Common Development & Distribution License) which was based on the Mozilla Public License (MPL) that Terraform was previously licensed under. The Illumos project continues to this day and has spawned several commercial companies.

 

However, OpenSolaris was an entire operating system with an full ecosystem of applications. Does this apply to individual software packages? Sure! let's think back to that MySQL/MariaDB split. Both products remain (mostly) cross-compatible to this day, but the feature set is starting to diverge between the two.

 

At risk of predicting the future (which is always a mug's game) it's not hard to see what will most likely happen. As the projects continue to grow and develop side-by-side, it's very likely that the featureset will begin to diverge. Having been a developer myself, I can unequivocally say that developers absolutely love working on brand new features. Greenfield features - doubly so. So I'm fully expecting to see new features in OpenTF that will not immediately be available in Hashicorp Terraform and vice versa. In fact, there has already been drift, with the very public announcement by social media accounts related to Gruntwork regarding encryption of OpenTF state files via the tool itself; a feature that was blocked in the main Terraform repository since 2014. One thing that I'm expecting to see here is actually a number of blocked or rejected features of the Hashicorp Terraform repository potentially making their way into OpenTF. Change is already in the wind.

 

What could also happen is the eventual absorption of one project into the other and vice versa. It's not a likely thing in the immediate future, but it is a possibility, and historically this has happened with divergent open-source projects before.

 

If your organization is using Terraform (or alternative Hashicorp products), it is most likely that you will need to run the new licensing terms past your legal council, if you need to upgrade to a re-licensed version of the tool. If that is not an option, continuing to use the pre-license change version of Terraform is perfectly fine. In fact, if you are still operating on a pre-1.x version of Terraform, no change will need to happen whatsoever. The upgrade path from those legacy versions to modern TF is a much broader topic with its own challenges that would be material for an entirely separate series of articles.

 

Unfortunately the answer to whether to go with the fork or stick with the Hashicorp version is a classic "it depends." If your organization meets the new licensing requirements, then there really is no immediate need to change. Likewise, upgrading may not be an immediate necessity which should give your organization somewhat of a runway prior to committing one way or another.

 

One thing that inevitably happens with open source projects like this is that certain things immediately change. The repository has been out for a week as of the writing of this article and while the majority of changes so far appear to be cosmetic or operational in nature, such as updating the default module registry, and as mentioned above, the beginning of an implementation of encrypted state files. The primary effort, at least based on extant and merged PRs though still seems to be housekeeping. There have been a few backporting efforts in terms of updates and features from the 1.5.0 branch of Terraform.

 

Depends on where you need to be. So far, there's no major split between the two projects outside of the licence, which turns the entire thing into a licensing question. In the meantime, as we watch the two projects develop, keep an eye out on the Better Than Services blog. We're huge users of Terraform for our work and OpenTF is already on our list of internal tools that we track, so we'll be sharing our analysis as development develops. Subscribe to the BTS blog using the form below to stay up on the latest.