Live data from Hacker News

The OpenTF Manifesto

opentf.org

261–270 of 392 posts

Re: The OpenTF Manifesto

#261
post #7

Also, update from Spacelift, we believe that we are not in violation of the new license, you can find more details in our today's announcement[0]. We nevertheless support this initiative, though, as written in the article itself. [0]: https://spacelift.io/blog/spacelift-latest-statement-on-hash... Disclaimer: Work at Spacelift

You guys effectively sell cloud-based TF instances though, don't you? Pretty sure that's a no-no...?

> cloud-based TF instances

Not sure what specifically you mean with this.

Anyway, the devil’s in the details, of both the license as well as the internal architecture of our system. I can’t share more here, but if you’d like to learn more please reach out via our chat or email. You can also expect more updates on our blog.

Re: The OpenTF Manifesto

#262

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

I have a hard time thinking of how terraform as a piece of software can do to much more than it already does to fix things? When terraform fails, it's typically because of a an API error or a configuration issue that is beyond its control? Not handling state rollback is a design decision that, having dealt with the fun of CloudFormation, I'm pretty happy that they made.

> I have a hard time thinking of how terraform as a piece of software can do to much more than it already does to fix things?

Oh, that one's easy: have the "plan" phase actually consult the underlying provider in order to know the straight face errors that are going to fail 60% of the way through your "apply" phase. I thought about including an example, but I don't care to try and lobby unless the community fork takes off, because Hashicorp gonna Hashicorp _their_ baby

Look, I know the TF community is allllllllllll about that Omniscient .tfstate file but (related to the sibling comments about the tool _being helpful_) the real world is filled with randos in an organization doing shit to underlying infra or humans fat-fingering something and it is not a good use of anyone's life having to re-run plan and apply due to some patently stupid but foreseeable bug

Re: The OpenTF Manifesto

#263

Earlier quoted context omitted.

There is a big difference though Terraform is the out and out winner in its market. All their other products are at best small x% share of a crowded market or dominated by another product.

Genuinely curious - other than Vault - what other product is there for secret management in the cloud infrastructure space. I get that CyberArk Conjur is big in the enterprise space, but I thought cloud users, even with k8s, mostly went with vault.

You generally only run Vault if your secrets don't/won't/can't reside on a public cloud service.

Re: The OpenTF Manifesto

#264
post #245

Earlier quoted context omitted.

it's not war hashicorp has decided they don't want to contribute to open source any more they're totally within their rights to do so, and it doesn't harm anybody; it's not the equivalent of going around blowing up buildings, raping women, and napalming children. at most we can wish they had continued doing the beneficial things they were previously doing maybe they'll change their minds, as you say, but that's no re…

I apologize if I appeared to downplay the horror of actual war. I'm lucky to never have experienced it first-hand. I mainly wanted to focus on the "civil" than "war" aspect of the possible schism.

it's not a possible schism. hashicorp has clearly and unmistakably abandoned the open source community. conceivably they'll change their minds, but their communication doesn't have any ambiguity in it

i have no idea what you could possibly mean by 'focus on the "civil"'. it's good that people are being civil to one another, isn't it? then why are you criticizing them?

Re: The OpenTF Manifesto

#265
post #245

Earlier quoted context omitted.

it's not war hashicorp has decided they don't want to contribute to open source any more they're totally within their rights to do so, and it doesn't harm anybody; it's not the equivalent of going around blowing up buildings, raping women, and napalming children. at most we can wish they had continued doing the beneficial things they were previously doing maybe they'll change their minds, as you say, but that's no re…

I apologize if I appeared to downplay the horror of actual war. I'm lucky to never have experienced it first-hand. I mainly wanted to focus on the "civil" than "war" aspect of the possible schism.

FWIW there are still people (dozens of us!) who don't feel the need to be artificially offended by a bit of hyperbole on an internet forum.

Re: The OpenTF Manifesto

#266
post #76

