31 ms·

OpenTF announces fork of Terraform

• ohad1282 3y ago
  env0 founder here - we are honored to collaborate on bringing OpenTF to the world together with our friends and backed by a massive support of the community. #opentf
  • slomawa 3y ago
    Big supporter in this move! When can we use it?
    • ohad1282 3y ago
      Expect the repository to be published very soon, once we’re officially part of a foundation and have some basic community guardrails and processes in place.
• SebastianStadil 3y ago
  IMHO Hashi TF is the fork since they changed the license to a non-open source one. OpenTF is the same MPL license under a different name.
  • igorzij 3y ago
    [flagged]
  • bornfreddy 3y ago
    Yes. Worse than that, they changed to a license that prevents companies to use their product freely - if they chose some "cloud protection license" that simply handicaps possible competitors to their commercial offwrings, this fork would probably not happen, or at least it wouldn't have such momentum.
    • saxonww 3y ago
      They really didn't. They changed it to prevent companies from building commercial products around terraform, which is what you've suggested as a cloud protection license. Companies that use terraform to manage their infrastructure are not practically impacted in any way, except by this OpenTF effort (which I don't personally oppose either!) which will create a schism and leave us with competing tools that are not quite interoperable over time (thinking about ZFS/OpenZFS, MySQL/MariaDB, etc.). https://www.hashicorp.com/license-faq#usage-limitations https://www.hashicorp.com/license-faq#usage-limitations It isn't the AGPL, but I am just sort of stunned at the uproar around this. Is Hashicorp supposed to just shrug and clap while a competitor takes (primarily) their work and competes with them using it? That's what the MPL allows, and they don't want to do that anymore, so they... changed the license to protect their interests. What do you expect them to do?
      • SebastianStadil 3y ago
        What we expect them to do? How about making better commercial products to start?
        • swozey 3y ago
          I just went through about 20-30 SRE interviews while hiring an SRE II for my team. Every single one of them that had state management at all used terraform cloud. I found that really interesting because I've never heard positives about it vs the others (spacelift, env0, terrateam, brainboard etc). Not a single one of them had anything other than tfc. Not even atlantis.
          • technics256 3y ago
            That's funny, I've only ever used Atlantis with a smattering of tfc
            • swozey 3y ago
              I've only used Atlantis as well! We actually need to decide on a service next month. I haven't demoed it yet but I'm really aiming to use brainboard.co if it actually does what it says. It's priced per user, not some weird deployments a month price and it honestly looks amazing. Gives you a gui to move resources around, imports your current state, etc.
• igorzij 3y ago
  Digger here The future of Terraform is open-source We are beyond excited to be part of this great initiative. We did of course expect a fork to be of significant interest to people; what we did not expect is this crazy level of support for it. 2k+ stars, 100+ companies and 400+ individuals pledged, and there is already more full-time engineering positions committed to it by pledging companies than the whole Terraform Core team at Hashicorp (source: terraform commit history)
• cube2222 3y ago
  I'll join the other members of the OpenTF Initiative who've already commented - I'm honoured to be a part of this effort and can't wait for us to push this forward in the following days, weeks, months, and years! It's been a pleasure working with everybody from all the companies involved. Happy to answer any questions you might have! Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
• mkl95 3y ago
  > We completed all documents required for OpenTF to become part of the Linux Foundation with the end goal of having OpenTF as part of Cloud Native Computing Foundation Imho the best possible choice, and one that was easy to see coming when they announced they were joining "an existing foundation".
  • candiddevmike 3y ago
    Seeing OpenTF on the CNCF website would be glorious. TF has become too ingrained in the cloud operating model, CNCF is where it belongs. Maybe a Vault fork will join it someday. Will HashiCorp remain relevant throughout this? Seeing a lot of parallels with Red Hat's recent mistake...
    • stbenjam 3y ago
      There’s parallels but it’s not the same. Red Hat’s projects are still all fully open source. And it’s not clear it’s a mistake yet.(I work for red hat but this is my personal opinion).
      • kskkkkkkk 3y ago
        As with Sun in the old days, good luck actually collaborating as in a healthy open source project but the license doesn't specify there should be a community around anything so it's all good. Hashicorp doesn't have RH's moat at all.
        • gjvc 3y ago
          Hashicorp must be in panic mode right now. Expect layoffs! especially with them deleting pages like this https://archive.is/zfdmS#selection-1351.0-1354.0 https://archive.is/zfdmS#selection-1351.0-1354.0
          • bob778 3y ago
            They did layoffs about 2 weeks before the licence change.
• janosdebugs 3y ago
  First of all, congratulations, I hope OpenTF will live and prosper, I really liked Terraform when I was working with it. I'm wondering how OpenTF will handle the plugins. Will it pull from HashiCorps servers, or will it spin up its own plugin registry? If the latter, will the existing plugins be mirrored?
  • fishnchips 3y ago
    No immediate change with regards to how the plugins are handled. Longer term I think the entire plugin ecosystem could benefit from less centralized control, in the interest of all other projects that depend on it (eg. Pulumi, Crossplane etc). As OpenTF we are already working with other parties interested in keeping the ecosystem in good shape. But for now there's no change necessary, since the TF registry seems itself to just be a lightweight proxy to GitHub Packages, they don't seem to host anything themselves. (Marcin, co-founder of Spacelift, and one of the members of the OpenTF initiative)
    • janosdebugs 3y ago
      I think this should be addressed sooner rather than later. A lot of core plugins (e.g. AWS) are written by HashiCorp themselves and the license could be changed at any time, putting OpenTF users in danger of violating the license. Furthermore, to publish a provider one needs a HashiCorp account and agree to their Terms of Service.
      • wlonkly 3y ago
        I was under the impression that a lot of the cloud provider plugins were developed in close collaboration with, or even by, the cloud providers themselves. At a glance, three of the top four contributors to the AWS provider are from outside of Hashicorp, and two of those three are AWS employees.
        • janosdebugs 3y ago
          You may be right on that one, but they still have copyright headers like this: # Copyright (c) HashiCorp, Inc. # SPDX-License-Identifier: MPL-2.0 This is enforced by a GitHub Actions check on every PR.
• Pannoniae 3y ago
  I am seeing parallels to the Amazon vs. ElasticSearch fiasco. Also interesting to mention that they haven't said a single word about CLAs. If this project would require a CLA (and copyright assignment) to contribute, then it doesn't matter that it's a foundation, they could also re-licence it easily, which is exactly what they are fighting against.
  • lars_francke 3y ago
    You are technically correct but I do see a difference between signing a CLA with The Linux Foundation, Eclipse, ASF etc. and a purely commercial corporate entity.
    • Pannoniae 3y ago
      You are entirely right; it's nowhere comparable. I'm just talking about the theoretical impacts. (after all, the re-licencing was also a theoretical problem, i.e. Hashicorp might abuse the non-compete clause so Terraform is not safe to use) I just find it interesting to mention - after all, the important details the ones which are not talked about.
      • hyperpape 3y ago
        For at least a few years now, companies relicensing their open source software has not been just a theoretical possibility, but a plausible thing that could happen any time. I don’t know what happens to the Linux Foundation when we’re all in the nursing home, but them relicensing everything is not currently plausible. It is a merely theoretical possibility.
    • riku_iki 3y ago
      > signing a CLA with The Linux Foundation, Eclipse, ASF etc. what is the reason those require CLA? Why underlying license is not enough?
      • koolba 3y ago
        If there’s no intention of ever changing the license, then there is no need for a CLA. A CLA is required when the repo owner wants the ability to change the license down the road without contacting N contributors.
• lars_francke 3y ago
  Do similar initiatives exist for the other HashiCorp products?
  • mdaniel 3y ago
    I am hoping someone will take on Vault since it really has a unique perspective on credential leases that I don't believe its competitors currently tackle I have been trying to help https://github.com/vaagrunt/vagrunt https://github.com/vaagrunt/vagrunt but there are 4400 forks so it's hard to know if one of the other ones is getting "community buy in" - I just saw that one in another HN thread and tried to help out (it's always bugged me that there was no $(make dist) for Vagrant so hopefully here's my ability to fix that bug since Hashicorp was for damn sure never going to accept any such PR)
    • vmatsiiako 3y ago
      Credential leases will be available in Infisical soon! Disclaimer: I'm one of the founders.
      • mdaniel 3y ago
        is there an issue where one could track its progress, and whatever leases you're intending to support? My personal use cases are PG and SSH CA leases (err, back when I used SSH :-D but I'm guessing that's still a non-zero audience)
• halifaxbeard 3y ago
  I wonder how long until Hashicorp starts to use OpenTF as the upstream for TFE
  • re-thc 3y ago
    Right, suddenly someone's doing the work for them and for "free".
    • halifaxbeard 3y ago
      It’s a traumatic birth for sure- but I think in the long run Hashicorp took the right approach. There’s already more FTE commitments from the community than Hashicorp actually had working on it.
      • fishnchips 3y ago
        Marcin here, co-founder of Spacelift, one of the members of the OpenTF initiative I'm not sure. They voluntarily exchanged the throne of a benevolent ruler for an audience seat where they're one of many. I would personally think that this privileged position was worth more than the cost of the FTEs devoted to the project. But obviously I don't see the whole picture.
        • lamontcg 3y ago
          Its certainly going to be interesting to watch how it all plays out.
      • eropple 3y ago
        How did Hashicorp "take the right approach"? They wanted $$money$$, they didn't want Terraform to be bigger or better or to cede control of it to anyone else. Having seen Spacelift, Pulumi, etc. over the last few years, I have little trouble envisioning them jumping to help with some alacrity if a Hashicorp that did want improvements did the work to move it to a software foundation themselves. But again: $$money$$.
• re-thc 3y ago
  How will providers be handled? If Terraform changes the protocols and interfaces it sounds like a game of cat and mouse. The providers will support Terraform and update to the latest framework, which may be incompatible with OpenTF at the time. Are we forking those too?
  • cube2222 3y ago
    Initially we strive for 100% interoperability. The provider framework has been kept MPL, as have the providers, so we will keep being compatible. We will see what the longer-term future brings, and we'll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it's in place. Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
    • jen20 3y ago
      > currently temporary Technical Lead of the OpenTF Project Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).
      • ahl 3y ago
        I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.
        • jen20 3y ago
          I doubt that "clean room" fixes for each new commit in Terraform can be authored in order to maintain compatibility with the canonical source.
      • fishnchips 3y ago
        I pity anyone who underestimates Kuba. OK, most people I've worked with in tech are probably smarter than me, but this guy plays in a different league.
