Why should I care about OpenTofu? | Hacker News Reader

Why should I care about OpenTofu?

opentofu.org

74 pointsRyeCombinator26 comments

So far it appears to be the same old thing with a different owner. Maintainers act like they own the thing and everyone else (read: the users, as opposed to the developers) can just suck it. Like the whole "enshittification of products" HN post, project doesn't actually care about the users. It's just a hedge for SaaS to have a more permissive license. They need us to adopt it, otherwise they will have to develop identical features to TF in their fork to maintain compatibility, indefinitely. Community definitely isn't the goal.

I think a major benefit of open source is that it doesn’t require good intentions on the part of the maintainers. A consortium of maintainers ensures that none of them have the market power to change the license.

There should be additional maintainers that are not affiliated with Hashicorp competitors.

Maybe that's true, but in the long run, I'll stick with the "community" of multiple SaaS providers all awkwardly sharing a permissive license than the one provider who took their ball and went home with it. Ultimately, the companies involved have to somewhat care about their users because the product needs to be good or no one will use it. The alternative is core Terraform or the first party's IaC options, which are all more closed and more don't care about the user.

Community may not be the #1 goal, but it's certainly on the list of things that has value about the project, both to the users and the maintainers.

A project like this needs a strong, opinionated approach.

I’ve seen too many wild “I wish Terraform did…” discussions with others to trust any form of democratic maintenance to work.

> Maintainers act like they own the thing and everyone else (read: the users, as opposed to the developers) can just suck it.

> project doesn't actually care about the users

> Community definitely isn't the goal

Hey, OpenTofu Core team member here. I'm sorry that you feel that way. Is there anything specific that you'd change, or should be different in your opinion?

Being heavily community-driven (regarding issues chosen for implementation) is definitely one of our core goals, and it's a hard goal! We're still setting things up here and on the road to the first alpha release - your feedback would be very welcome and valuable. We do listen and strive to improve, we've just introduced weekly updates[0] based on community feedback.

[0]: https://github.com/opentofu/opentofu/blob/main/WEEKLY_UPDATE...

> So far it appears to be the same old thing with a different owner.

What a ridiculous point. Did you expect 15 new features a few weeks after the branch?

> project doesn't actually care about the users

And you know that because the haven't yet developed 100 new features?

> TL;DR having options is good strategy, OpenTofu is your insurance policy and competition makes things great.

I hope that includes competition beyond dotTF (as a term to capture both TF & Tofu)?

For example, I'm keen to see what can be built in this space on top of CUE

I have concerns that this movement will fracture the ecosystem. They speak of backwards compatibility, which to me means they are going to be allowing things that TF will not understand. The paths this could take will be interesting to watch unfold, it could be a complete bifurcation or something like the NPM v Deno v Bun situation, where it seems there will be long-term convergence of the module system, but requires more work for all vendors and module authors.

re: the quote, I don't really feel an urgency to get insurance or invest in a migration just because Hashi changed their license. This seems more like a group policy for the SaaS's that are impacted than for the users of TF who aren't

---

edit, after reading the whole thing, I'm not really sure what to make of this writing, it meanders and spends a lot of time self glorifying...

Can someone explain concretely and specifically what this thing does?

This is a fork of Terraform after Hashicorp changed the license

Thanks. That's easily discoverable. Can you explain concretely and specifically what terraform does.

"infrastructure as code tool that enables you to safely and predictably provision and manage infrastructure in any cloud"

Doesn't tell me anything. Is this a markup language for describing networks? Is it some web interface where you drag and drop server icons and then draw lines between them? Is it a simulation tool? Is it some provisioning thing like chef with a database for different machines?

Infrastructure as code. You define your infra in a couple of files, then terraform builds it against eg: aws.

Through what? The aws cli tool?

Why would I need to encode something like that? Are you talking about maybe having identical setups in different parts of the world?

You would encode it for the same reason we use source control - confidence that what is deployed matches some kind of record of it.

In development we don't send archives of code to each other (OK, some people do I guess) and in infrastructure we don't click around in AWS to make changes

I'm still not convinced on this use case.

The click around technique could have logs and audit trails just the same. Someone could also just type up what they did.

If you're doing 100 of something I'm sold but the record argument I find unconvincing. A preference sure, but a simplifier, no.

