I wish Hashicorp all the luck in the world with their product, however they choose to license it, and whether they chose to keep it Open Source or not. It's th

I wish Hashicorp all the luck in the world with their product, however they choose to license it, and whether they chose to keep it Open Source or not. It's their product -- they can do as they wish. Simimlarly, I wish the OpenTF Foundation all of the luck in the world in their efforts to persuade Hashicorp to keep Terraform Open Source. I am not affiliated with either group; I wish both groups well in their respective positions; I am not affected in any way by Terraform going closed source, or forking, or whatever. One of the paradigms that I think in is that of Software Engineer, and that of first principles. The basic "problem" that TerraForm is attempting to solve is that of "cloud provisioning". "Cloud Provisioning" is a fancy name for "Infrastructure Provisioning" which is a fancy name for both "Server Provisioning" and "provisioning other services related to servers" remotely. Which in turn are fancy names for "create and configure a remote computer or VM" (VM's are effectively remote computers) or some piece of software or infrastructure related to one. Which are in turn fancy names for "spin up a remote server and/or something related to one or more of them..." Pretty simple, pretty straightforward, once we drill down through all of the layers of linguistic sediment... Problem is, in general, no two cloud computing providers -- use the same API. That is, AWS's API is in general, different from Azure, which is different from GCP, which is different from other providers, etc., etc. Here, have a look at some of them (there are quite a few!): https://registry.terraform.io/browse/providers https://registry.terraform.io/browse/providers The net effect is or should be, that Terraform creates its own abstraction layer, its own API -- over all of these other disparate and ununified API's, sort of like "The One API to bind them" (Compare to how Microsoft Windows in the early days created a unified API across disparate PC hardware components created by multiple vendors). With this unified API (or secondary abstraction layer if you prefer, API of API's), now code can be ran to programmatically automatically ad hoc add/modify/delete cloud infrastructure components (which remember, is a fancy way to say "servers and things related to remote servers") as needed. Thinking in this way then, it wouldn't be necessary to fork Terraform and/or keep it Open Source. If one were a Software Engineer, and one were inclined to, they could start building a rival Open Source product which would match the above functionality, completely from scratch with no dependencies on Hashicorp's code or licensing. Already there seem to be more than a few Open Source projects in this space; and while many may lack the depth and breadth of Hashicorp's product, it will only be a matter of time before one or more becomes dominant. The key word to search for in this space, on GitHub, is "cloud management" What follows is a list of early Open Source contenders in this space: https://github.com/topics/cloud-management https://github.com/topics/cloud-management To recap, I wish both Hashicorp and the OpenTF Foundation well in their respective quests. I expect to see many (and many other) non-affiliated Open Source cloud management tools and API's in the coming years... it's an interesting space...