• andrewstuart2 3y ago
  I'd really love to see this continued for some of the other hashicorp tools that have taken the turn to closed licensing. Vault is at the top of my list, but definitely some others like consul and vagrant seem like they have healthy communities that have been responsible for making hashicorp products successful, and stand to lose out with the whole switch part of this post-facto bait+switch.
• danpalmer 3y ago
  I'm thrilled to see that OpenTF appears to be aiming to win on positives, not negatives. They could be focusing on the licence and their perception of Hashicorp, but instead there's a lot of emphasis on the positive: getting up and running quickly, upcoming releases, public roadmap, and pledges of engineering work. In the long run few will care about this licencing change (as much as they should!) – business users will accept it, individuals won't take any notice, and competitors would get mired in issues as expected. Basically a win for Hashicorp. But winning on positive changes beats licencing issues. Business users will go where the centre of gravity in the ecosystem is, individuals will too, and will prefer free (in both senses) solutions, and competitors will push this hard to all their customers. It'll be interesting to see Hashicorp needing to build OpenTF support into their products to remain compatible. > So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository. Wow. Even if most of this doesn't actually play out in the long run, that's some good support.
  • EspressoGPT 3y ago
    > They could be focusing on the licence and their perception of Hashicorp They literally do: "HashiCorp even had all contributors sign a CLA which explicitly said (link to the CLA in the Internet Archive as HashiCorp has of course removed this wording): [...] The move to BUSL—which is not a free and open source license—broke the implicit contract. That was the brash action! Terraform would've never gotten the adoption it did, or all the contributions from the community had it not been open source. Most of us would've never agreed to the CLA to contribute to the project if it was BUSL licensed. Taking all those contributions and all that community trust, and then changing to the BUSL license is a bait and switch." [1] I agree with the overall sentiment, but they could've left out all the judging side comments. [1] Source: https://opentf.org/#why-fork https://opentf.org/#why-fork
    • jen20 3y ago
      > "HashiCorp even had all contributors sign a CLA Of course, this is untrue. They may have had all contributors after some specific date sign one, but it is simply untrue that all contributors have signed one at all.
• dbingham 3y ago
  Well done all! I'm really excited to see the community taking ownership of this tool and moving it to a foundation. I'll definitely be using OpenTF for any future projects and if I find myself a part of or leading a DevOps team again, will work to migrate that team over.
  • Coryodaniel 3y ago
    Thank you, we appreciate your words! We’ll do our best to make sure if you have to migrate, it’s just a binary change.