Have you ever worked in a regulated environment? One where you can't just SSH into production and change things? Logs and audit trails provide attribution, not prevention. How do you prevent unwanted changes to production? How do you block changes to production with quality gates? How do you ensure that modules conform to specific specifications before they are launched? How do you do an equivalent to code review? What happens when AWS rolls out a new feature like blocking public access and you have to roll it out to all of your buckets immediately? All of this is much, much more tedious in an interactive system.

Some great points from a sibling comment, and the one I'd add is:

You don't need 100 instances of something to make managing it programmatically worthwhile. Different environments, for example: Terraform makes it very easy to ensure _all_ of the cloud config in prod matches staging (or the inverse), and to set up and bring down ephemeral development environments, using parameterised Terraform modules so you can be confident changes will propagate appropriately.

Terraform is a tool and module ecosystem for provisioning cloud resources from a declarative language, called Hashicorp Language (HCL). The idea is to specify your cloud resources in a file, commit that to git, and then run the tool on sets of these resources. The underlying engine will look at what you want this time, compare that to what is in the cloud, and make the appropriate changes, doing some nice graph walking to handle dependencies and work in parallel when it can.

For those interested, there is a small package that is the core of the specialized graph data structure that powers this: https://github.com/opentofu/opentofu/blob/main/internal/dag/... (link to the most interesting comment block in the package)

Amazingly well done. Super clear. Thanks

It's a Hashicorp Terraform fork.

Hashicorp started playing license games. So a bunch of the people and orgs that depend on Terraform took out insurance against future license changes by forking and instituting an open license version that no one can close (or, for that matter, ensure no one pulls a Unity).

"HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share." [1]

[1] https://developer.hashicorp.com/terraform/intro

Maybe I'm missing something but I feel like I've heard pitches for many similar products, is this just the industry leader or is it genuinely a unique player?

It's pretty much an industry leader, it was one of the earliest ones on the scene. And many people write terraform providers for different kinds of targets. So whether good or bad, it has a lot of mind share and lots of lines of code written for it.

Alternatives do exist now and they're all good in their own ways.

Terraform is very popular, far more then older systems of this style. Im not sure if the feature set is totally unique.

When deploying infrastructure at scale, nobody clicks around in vSphere or AWS.

They create parameterized "infrastructure as code" definitions that can repeatably create resources.

Terraform is by far the most popular tool for this.

It's a configuration file parser and task dependency engine that tries to guarantee idempotent updates by keeping a record of the current state of your deployment and only running update tasks if your configuration doesn't match the deployed state. The dependency engine also does some topological sorting to automatically run tasks in dependency order, in parallel where possible, without you having to imperatively specify any kind of ordering.

The configuration files themselves are intended to be written in HCL or the Hashicorp Configuration Language, which was created for Terraform and offers some built-in functions and types, but it will also accept json, which is intended more for when you programmatically generate your configuration. They recently began supporting writing your configuration as Python or TypeScript as well, addressing complaints that HCL is close enough to a real programming language that you often wish you had a real programming language.

The state is tracked either in a local file or a remote file, and the file is json. If remote, you can add authorization and locking depending on the remote storage provider.

The meat of the work is not really done by Terraform itself, but by providers, which are plugins either written by Hashicorp, by infrastructure vendors, or by the user community. The configuration files define resources that consist of variables that end up getting passed to these plugins that then construct API calls to request the real infrastructure providers do the provisioning. You also get "data" resources that just query the infrastructure provider rather than asking it to provision anything.

As for why you want Infrastructure as Code, effectively the same reason you want anything as code. Why write software when you can get a computer to do just about anything with shell commands? Because you can reuse, share, make far better reliability and consistency guarantees, and the code itself provides somewhat of an audit trail or record that should reflect the behavior of your resources. As long as your administrators actually use it, you have a clear, readable record of how everything you own was deployed. It can be put to code review before changing anything. You can use your regular peer review/pull request process to implement separation of duties.

Terraform is somewhat of an industry leader. Hashicorp is the company that started out with Vagrant and also makes Packer, Vault, Consul, Nomad, and some other things, but all of their products are pretty widely used and have a lot of developer mindshare. They're not the only game in town, but as far as Infrastructure as Code tools that aren't locked to a single cloud provider, there's really only Terraform and Pulumi that I'm aware of and have seen actually used in the wild.

So should OTF become OpenTofuEnterprise ? https://github.com/leg100/otf

Reply on news.ycombinator.com