Terraform core is kinda crappy. The language is awful, and the module infrastructure sucks. I would support (with my own money) a fork that would re-use the Terraform providers, and reimplement the language as something not so insane.

Having recently picked up Rust (yes, sorry for mentioning it, I promise it's relevant), I picked up Terraform the other day. I was shocked by how weak its language-level developer experience story is. I am working in VSCode, which by and large tends to be the editor supported best, with the most mindshare. Terraform has static and mostly strong typing, yet some testing revealed I was able to pass an argument of the w…

No need to be sorry about mentioning Rust :)

Yes, can confirm the terraform language server is kinda unreliable. We could both be doing something wrong, but it seems like that's a common outcome.

Re: The OpenTF Manifesto

#267
I don't think the license change is unwarranted. At a previous employer we used Terraform but the pricing on the cloud/enterprise offerings was prohibitive enough that we instead had a dev create simple wrapper scripts in our CI/CD system to run the deploy jobs. Significantly cheaper, but I spent years pushing for us to eventually move to the paid offerings as the developer experience was significantly lacking (and to support Hashicorp), up until I left the company. I think they're still using those wrappers today despite how awful they were to use.

There was definitely room for improvement around using Terraform to do actual deployments. From better UX around doing PR's -- showing not only the commit diff but the output of a "tf plan" as well to see what it might actually do -- to actually running the deployments on isolated build machines that could hold the sensitive cloud API keys and provide a deployment audit trail, these were all features that teams absolutely needed to use Terraform sanely. As a solo developer you don't really need those features, but if you're on a team you definitely did, and were almost certainly willing to pay for it. Hashicorp recognized that need and created the cloud/enterprise offerings to provide that.

At some point the thought even crossed my mind of creating some open-source tool that could provide a nice enough web interface for dealing with Terraform for teams, building on what we had and providing the features I listed above, but the main reason I didn't was because it would be biting the hand that feeds. Such a tool would take away people's incentives from using Hashicorp's paid offerings and ultimately reduce their investment in Terraform and their other fantastic tools, and in my opinion, be disrespecting the tremendous work Hashicorp had done up to that point. I've been a user of their stuff since they only had Vagrant, and of course have loved them seeing them succeed.

It seems others, however, had different opinions and saw a business opportunity thanks to the permissive licensing and the high costs of Hashicorp's paid offerings. Plenty of money to be made from making it easy to use TF in teams, especially when you're not obligated to contribute back or maintain the underlying software [1]. Any time I saw a "Launch/Show HN" post from a company that was offering such TF wrapper web interfaces, I kept being surprised that Hashicorp hadn't yet clamped down on preventing lower-cost offerings of their paid services. It was only a matter of time.

[1]: I realize this reads as overly harsh to some of these companies, especially as some of them are in here replying and pledging to give back, so let me try to explain my reasoning here. When I use a product, I like it when the source is available from me to learn from and understand how it works [2] and to contribute back to for needed features or bugfixes [3].

When a company makes a product open-source, that's great! But if that product is the core of that company's business model [4], and another company starts competing with that company using the same open-source product, then I see a problem down the line. While you can make the argument that the competition is good and motivates the two companies to compete on the value they bring to their customers, which is a net-benefit to the open-source ecosystem as a whole as the open-source product is improved, it eventually turns into a race to the bottom. Pricing will be used as a core differentiator, reducing the overall R&D spending on the open-source product because ultimately the two companies have to maintain non-R&D staff like sales, finance, and support. If the Total Addressable Market is fixed (obviously not, but work with me), then that's two or more companies with the same fixed non-R&D costs diverting revenue that could be spent instead on improving the open-source product. Sure, the reality is that a lot of that revenue isn't going back to the open-source product, as a lot of people are complaining about in the comments, but that diversion is probably going to happen anyway whether there's 1 company or 20, so I'd accept it as a cost of doing business.

