Live data from Hacker News

The OpenTF Manifesto

opentf.org

141–150 of 392 posts

Re: The OpenTF Manifesto

#141

I appreciate the letter and trying to work with Hashicorp -- I used to have a ton of respect for Hashicorp. But honestly... at this point... ...just fork it into a foundation. Don't wait for Hashicorp's response. I get wanting to have the appearance of working with Hashicorp, but we've been shown again, and again, and again, and a-fucking-gain that private corporations cannot be trusted to maintain public goods. Only…

Speaking of nuclear options, need to get the providers to pledge/follow the fork, maybe via some kind of API incompatibility. Terraform is useless if the providers don't work with it and only the fork. Focus on disrupting the ecosystem.

This is the interesting part of all of this. The meat of Terraform is in its provider ecosystem. Anyone can make a new frontend (or even fork the existing one?), get rid of all the warts, add the missing encryption features gated under enterprise and have a much better tool.

Re: The OpenTF Manifesto

#142
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 all to just blow up and force you to figure out how to make the software work again.

Configuration management tools should make your life easier, not harder. You shouldn't have to hire a "Terraform Admin with 3 yrs experience" just to learn all the bizarre quirks of this one tool just to get your S3 bucket to have the correct policy again. You shouldn't have to write Go tests just to change said policy. It's like it was invented to be a jobs program for sysadmins.

I have a laundry list of all the stupid design decisions that went into the damn thing. And because the entire god damn industry is stuck on this one tool, no other tool will ever replace it. Its providers are so large and there are so many modules created that it would take years of constant development to replace it. So it doesn't get changed or improved, and it can never be replaced. It is the incumbent that blocks progress. A technological quagmire we can't extricate ourselves from.

The essential purpose of this tool is really to be a general interface to random APIs, track dependencies in a DAG, pass values into resources when it has them, attempt to submit a request to the API, and then die if it doesn't get a 200 back. We can accomplish this in a simpler way that is less proprietary and more useful. And we can ramp up on specific functionality to give the solution actual intelligence, like default behaviors for specific resources in specific providers, hints on how to name a resource, more examples, canned modules that are easier to discover or publish, ability to use different languages or executables, etc. But we need to put forward those alternatives now, or we won't get the chance again for a long time.

Re: The OpenTF Manifesto

#143
post #72

We need a new word for this. We say OpenTF is (or will be) a fork, and forks are bad, nuclear option, etc, but really, Hashicorp are the ones who made a breaking change, and the "fork" merely maintains that which already was, but for reasons, are not allowed to continue using their own name. We need for the shortest sound-bite 3-word sentence to the non-technical to somehow use terminology that says that the entity t…

The issue with that is the ownership of the name. Name is identity, and thus the canonical representation of "Terraform" is now BSL. However, if you don't have an identifier such as the trademarked name and you look at the project itself then I think you're right.

It can be rebranded, that's pretty straightforward for something that's such an industry standard. "Oh yeah? Earthworks? That's the open source fork of Terraform" pretty simple. If it were a lesser known technology it would be an issue but most of the (modern) internet runs on it, whatever they name the fork will be well known pretty much instantly

Re: The OpenTF Manifesto

#146

As a regular end-user of Terraform, what difference does BSL vs MPL make to me? From reading this article it seems not very much? Perhaps I'm misreading this.

You can continue to use plain Terraform forever. It would only affect you if you use a tool like Env0, spacelift, Gruntwork pipelines, etc instead of something like the Terraform Cloud. These tools are not going to be able to be used with users using new Terraform versions (though they can always use the current or any previous versions, or can use their fork these companies are jointly supporting). Then there are op…

> These tools are not going to be able to be used with users using new Terraform versions

As discussed in the other thread, we believe that we are not in violation of the new license, you can find more details in our today's announcement[0].

Disclaimer: Work at Spacelift.

[0]: https://spacelift.io/blog/spacelift-latest-statement-on-hash...

Re: The OpenTF Manifesto

#148

If any Hashicorp people are reading, can you please tell your middle and senior management that this decision has deeply soured my entire DevOps cohort on continuing to use Terraform in the future. We're already exploring alternatives. Future client projects may not use Terraform at all. Languages and frameworks must remain open or they will wither and die.

As a Free Software advocate and supporter, I'm thinking about the answer to this question: - MPL is a weak-copyleft license, which allows companies to grab and run Terraform codebase, provide it as-is (as Terraform), or as white-labeled Terraform compatible feature/layer. This is alright (because license allows this). - These people also contribute their own fixes upstream, which is great, and maintain their own patc…

IMO: HashiCorp is in this situation because they want to grow too big, too fast. A lot of their software is tooling, tooling that doesn't necessarily make sense to sell in a SaaS offering, or if it does: it's going to be commoditized. However, SaaS is where the $ is. They have investors they must please, and they want a big return on investment. It's probably too late to fix this, but IMO if they took the slow and steady route of providing support and professional services HashiCorp could easily be profitable while maintaining all of their products, but perhaps to a lesser degree.

Re: The OpenTF Manifesto

#149
As a long time Gruntwork customer, contributor, and fan, it is really nice to see them stepping up as thought leaders here. They run a great open source community already. Our DevOps team has been buzzing all day with what we are going to do. For now, we are staying pinned to the last open source version of Terraform and will likely follow Gruntwork's lead when the time comes.

Re: The OpenTF Manifesto

#150

If any Hashicorp people are reading, can you please tell your middle and senior management that this decision has deeply soured my entire DevOps cohort on continuing to use Terraform in the future. We're already exploring alternatives. Future client projects may not use Terraform at all. Languages and frameworks must remain open or they will wither and die.

I'm not Hashicorp, but I mean look at Docker. They built the most valuable devops tool of the last generation and can barely muster a viable business. Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers? The upside is lots of money and the downside is loss of halo. Honestly, it's an unfortunate game of expectation setting. If I wrote an open letter decrying Salesforce for not open sourcing their codebase, nobody would take me seriously. But we expect better from Hashicorp for some reason.
Post reply on HN