I'm impressed by the speed at which you've forked the project and brought up the new technical infrastructure. You mention that you are 'interim tech lead'; what does interim mean in this context, and what is the governance structure for future leadership (and presumably your replacement)? Will OpenTofu have a self-selecting board? Or will it be democratic by vote, and if so, have suffrage by membership, participation or something else? Maybe top-down BDFL appointed by the Linux Foundation?
I am curious because your Manifesto states that as a result of LF stewardship the 'community governs the project'. The LF is massive, with a much more extensive portfolio than most people think, and influential far beyond its staffing would indicate. There is a great range of governance models and community norms across its projects, and, as with many things in FOSS leadership, no easy answer to the question of which the best option is among those.
As tech lead, it is your responsibility to choose what model and venue OpenTofu will adopt to fulfil its promises sustainably; I hope and imagine that you have been given the authority to make these choices decisively. The stewardship of the Linux Foundation is not an automatic guarantee of success, and the resources that the LF can provide are significant, unusual in FOSS, and very difficult to use - and concerningly easy to abuse unless directed by clear leadership. I wish you all the best of luck in this challenging but exciting task, and am curious to discover how you intend to take this project forward into the future.
The initiative will have a steering committee composed of individuals from the main backing and involved companies and projects.
As interim technical lead I'm mostly responsible for the technical side of things and getting the project up and running in this first phase. This also includes the feature development process and similar things. Interim means "until we figure out the exact details of the governance process", so a couple of weeks, most likely.
Representatives of the main organizations backing the initiative are collaborating with the LF to iron out the governance model. In practice, all of this is a collaborative process among the main backers.
The initial steering committee has already been selected and was to my knowledge a prerequisite to even being accepted to the LF. Currently each of the following organizations has a single seat: Gruntworks, Harness, Spacelift, env0, Scalr. There are free seats reserved for future joinees.
I appreciate the detailed response; thank you! It is wonderful that the governance structure is being thought out early. The best of luck to you and your colleagues in this endeavour!
I generally like your takes but this one isn't very good since it wasn't Amazon that was the threat.
HashiCorp couldn't compete. Their enterprise offerings were bad and their price quotes were insane and unrealistic. I worked at two companies who rejected them because their pricing was so ludicrous. The TACoS space of small startups nimbly out-competed these bad offerings.
Rent-seeking because you weren't able to compete with tiny startups able to effectively value add where you didn't is a bad strategy that pisses people off. I shed no tears for them and their rich founder who posts tweets of his solo flights to visit his rich friends.
Corporations didn't seem to understand that when you participate in the OSS ecosystem you don't just get to trade on the name recognition. Or if you do, and you renege on those promises, you're going to get a lot of people very angry.
So now we have companies going BSL because they didn't have a good business plan to begin with and this is their dying gasp to own the space so someone will pay them and not their much smarter, more creative, startup competitors.
HashiCorp pricing just made it simply impossible to pay them.
Their plan was to provide a free offering that was very good, get companies hooked, and then charge our the nose for any enterprisy feature.
The problem was how they charged, which they don't reveal until after you contact sales. You could build a solution using the free offering that works very well. Then years later want something paid offerings and contact sales and find out that they charge over 1000USD per clients, and you have 1000 clients. Oops, guess I'm just going to engineer my own solution for that. 1 million a year buys a lot of development and operational.
It's really hard to go to management and say this open source thing we are running and serving the companies needs will now cost millions of dollars.
Though I understand HashiCorp position somewhat. I'm sure their sales team has repeatedly heard that a potential client has decided they don't need the feature they called about since the free solution is good enough and can engineer around any short commons.
> 1 million a year buys a lot of development and operational
Not all that much. At a global enterprise, for instance, that buys a couple senior systems engineers with SDLC experience after you include all the per-employee overhead that doubles their cost beyond their comp.
Terraform saves the enterprise far more than that in overhead. If Terraform provides even 10% lift across 1000 seats, that's many times its cost.
At a million a year, you'd need it to save you between 2 and 4 headcount to break even, not counting the compliance/audit/security benefits.
An enterprise will _already_ have a team managing terraform infra. Them building the parts they need from that remaining 10% may be cheaper then paying HashiCorp. This is a difficult sell.
Also, a ton of Terraform's value comes from the fact that there are modules for everything. Some or developed by HashiCorp but most are developed by vendors or even users who want terraform support.
You've either done a lot of tech sales yourself or bought into the kool-aid software salespeople hand out. Their bread and butter is overstating per-engineer costs and hardware ownership costs, but it doesn't mean they're right.
In many places in europe you can hire a team of ~10 engineers already fully loaded for $1 million a year, or like 2 seniors and 4 midlevels or any combo like this. This is based off of 1st hand experience hiring for these salaries.
Yeah, but it buys 3 senior consultants, and they’re a fixed cost/capital expense and can be cut at any time. Operationally, it’s not that expensive to keep a Terraform platform floating. It’s expensive to build, and most companies need it yesterday. But bring in 3 people to support a team to build it in a year, then cut them free when it’s in v1, and leave your team to iterate and update. And now you’re not paying $1mm a year or more after that forever.
I think the point is that those three senior engineers could figure out how to do some SAML wrapper or remote execution on top of Open-Source Terraform instead of paying for the turn-key “Enterprise” features.
> Their enterprise offerings were bad and their price quotes were insane and unrealistic.
To clarify: the products themselves were and still are very good, with minor quirks.
As for pricing, there is a class of companies that set extremely high margins (this doesn't apply just to Hashicorp, see the the pricing of Gruntwork which I believe contributes to OpenTofu). This game reduces the number of customers but also the number of problems you need to deal with. This strategy is perfectly fine and I have no complaints - I built my own HA Vault cluster solution and used remote AWS backend instead of Hashicorp Cloud. But the license change was a game changer - Hashicorp is still a strong player in the market, but no longer the default choice.
We actually used Gruntwork at a past company over paying HashiCorp for enterprise Terraform. Their prices then were around 5k for a ready to go Reference Architecture. Apart from that one-time cost which we didn't pay because we built an RA ourselves, Gruntwork's prices were extremely reasonable. I don't think the comparison here is fair unless Gruntwork's prices have dramatically changed since then (I just checked: seems the same now as it was then).
I also don't particularly agree with your clarification on my part. I think their products are slim on features especially in light of what you're paying and a Terraform shop should almost always be opting for a TACoS solution over HashiCorp's.
> I shed no tears for them and their rich founder who posts tweets of his solo flights to visit his rich friends.
Couldn’t keep out a personal dig at Mitchell, who happens to be one of the most unproblematic people at Hashicorp and certainly doesn’t care or participate much in governance ? Seems like a lot of personal feelings were packed into this innocuous-posturing statement.
It wasn't innocuous or posturing. I actually pack my real feelings about a whole range of topics under this pseudonym all the time. And no, I don't particularly like Mitchell.
In this context I don't see your point. If I remember correctly, Hashimoto was the founder/CEO when Hashicorp products were being released as Open Source. Now he is no longer in charge (doing some development work I think) and someone else took the decision to change the license to BSL. So I don't see any relevancy here.
Yes, doing money on open source is hard, but on the other hand, the reason why you were successful was because you were open source in the first place and capitalized on millions of hours of free work from unpaid contributors which would've neither contributed nor adopted your product otherwise.
Imho, if you can't compete with other cloud offerings of your products then your cloud offering is weak. Competing with Amazon on prices is obviously hard, but not impossible, and it's easy to compete with them on customer service because it's your goddamn product and you should have the best expertise on it.
> capitalized on millions of hours of free work from unpaid contributors
Does this hypothesis really hold up? In my experience the contributor community remains small and often even dormant compared to the userbase of an opensource project only to take action if the project itself gets in turmoil (main developer leaves, bad takes on features etc.)
HashiCorp could pull it off, but I think moving everything to BSL overnight is just way too aggressive. I also don't think it's Amazon they are afraid of, but rather the other “cloud Terraform” providers (who unsurprisingly are the ones behind the fork).
For my own project [1], I'm planning on keeping the basic edition open and maybe adding an enterprise edition later on under BSL – basically like MariaDB does. I think that's the most fair model you can do right now.
Open Source businesses have no future as Open Source businesses if they aren't using Open Source licences.
What I find odd in these situations, that have happened multiple times now, is the companies go straight from "weak" licenses like the MPL, straight to "source available" ones. Surely it would have been a good idea to try a strong copyleft licence like AGPL first.
Then they can pay for an alternative licence for their closed source project.
It's a win/win/win, open source projects will still support it, so you don't get the backlash from the community, while those who just want to take will either pay or find a different project.
With BSL and similar, you end up looking like the "bad guy", and the forkers look like the "good guys". With AGPL you will still look like the open source "good guy", and if someone makes a fork they look like money grabbing assholes.
The problem is that as far as many corporations are concerned, AGPL doesn't count as "open source we dare to use", and thus a AGPL+commercial software vendor doesn't get the benefit of companies adopting the "non-Enterprise flavor" first/easily/via grassroots.
I’ve had this argument with people ad infinitum; it seems some people just see “AGPL” and any further thought process just stops.
“You could ask or pay for an alternate licence” or “you’re almost certainly not using this in a way that means you need to open source your entire product” and any other rational argument you can think of are just met with “yeah but agpl” and that’s apparently just the end of it.
The thing is, at that point, why not just put it under a proprietary license in the first place? Lots of companies simply don’t have AGPL on their list of legal approved open source licenses and they’re not going to change that for you. ADDED: If you want to go the dual licensing route, at least just state this up front.
Because AGPL is open source and not proprietary, that's the reason. Open source doesn't necessarily mean that anyone can use it as they please, they must abide by the terms of the license. If they don't want to, then they can find another project, or get a different license for it.
Depends on why you want an open-source license in the first place.
If it's to bait in companies to use your product and then offer more features under a proprietary license, then something that's more attractive to companies like a permissive (corporate charity) license is a better choice. If it's to ensure that everyone who uses the software can contribute to the development, something like the GPL or AGPL is better.
There can be other reasons to pick a corporate charity license, of course, but encouraging corporations to use your software is certainly one of the most common.
This will happen anyway; what they could do is to gain some time, that's all. But long-term consequences will be serious, I'm not sure if it was worth it.
Tofu is great, just misused as a meat alternative. The Chinese and Japanese don’t use it as a meat alternative (dishes like mapo tofu and agedashi tofu contain both meat/fish and tofu), they use it to provide textural support and contrast to rich, full-flavoured dishes.
If the negative association you have is because of its use in organic kale tofu salads and the like, that’s not exactly tofu’s problem.
It's not tofu's fault, but it kind of is tofu's problem imo, since it seems to be a common view. Until a couple of years ago I had pretty much the same view as GP, that tofu was bland with an unpleasant texture and I couldn't imagine anyone eating it for pleasure - based on my experiences of how it was cooked/served by restaurants and friends here in England.
Eventually I tried a tofu dish while sharing plates with a couple of vegan friends at a Chinese restaurant and was amazed at how tasty it was, so I then spent the time to figure out how to cook it in such a way that I actually enjoy! It's not exactly close to being my favourite ingredient, but I do now eat it fairly often since it's healthy and tasty.
I think this experience - being put off tofu by the amount of people who make awful tofu dishes under the justification of it being healthy and vegan - is quite common, and it would be great if more people can discover ways they actually enjoy it.
(Side note, my #1 favourite way of preparing Tofu is roughly this recipe - I'm away from my desk and can't remember the tweaks I made, but they're not significant: https://frommybowl.com/crispy-tofu-recipe/ Bake it following that recipe, then it's ready to chuck into a salad, or stir fry, or some sort of sauce, or...)
I mean, disliking a food because it was cooked incorrectly is the problem of the eater, not the food. I can cook a steak well-done, that doesn't mean all steak is now bad.
If you're going to be pedantic then clearly steak and tofu are both dead forms of protein so they don't care whether people eat them or not. When I said it's a problem for the food I obviously (I thought) meant that in western countries it's a problem from the point of view of it becoming a popular food.
It's a problem because it's cooked incorrectly in the Western world. That's again not the problem of the food itself but of people not learning to cook it properly.
1B+ asians eat tofu as a regular ingredient and not as a "meat alternative missing any kind of taste, smell or texture." In fact, not only are there DOZENS of kinds of tofu with wildly different textures and flavors, but even within a category, brands have big differences. The Japanese eat tofu uncooked and cold, drizzled with sauces (soy i.e. more soybean product!) and spices (ginger) - it's called hiyayakko, it's delicious and available as an inexpensive appetizer in most japanese restaurants and sushi bars.
I believe that achieving perfection in naming things is an elusive goal. This is not only because individuals often associate their own unique meanings with words, but also because a chosen name may inadvertently carry offensive connotations in different languages.
(in my opinion) Tofu is much better than the other alternative they suggested like Archo or EchoSphere.
Disclaimer - I also do some work with Env0 which is part of the OpenT(o)F(u) initiative
I'm aware of smoked tofu at least, but still, if you order, let's say, an Indian dish with tofu instead of meat, you usually get the "basic" tofu version.
If your experience of tofu is only the above, I completely understand your distaste for it. But I think you owe it to yourself to try better tofu, and not as a meat alternative. Tofu on its own doesn't have much flavour, but that's the point, you need to marinate it. Google can give you some tips (squeeze the water out, then soak it in something delicious -- hell, soak it in meat juices!), but I highly recommend trying some good, low moisture smoked firm tofu. It's so good, I often just snack on it, slicing it like a sausage. But it's also great in things like burritos to add a smokey kick. Try it!
> a meat alternative missing any kind of taste, smell or texture
1. It's traditionally not a meat alternative.
2. One should try properly cooked tofu before judging that it's "missing any kind of taste, smell or texture".
As a heavy terraform user who can't wait to migrate away from Hashicorp, I don't care. It's just a name. After the first dozen uses you won't even notice, it'll be as natural as any other command.
It's a nice pun and at the same time is close to the original, which would help Terraform users recognize the brand. Your suggestions are nice, but less recognizable in that way.
Maybe we can take that pun to extreme though! If they ever have a designer that can come up with some crazy lore of terraforming with tofu that would be really really awesome. But I think they have more pressing matters right now.
The current (yellow cube) logo is genius though! It's like they took the Terraform logo, which to me looks like a cube that has fallen apart, and put it back together into a cute little cube of tofu.
I’ve always thought terraform was kind of a perfect name, making large-scale changes to thousands of resources with a single command really does feel like terraforming.
It's just like the Genesis torpedo. You simply fire this torpedo from your starship at a (hopefully lifeless) planet or moon, and the Genesis Effect will re-form all the matter on the world, creating a world full of life, just the way you want it. You don't have to do any hard work like earth-moving, planting trees, etc., because the Genesis device does it all for you, quickly and automatically, according to your design.
terraform is the same: you just write a text file describing how you want a bunch of resources provisioned, run `terraform`, and it does all the work of provisioning those resources for you, quickly and automatically, according to your design. Honestly, I think it's a brilliant name.
Out of curiosity, how does OpenJDK not get sued into fine pulp over this? Oracle owns the Java trademark and aren’t exactly known for being kind in matters of litigation.
I really like the new name and branding. Very cohesive, easy to pronounce, website looks good (and the benefits of this cannot be overstated). Hopefully the community can grow around it.
The link and github does not tell much what OpenTofu is. So I opened the official website. Again very hard to find out what it actually is. Goals and why it was created, and a hundred times that it's a fork of another product.
But still does not explain what it is or does.
I had to open the website of what it was forked from.
Yeah, but what is 'infrastructure as code'? For anyone not already in the know, this phrase doesn't mean "managing and provisioning data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools." (quote from Wikipedia), it just means nothing at all.
Yeah, but what is a 'computer'? For anyone not already in the know, this term doesn't mean "a machine that can be programmed to carry out sequences of arithmetic or logical operations (computation) automatically." (quote from Wikipedia), it just means nothing at all.
Edit: I don't want to sound dismissive, so let me explain the difference. Anyone coming to the website will be using a computer of some kind, and even if they for some weird reason don't, the verb "compute" does give a hint at what a computer might be. None of this is true for "infrastructure-as-code".
The target audience for a IaC project is probably people who know what IaC is. Or even people who know what "infrastructure" and "code" are, separately.
But a person who knows what "infrastructure" is likely thinks of roads and power lines and sewage pipes. A "data center", which is what "infrastructure" roughly means in this case, isn't exactly the prototypical example of "infrastructure", or is it?
Right now, most of its target audience already knows exactly what terraform is and why they're abandoning it, although I agree that pivoting to explaining independently of that is a good idea
For anyone not already in the know, "data centers" doesn't mean "building in which reside metal electronic machines that are connected by wires to other such machines all over the world, transmitting and receiving messages to one another" (quote by me), it just means nothing at all.
There's a base level of knowledge of terms that's assumed on this forum. Sometimes we are below that level, and sometimes we are above it. If you encounter "infrastructure as code" tomorrow, you will not react to it the same way, since now it's no longer devoid of meaning for you.
I am sorry, but your last sentence is basically "humans learn".
And, in case you missed it, no one here is asking what IAC is, most everyone in this forum knows, we are saying it's not super-transparent for a random visitor to their website and a better "what is this project about" page mentioning data centers a bit more and "we forked Terraform" a couple times less would be an improvement.
I assumed it mean representing various infrastructure (load balancers, http servers, microservices, databases, etc and their interconnections) as resources that you can add relations to in a code description and then it could resolve those as code, if you add new resources (code), it can work out dependencies and therefore help coordinate and make sure you don't overlook some critical link (like version compatibility) as developers add to it. It seems to have provisioning for CI as well.
True, I might have skimmed it. But even now that does not tell me much.
Best that I found was under Docs -> intro -> What is OpenTF?:
> OpenTF 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. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle
That could have been on the frontpage somewhere. Or in the github description.
Great initiative, and I'm sure that with the community's stewardship this will become a better tool than TF ever was. Me personally, I'm happy about the licence change because it pushed me to Pulumi and I'm absolutely loving it, which I could never say about TF, quite the opposite.
I had originally thought the project to be font related, ie. the Open Type Font. Not saying it’s clearer now but at least it doesn’t remind me of OTF anymore.
“You won’t have to financially support the project in order to benefit from it” is the usual selling point. Corporations will overlook a cute name if it’s free, relative to another product.
If your corporation(s) don’t resell service deriving from Terraform, then there’s no financial reason to switch, since they’re not subject to the licensing risk — at which point it doesn’t matter what the name of the project is, either.
It’s still possible to make an argument to switch based on “community exodus from the commercially-supported variant”, which is at least more likely to be of interest to a classical C-corp than “ethical duty to open source”, but if opentofu contributions can be mixed into existing terraform, then that might not stand up well either.
If the corporation makes a decision solely based on (for example) hostility to vegetarians, then the name will be relevant — but that’s an outcome that is too irrational to account for.
To what audience? For someone in a leadership position who is responsible for running their organization, optics are very important, and a silly name can hurt. We're already talking about a fork by a lesser-known organization with no track record. The silly name doesn't help.
- You can imagine a situation where Tofu keeps TF DSL compatibility but add useful new features to the runtime (better plan summary, multiple stack deployment, chained deployments, etc). That’s going to put Hashicorp under pressure to move quicker..
- … but Hashicorp publicly pleaded poverty over their development resource on TF as the reason they wouldn’t accept community PRs. You can’t just grow a team tenfold overnight. They’ve been quite deliberate about the design of the Terraform language and runtime over the years, taking their time to add new features. It’s going to be interesting !
- The provider situation looks fairly safe to me. Those licenses didn’t change and you can always redirect to github releases for the really popular binaries ?
I believe Dave McJannet, HashiCorp's CEO, should be concerned. OpenTofu has garnered massive support, with the project gaining admission to the Linux Foundation and even receiving public support from companies like Allianz. Within HashiCorp, the CEO has fostered a toxic culture characterized by a large workforce that strives to do as little as possible, relying solely on the dedication of a few committed employees, many of whom left the company shortly after the IPO.
The pricing "strategy," the culture of secrecy, subpar commercial and marketing practices, and the company's inability to formulate a successful cloud and monetization strategy are all squarely the responsibility of HashiCorp's CEO. Merely changing the licensing approach will not resolve the current issues. There is an urgent need for a change in leadership, a more robust embrace of the community, and the addressing of the issue of lazy employees. HashiCorp should also return to its core principles, possibly trimming down its focus areas (Integrity, Kindness, Pragmatism, Humility, Vision, Execution, Communication, etc.).
Terraform had the greatest potential for monetization within HashiCorp, but this required innovation and effort. They possessed all the necessary tools, brand recognition, and community support, but instead chose to impede competition, failing to realize that they were harming themselves in the process.
OpenTofu has the potential to genuinely enhance Terraform, as changes will be viewed not as aiding competitors but as a shared initiative aimed at improving the entire community and sharing the benefits.
> OpenTofu has garnered massive support, with the project gaining admission to the Linux Foundation and even receiving public support from companies like Allianz.
I don't know. It feels like this support comes from the vocal minority and competitors.
I'll believe such a statement when more big multinational companies show support. Right now, I don't believe there is as much support as is currently made out.
There are around 19 full-time engineers staffed for the project from various companies. That is a lot more engineers than HashiCorp themselves had developing Terraform at the time of the license change.
I do wish, for their own good, OpenTF/Tofu would stop making this comparison. What insight do they have about HashiCorp’s resourcing beyond some git commit history? Surely these folks know there are many more folks involved in providing a product with the scope of TF than just those committing code. While I do find myself nodding along to many of the OpenTF points, whenever I hear this one on podcasts and such it comes off as very naive.
This name confuses me as I usually expect things named "OpenFoobar" to be open versions of "Foobar" (see: OpenJDK, OpenTTD), but here that’s not the case.
"Terraform" is trademarked and cannot be used without permission and "TF" is kind of on the edge, so it was decided to change it more to avoid any legal challenges.
What are OpenTofu's plans around CDKTF? Will that only work with HashiCorp TF going forward? Or will that be forked as well?
Terraform is a better foundational layer than CloudFormation, but CDK is by far the better level of abstraction, I believe. AWS CDK is decent, but it is of course limited to AWS. CDKTF was one of the more interesting initiatives in this space.
Indeed. While I don't "like" the name just yet, it's already pretty recognisable yet not "Terraform"-ish in branding. I suppose that's also a bit of a downside since Terraform is such a brilliant name for the thing that it does.
We pretty much talk in terms of "let's terraform a new environment" at places where we use it.
It was never called OpenTerraform, they knew enough to avoid that as an obvious trademark problem. It sounds like after consulting with lawyers they determined even OpenTF was too close [0].
The criticism of hashicorp seems childish. Why shouldn't they restrict the way in which companies make money from their inventions as they see fit? There's a lot of thoughtless entitlement among some of the attitudes being expressed in this debate.
HashiCorp is free to make money, but to take the work on community contributors and relicense it for its own gain is the biggest scam an "open source" company can commit. HashiCorp's inability to license their software effectively is what got them into this mess. Instead of using a license like the AGPL, they left themselves open to this attack. Why would you have sympathy for a company that dug their own grave?
I think at this point we exhausted arguments on both sides of the debate. I think that agreeing to disagree and moving on is a better alternative to competing on ad hominems.
It's easy to say that when it is not your work others are making money on
Just "moving on" is like putting your head in the sand to avoid difficult conversations about financially sustainable open source (which requires an amount of unopen-source if we're going to be honest with ourselves). Donations and charity don't put food on the table for those building the projects.
We have not figured this out as a society, so we should keep talking and debating
Many of these discussions seem to devolve into calling names, throwing ad hominems or even darker stuff like threats of symbolic or physical violence. Being on the receiving end of all that in relation to the fork makes me wish we can indeed move on and resume the conversation when the tempers cool down.
It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think it would be nice to have it clearly visible on the website, too.
Is OpenTofu also planning to maintain the language server (terraform-ls) or is that not within the scope ? I was not able to find any language server related repository.
Bigger players naturally take longer to reach decisions for projects that are not their own, so it's only natural to see some caution on their end. It would be premature to announce anything at this point but I can just say that "good things come to those who wait".
I was seriously expecting some sort of open sourced tools for making tofu. As a vegetarian that likes to cook I was a little disappointed, but this sounds good as well.
In its original producing country it's often used as an expression of excessive softness ("tofu mental" for instance, for mental fragility). But it's also cute and inoffensive, I think it's a nice name overall.
I think OpenTofu should embrace the negative connotations. Go crazy, make everything Tofu, that's the goal. It'd be a nice side history for marketing purposes. I doubt anyone would not use the tool because of it and others would get a good chuckle.
Is terraforming even a thing outside of the realm of SF? I can't say I've ever seen it depicted as anything but positive, since it's taking unlivable planets and making them livable.
there are countless SF examples where terraforming is used against the protagonist group in some negative manner; some alien race begins some scheme to turn the planet hotter/colder/acidic/whatever and has to be stopped by some hero.
as far as being a thing outside of SF, there are lots of studies on the idea of being able to do it in one way or another to both the moon and Mars, with real life validation efforts here on Earth -- but no real practical efforts as far as I know.
p.s. the reason I avoid mentioning our efforts here on Earth changing the climate being akin to terraforming is that I think that intentionality is really the defining feature of terraforming that differentiates it from pollution or abuse otherwise.
There are plenty of examples of terraforming going/having gone wrong or being abandoned.
My first associations are Snowpiercer (overdoing the fight against climate change) and Stellaris (abandoned machinery on planets).
There is a thing called acronym, abbreviation, or initialism copyright.
For Hashicorp's Terraform, "TF" is a well recognized abbreviation.
Hashicorp can't prohibit anyone from using "TF" in all areas, but it can argue that "OpenTF" confuses users that expect anything "TF" to mean "Terraform".
You can probably create a "OpenTF juice maker" without problem but OpenTofu especifically is in the same area as Hashicorp's Terraform, so it's better to avoid any trouble there.
Well, I guess this is more motivation to leave HCL and anything related to TF... tofu? Poor naming choice imho, searching is going to be a terrible time, wonder how confused the ChatGPTs will get?
I'm allergic to soy and derivatives like tofu, so not liking this name change
A CUE powered solution will be much better anyway, go straight to the APIs for definitions, no intermediate, yet still unique, (leaky) abstractions
The API definitions (even the good ones, like Azure) do not contain sufficient information to be able to build a declarative tool. Google seem to view their internal annotations about what is mutable or not as some kind of competitive advantage (bizarre). The AWS API is wildly poorly specified for building anything except 1-1 API wrappers. (Cloud Control improves it, but covers few important resources).
Everything has gaps that need to be filled, the main point is that the object I send is the same shape and schema as the API, same for their responses and the data in the system.
TF under the hood is using these APIs through an abstraction.
I say "go to the APIs" as (1) bypassing abstractions (2) in CUE, we can import the existing TF resource schemas from the Go types, or from the OpenAPI schemas. There are 2 camps in CUE about how to approach the CUE/TF/Helm/k8s intersection (one for each way)
CUE actually offers a really great space to enrich the APIs with the needed information.
CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider (whether TF, Pulumi or anything else!) can be generated from a cloud provider API specification.
The only cloud that offers a really declarative API at all is Azure, via Resource Manager.
For AWS, since most APIs are request-response focused (AttachENI, DetachVolume and so forth), something has to tie all that together to make a resource-focused API.
> CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider
100% agreement
What CUE potentially makes great is going from what the API spec has available to what we need by keeping the enrichments by us in the same space, so we merge or unify into a single space, without having to write code in the imperative sense. You get to stay in a logical space that will ensure what you write remains self consistent. It will catch the gaps and issues earlier.
I'm not aware of any config language or other technology that looks to make this processes as good as CUE can, except maybe sprinkling some of that magic LLM dust on the problem too, which CUE will help in double checking as well
Modern search engines and LLMs have no trouble distinguishing between different things with the same name. Google Trends will even show you something is a product, a service, a book, whatever. If you ask a LLM "what is this tofu infrastructure as code tool I keep hearing about?" it will 100% tell you about the tool and not the food.
nothing is 100% with LLMs, except that they will make things up at some point
Search is also struggling more and more each day to surface the actually relevant results. It's part of why people are reaching to LLMs for things they used to search.
I'd like to add that as of today (announced just now at OSS Bilbao) we're officially part of the Linux Foundation[0]!
Hope you like the new name (it basically won the votes anywhere it was proposed) and happy to answer any questions!
[0]: https://www.linuxfoundation.org/press/announcing-opentofu