• Coryodaniel 3y ago
  Massdriver co-founder here. We are super excited to be supporting this initiative. The community around Terraform has been pushed aside for too long. Terraform is the most widely adopted tool for managing cloud infrastructure. Putting it in the hands of a foundation that can ensure it remains open-source, community-driven, and impartial is crucial to so many infrastructure and operations teams around the globe.
• nabakin 3y ago
  We need to raise awareness about this fork so people know about, join in, and support the move. Share it with your friends and co-workers. Upvote or star everything you can. Let's push this forward people!
• bonetruck 3y ago
  From the Hashicorp post: "Vendors who provide competitive services built on our community products will no longer be able to incorporate future releases, bug fixes, or security patches contributed to our products." What vendors is the post referring to?
  • wmf 3y ago
    Nobody's entirely sure, which is a problem.
    • jen20 3y ago
      At minimum: - Spacelift - env0 - Digger Pulumi is not targeted, since the licenses of the providers are not changed.
      • SebastianStadil 3y ago
        - Scalr - Terramate - Terrateam
        • fishnchips 3y ago
          Also IBM [0], possibly AWS with Proton [1], GitLab [2], Harness [3], Gruntwork [4] and probably a dozen other smaller players. [0] https://www.ibm.com/cloud/schematics https://www.ibm.com/cloud/schematics [1] https://aws.amazon.com/about-aws/whats-new/2022/03/aws-proton-terraform-open-source/ https://aws.amazon.com/about-aws/whats-new/2022/03/aws-proto... [2] https://docs.gitlab.com/ee/user/infrastructure/iac/ https://docs.gitlab.com/ee/user/infrastructure/iac/ [3] https://medium.com/@steve.burton/harness-introduces-aws-cloudformation-and-hashicorp-terraform-support-6592203c50fc https://medium.com/@steve.burton/harness-introduces-aws-clou... [4] https://gruntwork.io/pipelines/ https://gruntwork.io/pipelines/
• h1fra 3y ago
  That's great news. I wonder what will happen to ongoing roadmap and all the bug/feature requests that were pending. I fear that sooner or later the APIs will become non-compatible so the only "good move" would be to jump to OpenTF as soon as possible to avoid complication. But for entreprise it will be a tough jump: updating all tooling, scripts, deployment flows, CI, compliance check, etc.
  • fishnchips 3y ago
    We have the tooling in place to ensure full equivalence of the most important parts, especially the statefile. We will also take great care to not introduce DSL changes that would make it hard to switch back and forth between OpenTF and the legacy Terraform. Looking at the codebase for the last week, and the list of PRs on the original repo ignored to oblivion I believe there's a lot of space for innovation that does not break the interop guarantee. [Marcin, co-founder of Spacelift, one of the members of the OpenTF initiative]
    • h1fra 3y ago
      That's very nice to hear, thanks! (even though I wish there was some breaking changes to be able to fix some of nasty bugs that have been there for years ahah)
    • freedomben 3y ago
      I think that's a good goal, but it seems pretty out of your hands. After your first addition to the language or state file (which by the sound of it is something you hope to do soon, and I applaud that), TF could immediately introduce something making compatibility impossible without you reverting and breaking the feature.
      • fishnchips 3y ago
        They could I guess, but with that they'd be abandoning support for all their previous versions, too. Plus it's software, there are a great many options here. I won't get into the nitty gritty not to spare everyone else the gruesome details but I'm not going to be losing sleep over this just now.
• thedougd 3y ago
  If the maintainers can keep a good throughout of pull request approvals, I think there’s a good likelihood that OpenTF could outpace Terraform in capability. Terraform, IMO, has benefitted significantly from having some very smart people at the helm. Most recently I’ve been impressed with the declarative mapping of imperative actions including import, state moves, and more. These things required very carefully coordination, especially in large active configurations, and are now quite simple and safe.
  • fishnchips 3y ago
    > very smart people at the helm Hear, hear. We would love to see them join forces with OpenTF.
  • kskkkkkkk 3y ago
    One has to wonder how much collaboration was prevented by having Hashicorp refuse to hear their users or accept PRs. At some point, opensource or not, people just stop bothering.
    • moondev 3y ago
      Was thinking the same. Would be great if they provided more "experimental" features with a flag or ENV. Then the default cli could be the "comparability mode". Cheers and good luck to the project!
    • znpy 3y ago
      People could have forked terraform before too. It’s being forked only now because there is big money at stake. I’m gonna wear my cynical hat and say: it never was about collaboration. Seriously: people are falling for the collaboration meme. Isn’t anybody wondering “why now?” Why not a year ago, why not a year in the future?
      • RealStickman_ 3y ago
        A year ago most people probably wouldn't have known or cared about a small new fork and I don't think it would have gotten the community support OpenTF has now.
• Pet_Ant 3y ago
  Not to be confused with related but different “OTF” which is the open source version of Terraform Enterprise: https://github.com/leg100/otf https://github.com/leg100/otf https://news.ycombinator.com/item?id=34536663 https://news.ycombinator.com/item?id=34536663