If instead the competition were on providing a better but different open-source product in the same space (e.g. Pulumi), rather than working off the same base, that would be a different story. But if developers keep seeing businesses take open-source projects and directly compete with their creators, then I think we're going to see a net harm to the open-source community as it creates a sort of chilling effect as it'll demotivate them from going the open-source route so that they can find a viable way to sustain their efforts. I think licenses such as the BSL and SSPL are valid enough compromises, considering that even mentioning the AGPL inside of a lot of companies seems to be like someone saying Voldemort's name. We can't rely on large corporations sponsoring open-source projects, either with money or developer time, if we want them to succeed.

We grant inventors 20 years of exclusive-use on an invention, provided they explain how to reproduce it through the publishing of a patent. What's the difference between that and the BSL? I see a lot of complaints about bait-and-switches, but I don't really see the issue. If you contributed to the project under the old license, it's still available under the old license! You just don't get any of the new changes starting from the license change. If you decided to use Terraform in a non-competing way [5] solely because of the old license, and are concerned about the new one, then you have to recognize that Hashicorp is now another addition to a long-line of "open-core" companies trying to deal with the reality that companies will make money any way they legally can. This is where the industry is currently headed, and whatever replacement you find will probably be next.

If you believe different, then make an open-source offering, and don't just make a public statement saying it'll be open-source forever. Public statements are great and all, up until there's doubts about meeting payroll. Find a way to make the statement legally binding and then we're talking. Which is I guess why there's so much consternation, since the way to do it is through the license, but the OSI doesn't recognize any of these other licenses as "open-source" and the AGPL is a non-starter at most companies.

[2]: Reading the source code for libraries I use has been incredibly valuable in my understanding of how to use the libraries properly, much better than any documentation could. And of course, makes me a better programmer in the process.

[3]: At one point, Terraform was missing a feature that I badly needed. With the source available, I could easily get a new version of it running locally with that feature to unblock me, and then everyone benefited when I contributed it back to the project. It's also been invaluable having these locally modifiable builds to understand the quirks of products from cloud vendors, and to work around them. Ever had multiple deployment pipelines fail because Azure decided to one day change the format of the timestamps they returned in API calls, without publishing a new API version? I have.

[4]: As opposed to supplementing their business model. Google open-sourcing K8s was great for them because it drove adoption of their cloud VMs. Their cloud business makes money off the VMs, not GKE, so sponsoring K8s is essentially a marketing expense. But for Hashicorp, their core business model is paid offerings of their products.

[5]: Yes, I get that the license currently is un-clear, for all their products. But let's simply say that you're not trying to directly sell a wrapper around running Terraform.

Re: The OpenTF Manifesto

#269
post #185

Earlier quoted context omitted.

You and the OP are referring to different things. Terraform the codebase has a test suite. Terraform the app does not have a test suite/runner as in a way to run tests against your Terraform files.

It doesn’t have a testing tool built in. No one legitimately understands the phrase “terraform doesn’t have a test suite” to mean anything except “there are no tests”. A runner and a suite are quite different.

I can understand the miscommunication in the first post, but I clarified in a direct comment to you what I meant. I was even comparing it to Terratest, which is not used for testing terraform core. At this point you're just being belligerent for the sake of being belligerent.

Re: The OpenTF Manifesto

#270
post #264

Earlier quoted context omitted.

I apologize if I appeared to downplay the horror of actual war. I'm lucky to never have experienced it first-hand. I mainly wanted to focus on the "civil" than "war" aspect of the possible schism.

it's not a possible schism. hashicorp has clearly and unmistakably abandoned the open source community. conceivably they'll change their minds, but their communication doesn't have any ambiguity in it i have no idea what you could possibly mean by 'focus on the "civil"'. it's good that people are being civil to one another, isn't it? then why are you criticizing them?

You're missing the point- the OpenTF group wants to mend the schism if possible, by getting Hashicorp to change their licensing back. If they immediately fork then that's not likely to happen, so they're attempting this first.

I don't think it will work, but I think it's good of them to try.

Post reply on HN