OpenTF is now OpenTofu
github.com
github.com
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
Open Source businesses have no future in a world where big tech can gulp your product for free.
The OpenTofu folks will probably even raise capital to support commercialization of their thing at some point.
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.
[1]: https://lunni.dev/, a Docker Swarm dashboard
Their stuff pretty much all competes with it.
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.
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.
Terraform is immensely valuable.
The open source bits is 90% of that value.
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.
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.
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.
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.
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.
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.
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.)
What is the ratio of terraform dev vs third party dev in most popular terraform modules?
save themselves from others building a less shit version of terraform cloud.
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.
“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.
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.
Developers are so entitled, they don't even ever reflect they are taking without giving back all the time.
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.
I assume there may be forks of the older code but I don’t actually know.
How about "Genesis" or "Reliant" or "Marcus" or "Kruge"?
tofu is short for torafurm.
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.
So it was a clever comment but not particularly a joke (maybe a not so good one?)
I have a feeling that the designer may find it... challenging.
Or a globe with a tofu on top. Make the tofu evil/insane and create a story it wants to transform every plant in tofu.
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.
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.
Here are some links that are specifically about the name change:
- https://github.com/opentofu/opentofu/issues/296
- https://techcrunch.com/2023/09/20/terraform-fork-gets-a-new-...
- https://www.theregister.com/2023/09/20/terraform_fork_opentf...
"The name OpenTofu was adopted out of concern for, as you might have already guessed, trademark litigation."
Because Hashicorp might not like the "TF" (for Terraform).
What I think you are talking about when you say OpenJDK is called Adoptium now (https://adoptopenjdk.net/releases.html). Earlier called Adopt OpenJDK.
Similarly Eclipse folks named their project Temurin and so on.
“Eclipse Temurin is the name of the OpenJDK distribution from Adoptium.”
(Reference for non-UK viewers: https://www.theguardian.com/politics/video/2022/oct/18/suell...)
Also lol.
Whatever else, but you have to give her props for inventing the word "wokerati". That word sounds so ridiculous that it might become cool again.
Perjorative labels aren't what they used to be, people are happy to be labelled most of the time, so yes, maybe it'll be cool to be a, erm, "wokerat"?
Well done and good luck keeping up the momentum.
Hasn't that ship sailed? Even if Hashicorp did that, would the community still be willing to mend this breakup, or declare that trust was lost?
But still does not explain what it is or does.
I had to open the website of what it was forked from.
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".
And I don't get why it's hidden, but instead they tell the reader multiple times it's a fork of something else.
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.
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.
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.
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.
- Maybe do nothing, and as long as OpenTofu doesn't attempt to extend Terraform they are in not that different a position than pre-MPL.
- Add so many features OpenTofu can't keep up?
- Add some sneaky code to latest versions of hashi providers which makes them not work with unofficial terraform binaries?
- … 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 ?
Intriguing ideas. Would you mind elaborating or - even better - open issues [0] explaining the concepts to gauge the community interest?
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.
That is a serious accusation. What backup do you have for this statement?
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.
Various companies being all HashiCorp competitors: https://opentofu.org/supporters
In that case it’s quite obvious that "search" is not a product, and so this should be an open-source search engine.
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.
Stop struggling with HCL files, there is a solution.
[0] https://github.com/opentofu/opentofu/issues/273#issuecomment...
We pretty much talk in terms of "let's terraform a new environment" at places where we use it.
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
I predict that it will be commonly known as "Tofu", which is a wonderfully snappy name. Almost too good for this kind of project.
(Edit: added a bit of context as parent comment suggesting you can interpret the new name as open to fuck was removed)
[0] https://en.m.wikipedia.org/wiki/Great_Plan_for_the_Transform...
I'd argue your "in a few years" was like 2018 or 2019 or so.
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.
Terraforming is a sci-fi concept for making planets viable for life......
What's the other usage?
Some people associate it positively ('ethical', 'wholesome', 'tasty'), others do not ('not the real thing', 'tasteless').
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.
It also makes me think if Fujitsu's interconnect for their crazy HPC ARM chips (PDF warning): https://www.fujitsu.com/global/documents/about/resources/pub...
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
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.
Do you really think no-one has tried that?
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).
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.
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.
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