• bloopernova 3y ago
  Regarding the Language Server, terraform-ls: does anyone know if that will also be forked? Gah, this is frustrating! I am learning Python but TF and tf-ls are written in Go. I need to figure out how best to contribute.
  • fishnchips 3y ago
    If you can handle Python, you will have no issue with Go, which is overall a simpler language.
    • freedomben 3y ago
      I mostly agree, but subtle thing is that GP is "learning" Python. I don't think they know yet if they can handle it
      • bloopernova 3y ago
        That's very much it. At the risk of too much information I'm partially disabled, looking after my disabled wife, and working full time. I have a very limited "bucket" of stamina and strength that I can dedicate to anything else. On the weekend I try to get through a couple of Exercism items, and rest. I really wish I had 10x the energy to contribute to so many worthy open source projects :(
        • tetha 3y ago
          In my book, mirroring what a friend recently told me about instruments: Learn Python. Ignore everything else for 1-3 years. The main drawback is: You won't be able to write 10^3 - 10^5 events per second throughput services. That's where you need Go, (weird) Java and C++. But I don't think these are your current main problem. However, Python exposes you to a lot of very valuable concepts in the programming language space. If you know Python well, you easily know 80% of the language fundamentals of Java, 70% of Go or Ruby and like half of Haskell or C++. And the other half of those languages is mystical wonderous ponderous voodoo magic.
• Havoc 3y ago
  Seems like the inevitable conclusion. I reckon hashicorp overestimated how much of a moat they have.
  • freedomben 3y ago
    We're still in the first inning. A little too soon to declare victory IMHO. They're moat hasn't even been tested yet. Adoption is what actually matters. FTE commitments will disappear quickly if the project isn't able to get adoption. Also I know Hashicorp has a good moat (how good we don't know yet). Some very big companies pay Hashicorp and there's no way they're going to leave for opentf anytime soon. The support alone is plenty valuable enough to keep them there.
• RyJones 3y ago
  Welcome aboard to LF and thank you for making my life easier[0]! 0: https://github.com/hyperledger/toc/issues/151 https://github.com/hyperledger/toc/issues/151!
• pxc 3y ago
  > Community-driven - so that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit and changes are proposed through a public RFC process IMO if OpenTF wants to quickly pull ahead, they'd do well to quickly revive popular but neglected PRs from Terraform, inviting those authors to rebase on top of OpenTF and quickly getting them merged. The RFC process will slow them down here, at least for features, but presumably there are still old bug fixes that died on the vine, too.
  • fishnchips 3y ago
    Yup. This is very much what we intend to do.
    • pxc 3y ago
      Recently I (new to it myself) introduced Terraform on my team at work (my department historically mostly uses CloudFormation), and this whole license rug pull left me wondering if I'd made a mistake. But if OpenTF really flourishes, this could end up being better for us than if the license change had never happened. I wish you guys the best in making OpenTF a clear winner! The sooner that happens, the less of a shakeup this will be for the whole userbase and the more teams will stay invested and stick with terraform-the-technology (if not the trademark). I'm optimistic. :)
      • kskkkkkkk 3y ago
        Well, CloudFormation is as proprietary as it comes so I'd say you chose correctly with TF.
        • pxc 3y ago
          Technically we mostly use an open-source library for generating CloudFormation, but yeah it still ends up being a bit more deeply vendor-specific than TF.
          • 3y ago
• alexchantavy 3y ago
  > We completed all documents required for OpenTF to become part of the Linux Foundation with the end goal of having OpenTF as part of Cloud Native Computing Foundation. Anyone know why this was done in this order? Why not apply for CNCF right from the get-go?
  • dharmab 3y ago
    I'm guessing their application to the CNCF Sandbox is either planned or in review. It's only been 10 days, after all.
  • fishnchips 3y ago
    The CNCF process takes a bit longer and CNCF is part of the LF anyway. The project governance can benefit from being part of a reputable foundation as soon as practicable. (Marcin here, one of the OpenTF folks)
    • alexchantavy 3y ago
      Thanks, can you share more details? E.g. are there more reviews, more paperwork required, etc?
      • justincormack 3y ago
        Yes to reviews, no to more paperwork
• ahl 3y ago
  Some of the OpenTF team joined us on Oxide and Friends to talk about the project. It was a great conversation: https://oxide-and-friends.transistor.fm/episodes/fork-in-the-road-for-terraform https://oxide-and-friends.transistor.fm/episodes/fork-in-the...
  • Coryodaniel 3y ago
    Thanks for having us!
• mnw21cam 3y ago
  Linked page and the root page of the domain lack any explanation of what OpenTF and Terraform are. That should be right at the top of the page.
  • layer8 3y ago
    “Fork of Terraform” sounds like an item in a Mars settlers RPG. ;)
• pxc 3y ago
  When Oracle bought Sun, there were a number of open-source projects they started fencing off and developing in a less community-oriented way. Usually, I think they didn't even actually change the licenses. In every case I can remember, the community-centric forks outpaced or altogether outlived them. Hudson is dead. OpenOffice is basically irrelevant. Oracle ZFS sees little interest and is not what anyone thinks of when they hear 'ZFS'. But Jenkins, LibreOffice, and OpenZFS are all going strong many years later. This could end up being a really good thing for Terraform users, would-be contributors, and Terraform itself as a technology. I wonder if any Terraform maintainers from HashiCorp itself will jump ship to work on it full time as OpenTF. A similar phenomenon ended up being a decisive factor with the post-Oracle forks of Sun software IIRC.
  • davewritescode 3y ago
    Sun is a great example of a company that had excellent engineers but a terrible business model. Instead of fixing the business model, they tried to extract as much value out what they had and it ultimately lead to the death of the company. Terraform is the gateway to Hashicorp and it feels like they're going to lose it.
    • pxc 3y ago
      I was just a kid when Sun died, reading about all the drama of the buyout and the series of forks on Slashdot whenever I had already finished my work in my high school computer science class every morning. I didn't really know what or how to think about the mismanagement aspect of it, but I was already a F/OSS enthusiast by that time. I ran Linux at home and used free software everywhere I could. I even eschewed Times New Roman in favor of Linux Libertine (then the font of the W in the Wikipedia logo!) for my school essays because I didn't want to support the hegemony of a proprietary typeface. What I did understand about Sun was that they had been the caretakers (and sometimes creators) of some of the most important and beloved technology I'd ever used. I didn't know anything about Solaris, Hudson, ZFS or SPARC, but I knew Sun for VirtualBox, OpenOffice, the MySQL database system that seemed to be everywhere in the open-source world, and the Java programming language I was writing in for school. I remember a sense that something precious had died with that buyout, even though I didn't understand what led up to it. I worried a lot about OpenOffice, which I relied on and advocated to friends, and I practically cheered when I read about the formation of The Document Foundation and LibreOffice.
• koolba 3y ago
  Why oh why didn’t they add a dash to the GitHub org name? Is it too late to fix that or will be squinting at the repo owner for years to come? opentffoundation vs open-tf-foundation
  • fishnchips 3y ago
    This may change at some point.
    • koolba 3y ago
      Looks like "open-tf" is available as well. That'd be even better! As an added benefit, shorter names add a sense of legitimacy to new projects.
      • fishnchips 3y ago
        Thanks, snatched that one.
• jasonhansel 3y ago
  Here's hoping other HashiCorp products go the same way, creating an excellent new suite of truly OSS cloud tools. HashiCorp shot themselves in the foot, but they may have accidentally benefitted the FOSS community greatly.
  • lotyrin 3y ago
    Especially if the Vault fork implements things like replication.
    • mdaniel 3y ago
      Out of curiosity, what do you mean by this? cross-cluster? they already have HA: https://github.com/hashicorp/vault/blob/v1.14.1/website/content/docs/internals/high-availability.mdx https://github.com/hashicorp/vault/blob/v1.14.1/website/cont... while digging up that link, I also saw one named replication: https://github.com/hashicorp/vault/blob/v1.14.1/website/content/docs/configuration/replication.mdx https://github.com/hashicorp/vault/blob/v1.14.1/website/cont...
• b0dian 3y ago
  [dead]
• MaxwellKahn 3y ago
  I'm hopeful on this news. Terraform has become the standard in the industry, but incentives weren't quite aligned. My attempts to submit Pull Requests for much wanted features (fully working documentation with new integration tests all passing) often took months-a year to be accepted and merged. Hashicorp engineers were incentivized to work on features related to Hashicorp paid services, and Hashicorp competitors who would similarly benefit from a stronger Terraform codebase were disincentivized from potentially helping Hashicorp.
  • tpmx 3y ago
    Agreed. This will probably end up being a net positive for the Terraform 'concept' and its relatives like e.g. Pulumi.
  • jopsen 3y ago
    > My attempts to submit Pull Requests for much wanted features (fully working documentation with new integration tests all passing) often took months-a year to be accepted and merged. Isn't this always going to be the case? Honestly, are you signing up to maintain the feature long-term? Fix bugs? Update documentation? Review PRs with small changes to the feature? The cost of accepting a PR can be much higher than the cost of creating the PR. Even if you promise to maintain it! What if you don't? What recourse does the maintainers have? They can't just remove your feature, since customers started using it and you don't want to announce breaking changes and scare everybody. If you're building an open source product with lots of users, where compatibility is important. Then accepting a PR is a huge liability, you'll always want to be extremely conservative about it. A PR is not always a gift, regardless of innocent it looks.
• vmatsiiako 3y ago
  I think HashiCorp, as an infrastructure company, made a big mistake by choosing the BSL license (which was primarily designed for databases). Ultimately, this will destroy their community which in the long-term will also mean a lot of lost revenue... It is also very interesting to see how this will play out specifically for Vault vs Infisical. So far, Infisical has been growing incredibly, especially after the license switch.
  • IshKebab 3y ago
    Why is BSL primarily designed for databases? I thought it was just "GPL 4 years after release" sort of thing which seems pretty reasonable to me tbh.
    • vmatsiiako 3y ago
      It was invented by MariaDB and later adopted by CockroachDB, etc. It basically says "you can't compete with us" https://mariadb.com/bsl-faq-adopting/ https://mariadb.com/bsl-faq-adopting/
      • deleted 3y ago
        [deleted]
      • IshKebab 3y ago
        Right but there's nothing database specific in it is there?
• jamengual 3y ago
  OpenTF should poach apparentlymart from HC, that will drive a lot of adoption :)
• jakozaur 3y ago
  Time to do you part. Substitute Terraform with OpenTF (Terraform successor) everywhere. Oracle tried to constrain Hudson, but Jenkins won.
• kskkkkkkk 3y ago
  Waiting for Hashicorp's next move to introduce some proprietary incompatibility with Terraform Cloud API just so they can artificially damage OpenTF.
  • js4ever 3y ago
    Or just finishing to completely destroy their credibility? That would be the last nail in their coffin.
• yesmad1234 3y ago
  Does HashiCorp pose a patent threat to OpenTF? If Terraform implements a feature and OpenTF (cleanroom) copies it, could HashiCorp patent the feature to prevent OpenTF from using it?
  • bcantrill 3y ago
    No -- thanks to the MPLv2, which contains a patent grant.
    • deleted 3y ago
      [deleted]
• mdaniel 3y ago
  I don't see any mention of migrating the issues over, is that part of the plan? I also don't have a good grasp of what the situation is for the in-flight PRs for Hashicorp's repo: are those changes still MPL until they land in "main" and get BuSL-ed? IOW, is the PR author responsible for resubmitting or could any such patches be pulled in safely (err, DCO and CLA nonsense aside)?
  • voakbasda 3y ago
    I would suggest that PR authors should resubmit their work to OpenTF, closing the old PR. Even better would to leave a note rescinding permission for Hashicorp to include that work, though I'm not sure whether that is a viable strategy. At the very least, these steps will create more work for Hashicorp and send a clear signal that the community thinks that they have made a mistake.
    • phyzome 3y ago
      > Even better would to leave a note rescinding permission for Hashicorp to include that work, though I'm not sure whether that is a viable strategy. I don't see how that would work. If a valid offer has already been made under a license agreement, it's then entirely up to Hashicorp whether to merge it or not.
      • voakbasda 3y ago
        I would argue that the license change constitutes a material breach of whatever agreement existed previously, but IANAL so what do I know. Regardless, the legality of it does not matter. The already significant social consequence would be compounded if they chose to merge something that the contributor no longer wanted to see merged. It might be legal, but it treads even further into an ethical gray area.
        • phyzome 3y ago
          Their current CLA provides for a full copyright license grant: https://www.hashicorp.com/cla https://www.hashicorp.com/cla Assuming that's not new (and I have no reason to believe it is) then contributors were already signing away their right to be choosy in that regard; Hashicorp can already relicense any previous contribution, which is why this change is even possibly in the first place. I agree that it might cause some bad vibes, but it's no different for these in-flight PRs than it is for all of the historical ones that were already merged.
• jhoelzel 3y ago
  While i rally appreciate the effort and am astounded that they already have the pledge of 10 Full time engineers for 5 years I am left wondering 2 things: A) This could easily be a another reddit moment, where corps and actual bill payers will forget about it in two weeks since it simply -does not concern them-. The supporting list mostly consists of actual competitors. B) If they can manage all these resources, why can we just simply not do something new along the way? Terraform has its flaws and everyone that seriously had to worked with it can name many. For instance: Did you know that you cant easily shut down a server when deleting a terraform resource? At least not without hacks or workarounds? Its time for a "cloud-init native" solution to all these problems and while appreciating the effort i think this fork will actually hinder future development by having things remain the same. - Cluster Api all the way -
  • skywhopper 3y ago
    Not sure what you mean exactly about "shutting down a server when deleting a Terraform resource". But do you think that's something inherent to the design that OpenTF wouldn't be able to address? Personally I think Terraform hit on a really good pattern for IaC, and while there are lots of rough edges that could be polished, the overall approach is by far the best fit yet invented for the problem it's aiming to solve.
    • thayne 3y ago
      I'm not sure what they mean by that. But one case where terraform's model doesn't work very well, is updating a certificate on a load balancer (to be concrete, say an ACM certificate attached to an NLB in AWS) to a new cert and remove the old one. The proper way to do that, without service interruption is the following: 1. Create new certificate 2. Update the certificate attached to the load balancer 3. Delete old certificate But it isn't actually possible to do that in that order with terraform because of how dependencies work. By default what terraform will try to do is: 1. Delete old certificate. this will either fail, because the certificate is in use (as is the case in AWS) or destroy a resource that is still in use and cause the load balancer to enter a bad state 2. Create new certificate 3. Update the load balancer The only ways I have found to work around this is with targeted applies (which are discouraged), or splitting the change up into multiple code changes, with separate applies for each change.
• caniszczyk 3y ago
  Awesome to see how enthusiastic this community is! We at the LF are excited to work with the wider community to bring them under neutral governance like our many other foundations/projects. On the CNCF side, we welcome an application through the official processes when they are a bit further along with establishing their initial governance here: https://github.com/cncf/sandbox https://github.com/cncf/sandbox
• dhess 3y ago
  What’s the plan for dealing with the Terraform CDK?
  • bilalq 3y ago
    This is a big question for me. The CDK style form of authoring IaC is way better than config files in HCL/YML/JSON. It has some rough edges and I do wish it wasn't so gung-ho on the magical object-oriented constructor side-effects, but it's still a net improvement. CDKTF looks promising. How will OpenTF interplay with it?
    • fishnchips 3y ago
      I'm not into the CDK at all to be honest but isn't it a glorified preprocessor that generates the JSON representation of Terraform input, which is then processed as usual by your regular Terraform binary?
      • Coryodaniel 3y ago
        This is correct. TFCDK is also MPL (for now?). You will be able to generate tfjson w tfcdk and execute it with opentf
      • paulddraper 3y ago
        Yes. But a preprocessor that deserves the glory. Imagine writing in a real programming language, with real variables, loops, function calls, etc. And then imagine trying to use HCL instead.
        • fishnchips 3y ago
          To each his own I guess. I personally like the HTML-like mental model that HCL gives me. In a sense not being a programming language is to me a benefit. If anything, I'd love to see an equivalent of CSS to Terraform - an idea someone smarter than me was floating not so long ago. Decoupling structure from specifics - I can see a well thought-out implementation of this concept actually taking off. Re: programming languages... I love programming. Just not my infra.
• evantbyrne 3y ago
  It would be amazing if these efforts included fully documenting Terraform's Go interface and developing it into a first-class library. Being forced to interface with Terraform through HCL really holds it back.
  • fishnchips 3y ago
    That's literally one of my personal goals - to open up the libraries so that new and beautiful things can be built on top of it without having to reinvent the wheel. You will see it being part of the manifesto which says: _Layered and modular - with a programmer-friendly project structure to encourage building on top, enabling a new vibrant ecosystem of tools and integrations_
    • evantbyrne 3y ago
      Looking forward to seeing what you develop or even just expose with documentation! Terraform felt artificially constrained by the UI when I used it to MVP my CD platform. I suspect Hashicorp uses an undocumented Go interface internally for Terraform Cloud.
      • fishnchips 3y ago
        > I suspect Hashicorp uses an undocumented Go interface internally for Terraform Cloud. That API is public [0], though only a small subset of it is needed for the cloud backend. [0] https://developer.hashicorp.com/terraform/cloud-docs/api-docs https://developer.hashicorp.com/terraform/cloud-docs/api-doc...
        • evantbyrne 3y ago
          Sorry I should have been more clear, I meant the Go code that underlies the terminal UI. Maybe I'm totally off-base on my assumption, but my assumption is they aren't booting up individual terraform processes behind the scenes.
• thih9 3y ago
  In this case are there any benefits for Hashicorp to move Terraform to BSL? Especially considering: > Will I be able to use OpenTF as a drop-in replacement for legacy Terraform? > Yes > Will OpenTF be compatible with future Terraform releases? > OpenTF will be 100% interoperable with future Terraform releases until the community wishes otherwise.
  • rismoneyman 3y ago
    I don't think OpenTF interop with future TF is important. Particularly if OpenTF just moves at a faster pace, and gets way better in time. I would say leave TF in the dust and just start innovating.
• Daegalus 3y ago
  I would love to see a similar initiative with Vault and maybe Consul. Maybe call it OpenVLT and OpenCNSL. Then we can wrap it in a larger OpenHC or OpenMoto umbrella of projects. Especially with the integration points between Terraform, Vault, and Consul, those can be maintained better. Hell, I would do it myself, it I had the connections and time to do it. I might still try if no one else does. I would model it after OpenTF
  • mdaniel 3y ago
    > OpenMoto I dunno if you're trying to play on "hashimoto" but https://github.com/getmoto/moto#readme https://github.com/getmoto/moto#readme would be a prime name collision for any such "OpenMoto" name But yes, please, to adopting Vault. I don't have a horse in the race about Consul but my suspicion is such an effort would only be worthwhile if trying to adopt Nomad, too, which I gravely doubt
    • Coryodaniel 3y ago
      I am very curious about the future of Nomad. It definitely has its place for some orgs and was exciting to see an alternative to k8s gaining traction. I think this license change will hamper adoption and contribution when teams compare a foundation supported k8s vs a source available Nomad. I haven’t heard of anyone taking this on, but I’d love to keep my eyes on it if/when it happens. Disclaimer: early supporter of opentf, cofounder of massdriver
    • Daegalus 3y ago
      It was intentional, but I was not aware of that project. Consul is just a nice distributed KV store and Consul Templates integrate well with vault secrets. It can also be used as a storage engine for Vault of needed.
• swozey 3y ago
  Wow I had no idea so few people worked on TF. Where are the bulk of Hashicorp working? > So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository.
  • restlake 3y ago
    Well five is about the amount of sales people I remember joining an absolutely awful call with them a few years ago, so that’s my guess (edit: lol at getting downvoted for relaying an actual experience that happened. been using Vagrant since the original hobo logo circa 2012-2013 and have always been a HC fan, get off your high horse)
• throwawaaarrgh 3y ago
  can we finally fix all the annoying lack of features like auto import of existing resources? and providers that are just executables, so we don't need to write them with Go or according to an ABI? I'm sure lots of users have things they'd like to fix
  • mdaniel 3y ago
    Only time will tell, but my mental model is that this new stewardship will be a lot more open to community input than the Hashicorp "we're too busy, pound sand" model has been I dunno if "auto import" will ever be a thing, but I will be first in line to change its model to actually contact the provider during `plan`, which neither TF nor Pulumi do right now and it's a cause of endless wasted hours and borked deploys
• v3ss0n 3y ago
  someone needs to do something for nomad and rancher too, both of them are very powerful
  • mdaniel 3y ago
    Did something happen to the Apache 2 rancher? https://github.com/rancher/rancher/blob/v2.7.5/LICENSE https://github.com/rancher/rancher/blob/v2.7.5/LICENSE RKE2 is similarly Apache 2: https://github.com/rancher/rke2/blob/v1.26.7%2Brke2r1/LICENSE https://github.com/rancher/rke2/blob/v1.26.7%2Brke2r1/LICENS...
• AtNightWeCode 3y ago
  What is the problem with BSL? Is it that the code is still available but you have to run their binaries? Honest question.
• kidsil 3y ago
  It worked very well for LibreOffice. Best of luck!
• tamimio 3y ago
  So the business model for these companies goes like this: - New startup, cool idea, not much budget to hire engineers - Make it open source, piggy back on the free exposure that will get you, no marketing is needed because everyone loves open source! - Your project gets to have top tier programmers as maintainers, make all the nifty features, fix all bugs etc. for free or at minimum cost - Few months later, change license and/or close source it. - Rinse and repeat! Sometimes you get the community to fork it and maintain it by themselves, unfortunately, that’s not always the case.
  • louzell 3y ago
    I don't mind it. If a business is providing good software, and they have to make a license change to prevent someone from wholesale copying the work and selling it as a direct competitor, I'm for it! I'd rather have the sound business _in business_ and continuing to provide good software.
  • khuey 3y ago
    > Few months later, change license and/or close source it. Not to defend HashiCorp too much but in this case "a few months" was actually nine years.
  • Znafon 3y ago
    This is a very non-charitable read of the history here. Also, none of the companies that pledge FTE support to OpenTF are open-source.
  • shcheklein 3y ago
    > Your project gets to have top tier programmers as maintainers, make all the nifty features, fix all bugs etc. for free or at minimum cost In most case in these companies it's maintained and created at the expense of the company. I would expect that 90-99%% of the code, product development (talk to users, understand needs, etc), even devrel (marketing) (be on every conference to convince people to use it, that codification is good)- it's a lot of money, resources, and effort. > New startup, cool idea, not much budget to hire engineers In this case a few folks build it from the ground initially (most likely founders) I think. Please, let's not forget about this. The important thing here is to discuss why did they do this (I meant relicensing it). Most likely- trying t create a moat from a lot of other VC-funded companies that play in this space? Not sure. It would be great to know their exact concern.
• chrkl 3y ago
  Would love to see also a Vault fork
• Layvier 3y ago
  So I'm pretty new to Terraform, and in my team we were planning to set it up for our infrastructure next month. Does that change something for us? If it stays backward compatible I assume not much would have to be done for switching? I'd definitely prefer an open license.
  • Coryodaniel 3y ago
    We plan to maintain backward compatibility with the legacy version of terraform. You should be able to just start developing and swap the CLI. Depending on when you start, the first release mag already be out!
    • Layvier 3y ago
      oh ok great to know, thanks a lot! All the best with this project;)
• ladzoppelin 3y ago
  It seems like really hard work keeping up with AWS api changes, is that not going to be an issue?
  • fishnchips 3y ago
    This is handled by the providers, not by Terraform core, and these maintained fully or partially by cloud vendors. Terraform core is but a small part of a much larger ecosystem.
    • paulddraper 3y ago
      But the AWS provider is owned/maintained by Hashicorp, and I believe under the same license.
      • fishnchips 3y ago
        Provider ecosystem is still MPL-v2. A move to BSL here would be a way more bitter pill to swallow for the clouds.
        • paulddraper 3y ago
          ok
• js4ever 3y ago
  I hope this will be a warning for others tempted by relicensing to BUSL. This will probably kill all the community and maybe the company.
• swozey 3y ago
  I'm really curious what Hashicorp expected here. I supposed their next move is to control access to terraform cloud by versioning. But that'd chop off a big portion of their userbase. So maybe they grandfather old tfvers in and expect new to use 1.15 or 1.5 I forget.
  • pizzafeelsright 3y ago
    My guess is they went IPO. There was a massive cash infusion. Good. Eighteen months go by and people will be exiting. That means cash and talent leave. Now sales are tough. Pricing is terrible. We've been using their services for years while being offered enterprise services without much incentive. Why the license change? Lock out competitors or perhaps a charitable assumption, secure future service offerings without being exploited by cloud offerings that use their code while competing. The decision was a business decision. The amount they spend on sales to sell what I think is an amazing product, just over priced, is their doom. Why lock an enterprise into a three year contract tied to usage?
• deleted 3y ago
  [deleted]
• littlejo 3y ago
  Do you plan to crypt secrets on tfstate file? I think it could be a killer feature.
  • fishnchips 3y ago
    There was a long-standing PR with support for encrypting the entire statefile at rest. I personally find it worth revisiting.
• littlejo 3y ago
  You say you have 14 FTEs. But do you have at least one major developer who contributed to terraform. Could you give me the users list who will work on this project.
• fuddle 3y ago
  I'm really surprised the Hashicorp founders make no mention of the license change on their X (Twitter) accounts: https://twitter.com/mitchellh https://twitter.com/mitchellh & https://twitter.com/armon https://twitter.com/armon
  • voakbasda 3y ago
    When someone gets a well-deserved black eye, most folks would rather put on concealer makeup than be forced explain how they got their shiner. I doubt they want to draw attention to how badly they just pissed off the open source community.
  • donutshop 3y ago
    I thought Mitchell stepped down from an exec role a while ago.
  • tzcl 3y ago
    I doubt they were involved in the decision, https://twitter.com/mitchellh https://twitter.com/mitchellh posts a lot about stepping away from leadership to become an engineer again.
• sontek 3y ago
  I'm concerned that people who do not have a provable track record for contributing to terraform believe they can fork and be good stewards of the project. Looks like the top contributors to the foundation are: - https://www.scalr.com/ - https://github.com/Scalr - https://gruntwork.io/ - https://github.com/gruntwork-io - https://www.massdriver.cloud/ - https://github.com/massdriver-cloud - https://spacelift.io/ - https://github.com/spacelift-io - https://digger.dev/ - https://github.com/diggerhq Gruntwork and Digger do some decent opensource but the others haven't been great stewards of opensource. Looking at their githubs they don't seem to give much of anything back. So why should we trust them over hashicorp?
  • fishnchips 3y ago
    https://www.terratag.io/ https://www.terratag.io/ is by env0, one of the OpenTF sponsors. I also encourage you to take a look at the Sponsor badge on our (Spacelift's) profile. Whenever a possibility exists, we give back to the projects we use. We tried the same with Hashi, too. Re: trusting us over Hashi. DON'T. If there are any lessons learned from the great Hashi bait-and-switch trick it's that for-profit companies should not be trusted as the guardians of open source. Trust the foundation that takes over the project. Trust the cash we'll endow it with.
    • fishnchips 3y ago
      Also worth mentioning that we support our employees working on open source during their Friday projects where they're free to do anything to grow as engineers. Many choose to do open source and we don't require them to do it under our umbrella. In fact the guy from my team who is the acting TL of the OpenTF project is the creator and maintainer of https://github.com/cube2222/octosql https://github.com/cube2222/octosql
      • Znafon 3y ago
        So the software from your company is fully closed-source, isn't it? The employes can do open-source on Friday but no part of Spacelift is actually open-source?
• deknos 3y ago
  Well, do they also care about vault, vagrant and packer?
• Aeolun 3y ago
  I’m not sure how I feel about them saying they’re forking something, that it will be truly open source, and then saying they’ll publish the repo in 1-2 weeks. Why not now?
  • cube2222 3y ago
    Making sure there aren't any trademark infringements left, that we have some basic community process in place, etc. There's unfortunately a bunch of these things we have to do before we can publish. We created a public roadmap repo if you'd like to track the progress[0]. We're doing our best to make it public as soon as possible. [0]: https://github.com/opentffoundation/roadmap/milestones https://github.com/opentffoundation/roadmap/milestones Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
• voytec 3y ago
  Any open-source project being backed by VC is a red flag which should tell you to fork or back the fuck off asap. VC is cancer.
• serverlessmania 3y ago
  If AWS is the only cloud you're company using, do your self a favor and use cloudformation
• thedougd 3y ago
  Encryption of secrets stored in state and or support for a would be an excellent first fork feature to pull ahead. Maybe something that supports backends like AWS KMS (for encryption) or AWS Secret Manager (for storing/retrieving ) secrets. Stringing together resources to pull from a secrets manager and still having the secrets stored plainly in state is enormously frustrating. We aren’t all living in a nirvana of fast rotating out of band secrets.
  • cube2222 3y ago
    This is actually a feature I'd love OpenTF to have and am quite passionate about, personally. My plan is to submit it once we have the RFC process in place. Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
    • pxc 3y ago
      > > Maybe something that supports backends like AWS KMS (for encryption) or AWS Secret Manager (for storing/retrieving ) secrets. > This is actually a feature I'd love OpenTF to have and am quite passionate about, personally You're probably already aware, but SOPS¹ kinda fits the bill for integration here perfectly. It supports local secrets as well as encryption via keys stored with all the big cloud providers, and it's already battle-tested as it is used heavily at Mozilla (it comes from there). Additionally, like OpenTF, SOPS is maintained independently of any single corporation, written in Go, and distributed under the MPL-2.0 license. On its face, it seems like a match made in heaven. SOPS is a great tool and could be a pretty killer starting point for this stuff! -- 1: https://github.com/getsops/sops https://github.com/getsops/sops
      • fishnchips 3y ago
        Pure personal speculation here, even though I'm one of the OpenTF folks. If one wanted to make secret encryption ultimately flexible, it could become a type of extension like provider, which would work as a sidecar and simply encrypt and decrypt each secret thrown at it. It should be possible to wrap SOPS into one such plugin.
• user6723 3y ago
  What AWS decides to do will determine which way the wind blows on this ultimately.
• Proven 3y ago
  [dead]
• nsonha 3y ago
  cool name
• roschdal 3y ago
  Viagrunts is a fork of Vagrant: https://github.com/vaagrunt/viagrunts https://github.com/vaagrunt/viagrunts
• segevg 3y ago
  I don't think Hashi thought the community will react so fast.
• londons_explore 3y ago
  It seems to be a bad sign that the repo for this isn't even open yet... I understand that on day one the tests may not yet be green or some links in documents might not be updated, but I would feel a lot better if there was a public github repo that had a README.md with a big note at the top saying "Work is underway, don't use this yet". Without such a repo, it feels very much like opensourceness and community involvement is an afterthought.
  • cube2222 3y ago
    Tests are all green, actually! We believe we've even resurrected a large number of previously broken tests. Really, there's a few things, like getting rid of trademark infringement and setting up some basic community guardrails, that we need to finish prior to publishing. We're doing our best to get this out and public as soon as possible. You can take a look at the new public roadmap repo[0] to track progress towards milestones such as publishing the repo. [0]: https://github.com/opentffoundation/roadmap https://github.com/opentffoundation/roadmap Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
  • fishnchips 3y ago
    Under normal circumstances - yes. But the moment one creates an open fork of the repo, they get a trademark violation letter from Hashi's legal team. So in order to make the repo public, we need to be absolutely sure we're clean.
• lvncelot 3y ago
  > Who is maintaining OpenTF? Is there enough firepower behind the project? > So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository. That actually sounds promising.
  • rattray 3y ago
    Which four companies? This matters a lot; am I the only one skeptical about this move just being about cloud competitors trying to preserve margin?
• wg0 3y ago
  When you have 1000 employees and multiple investors, this was bound to happen. Wondering about nomad and it's future. It didn't have as much user base though and if only containers matter, nothing can beat the simplicity of docker swarm. No sure about Vault. I found it over engineered and complicated to graspe.
• olgeni 3y ago
  Why Terraform and not, say, Nomad? Just wondering :)
• fergie 3y ago
  Infrastructure state management is a massive opportunity, but I’m not sure that Terraform is the way forward (it should use an existing programming language, state should probably be in git, or even better it should be able to analyse state in real time, you should be able to spin up a local environment on your own computer). Managing a cloud deployment in 2023 feels a lot like managing a Sharepoint server in 2010. You really want it all to be scriptable, but the tooling isn’t quite there yet.
• wucaworld 3y ago
  Programming team of the future … 9 lawyers and 1 programmer. I think we are getting there.
• nuker 3y ago
  If in AWS, use Cloudformation. Your future colleagues will thank you. https://news.ycombinator.com/item?id=37218187 https://news.ycombinator.com/item?id=37218187
• deknos 3y ago
  so, will OpenTF also care about Vagrant and Packer? That would be nice.
• totallywrong 3y ago
  Terraform has got to be the only tool I've used a lot and still don't like one bit. The license change was the last push I needed to look seriously into Pulumi. What a wonderful tool in comparison, I'm not touching TF again if I can help it. I also got the feeling this fork will be better than the original eventually.
• peter_d_sherman 3y ago
  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...
• midoridensha 3y ago
  This is a terrible name for the project. "OpenTF"? Surely they can come up with something more imaginative. How about "Genesis" or "Reliant"?