docs: Add clarity to the public FAQ. #338
Conversation
Signed-off-by: Ryan Parman <[email protected]>
|
|
||
| </AccordionItem> | ||
|
|
||
| <AccordionItem id="opentofu-terraform-differences" summary="What are the differences between OpenTofu and Terraform?" highlight> | ||
|
|
||
| On the technical level, OpenTofu 1.6.x is very similar feature-wise to Terraform 1.6.x. In the future, the projects feature sets will diverge. | ||
| On the technical level, OpenTofu 1.6.x is very similar feature-wise to Terraform 1.6.x. In the future, the feature sets will diverge. OpenTofu will have features not found in Terraform, and vice versa. As a matter of fact, this is already beginning to happen. |
There was a problem hiding this comment.
Here it may be worth linking to the migration guides in the docs.
| On the technical level, OpenTofu 1.6.x is very similar feature-wise to Terraform 1.6.x. In the future, the projects feature sets will diverge. | ||
| On the technical level, OpenTofu 1.6.x is very similar feature-wise to Terraform 1.6.x. In the future, the feature sets will diverge. OpenTofu will have features not found in Terraform, and vice versa. As a matter of fact, this is already beginning to happen. | ||
|
|
||
| The other primary difference is that OpenTofu is available under the [Mozilla Public License 2.0](https://spdx.org/licenses/MPL-2.0.html) (MPL-2.0), an [open-source license](https://opensource.org/licenses?ls=MPL-2.0) ([definition](https://opensource.org/osd)). Its goal is to be driven collaboratively by the community, with no single company being able to dictate the roadmap. |
There was a problem hiding this comment.
Since this was written, both us and Terraform have added a host of new features, so this section may need to be revised.
There was a problem hiding this comment.
I'll take a crack at it.
|
|
||
| </AccordionItem> | ||
|
|
||
| <AccordionItem id="why-use-opentofu" summary="Why should you use OpenTofu instead of Terraform?" highlight> | ||
|
|
||
| #### Personal use | ||
|
|
||
| Initial impressions suggest you could use either OpenTofu or Terraform for personal use, as the BUSL license has no restrictions for non-commercial use cases. That may change as the Terraform ecosystem becomes increasingly unstable, and a switch to another license may happen. Those familiar with Terraform will have no issues adopting OpenTofu for personal use, so there will be no knowledge gaps, at least at the start. | ||
| Initial impressions suggest you could use either OpenTofu or Terraform for personal use, as the [Business Source License](https://spdx.org/licenses/BUSL-1.1.html) (BUSL) has no restrictions for non-commercial use cases. That may change as the Terraform ecosystem becomes increasingly unstable, and a switch to another license may happen. Those familiar with Terraform should have very issues adopting OpenTofu for personal use, as long as they are not using features that are _exclusive_ to Terraform. |
There was a problem hiding this comment.
should have very issues
Did you mean "very few issues"?
|
|
||
| </AccordionItem> | ||
|
|
||
| <AccordionItem id="terraform-replacement" summary="Can I use OpenTofu as a drop-in replacement for Terraform? Is OpenTofu suitable for production use?" highlight> | ||
|
|
||
| Right now, OpenTofu is a drop-in replacement for Terraform, as it's compatible with Terraform versions 1.5.x and most of 1.6.x. You don’t need to make any changes to your code to ensure compatibility. | ||
| OpenTofu will remain compatible with Terraform versions 1.5.x and most of 1.6.x. In these cases, it is a drop-in replacement for Terraform. You don’t need to make any changes to your code to ensure compatibility. |
There was a problem hiding this comment.
OpenTofu will remain compatible with Terraform versions 1.5.x and most of 1.6.x. In these cases, it is a drop-in replacement for Terraform. You don’t need to make any changes to your code to ensure compatibility.
This feels awkward. I would suggest:
OpenTofu will remain compatible with Terraform versions 1.5.x and most of 1.6.x and is a drop-in replacement for Terraform amongst these versions. You don’t need to make any changes to your code to ensure compatibility.
There was a problem hiding this comment.
This is another good place to link with the migration guides from terraform versions above 1.6.X.
|
|
||
| </AccordionItem> | ||
|
|
||
| <AccordionItem id="decisions" summary="How are new features, bug fixes, and other development decisions made in OpenTofu?"> | ||
|
|
||
| The core team with its technical lead determine the most important features and bug fixes to work on, while the steering committee makes decisions on big changes. | ||
| The Core team with its Technical Lead determine the most important features and bug fixes to work on, while the _Technical Steering Committee_ (TSC) makes decisions on big changes. |
There was a problem hiding this comment.
A link to the TSC notes would be helpful, here.
|
|
||
| </AccordionItem> | ||
|
|
||
| <AccordionItem id="opentofu-compatibility" summary="Will OpenTofu be compatible with future Terraform releases?" highlight> | ||
|
|
||
| The community will decide what features OpenTofu will have. Some long-awaited Terraform features will be publicly available soon. | ||
| OpenTofu will remain compatible with Terraform versions 1.5.x and most of 1.6.x. |
There was a problem hiding this comment.
I would re-phrase it a bit, because the current version sounds like we will not be compatible with Terraform 1.7 and above. It is true to some degree, but we want to be as much compatible as possible in general. I would reflect that here.
Also, this is another good place to link with migration guides.
There was a problem hiding this comment.
Good points here. I know I've seen chatter in Slack about not wanting to maintain a differences list between the projects, but I do believe that there is some value there.
Let me think on this.
| If you're missing a feature in OpenTofu that's available in Terraform, feel free to create an issue. | ||
| Core functionality with regard to the Terraform HCL language will remain compatible with future Terraform releases. OpenTofu remains compatible with the underlying gRPC-based [Provider Protocol](https://developer.hashicorp.com/terraform/plugin/how-terraform-works) upon which all current providers are built. | ||
|
|
||
| Outside of those areas, the community will decide which features OpenTofu will have. In some cases, we've already shipped features in OpenTofu that spent years languishing in the Terraform backlog. There are even features which are exclusive to OpenTofu, such as [State and Plan Encryption](https://opentofu.org/docs/language/state/encryption/), and even writing custom provider functions in [Go](https://github.com/opentofu/terraform-provider-go) or [Lua](https://github.com/opentofu/terraform-provider-lua). |
There was a problem hiding this comment.
Another good example of OpenTofu exclusive feature - early variable and locals evaluation.
| OpenTofu will not have its own providers. Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu works with the current Terraform providers, but it uses a separate registry. | ||
| The [Terraform Plugin SDK v2](https://github.com/hashicorp/terraform-plugin-sdk) and the newer [Terraform Plugin Framework](https://github.com/hashicorp/terraform-plugin-framework) are both available under the [Mozilla Public License 2.0](https://spdx.org/licenses/MPL-2.0.html) (MPL-2.0), an [open-source license](https://opensource.org/licenses?ls=MPL-2.0) ([definition](https://opensource.org/osd)). This means that we can continue leveraging the existing providers and modules in OpenTofu without having to fork them. | ||
|
|
||
| Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu works with the current Terraform providers, but it uses a [separate registry](https://search.opentofu.org). If those circumstances change, we will have to adapt. But we are confident that the OpenTofu and its community will be able to resolve any issues that arise. |
There was a problem hiding this comment.
I would elaborate a bit more on why it is very unlikely for providers to change their licenses:
| Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu works with the current Terraform providers, but it uses a [separate registry](https://search.opentofu.org). If those circumstances change, we will have to adapt. But we are confident that the OpenTofu and its community will be able to resolve any issues that arise. | |
| Terraform providers are separate projects built by the community and supported by different companies and authors. They have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu works with the current Terraform providers, but it uses a [separate registry](https://search.opentofu.org). If those circumstances change, we will have to adapt. But we are confident that the OpenTofu and its community will be able to resolve any issues that arise. |
There was a problem hiding this comment.
This text was previously there and I didn't change it, but the same question crossed my mind during editing — why?
I imagine that the original text was put together quickly, but expanding on the topic while still remaining FAQ-length could be a good idea.
Then again, maybe this is a topic for a deeper technical FAQ that was mentioned in the Slack #dev-guides channel. A place where we can go deep on technical topics, beyond the scope of the VP-friendly FAQ on the homepage.
Let me play with this.
Description
I feel that the content of the FAQ can be improved to increase clarity, provide additional context, and shift the language to describe OpenTofu in its own right (instead of simply being a Terraform fork).
Certainly open to discussion, but I believe that this reads a little better.
Motivation and Context
Types of changes
Checklist: