[HN Gopher] The OpenTF Manifesto
___________________________________________________________________
The OpenTF Manifesto
Author : CathalMullan
Score : 449 points
Date : 2023-08-15 12:19 UTC (10 hours ago)
(HTM) web link (opentf.org)
(TXT) w3m dump (opentf.org)
| fuddle wrote:
| This reminds me of how the MapLibre project was created after
| Mapbox changed their license. https://wptavern.com/maplibre-
| launches-as-official-open-sour... https://maplibre.org/
| pjmlp wrote:
| [flagged]
| miah_ wrote:
| I think this is awesome. I highly doubt Hashicorp will do the
| right thing, so I look forward to the new OpenTF foundation and
| their fork of Terraform.
| SebastianStadil wrote:
| Thanks for your support!
|
| Please consider helping us by: - starring the Manifesto -
| spreading the word - pledging your organization if you can
| Halan wrote:
| Thanks Hashicorp for providing me with an excuse to convince my
| management to give Crossplane a try
| onedr0p wrote:
| There is zero chance of Hashicorp donating Terraform to an open
| source foundation. If there was they would have never even
| considered this change in license. Honestly it's not a bad thing,
| maybe the maintainers of the Terraform fork will actually listen
| to feedback from the community of people who use it instead of
| ignoring them.
| [deleted]
| fidotron wrote:
| The weaponisation of open source by the cloud vendors combined
| with devops culture encouraging only paying for operations and
| commoditising development is going to lead to constant pointless
| migrations of this kind (such as Docker/podman etc.)
|
| Devops people need to find a viable way to reward the developers
| of the tools they make a living from operating. Failing that they
| will wake up finding no one is willing to make them or that those
| that do have an ulterior motive.
| rank0 wrote:
| I actually love the weaponization of OSS. It eats away at the
| technical gap between proprietary systems and their FOSS
| equivalents. See elasticsearch + openAI (although open models
| are still quite far behind)
| [deleted]
| sberens wrote:
| I created a prediction market to estimate the success of this
| manifesto (along with other efforts):
| https://manifold.markets/SimonBerens/will-terraform-be-mpl-l...
| bloopernova wrote:
| 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.
| thdn wrote:
| Would you mind to share, those alternatives?
| johnbellone wrote:
| Just stop using their products. Stop giving them free
| advertisements. Stop integrating your software and services
| with them.
|
| It is harsh, but they're a public company now, not Mitchell.
| YetAnotherNick wrote:
| > Languages and frameworks must remain open or they will wither
| and die.
|
| Terraform is neither a language nor a framework, and I
| certainly don't think it will wither and die if they transition
| to BSL. Case in point, docker's revenue grew by 12x once they
| started taking control of their code and stopped caring about
| community. Same with postman or nginx or many other companies.
| mardifoufs wrote:
| What? Docker is still completely open source apart from the
| desktop GUI. The engine and (I'm pretty sure) all components
| are completely free and if anything, they have pushed for the
| standardization of the container runtime. Buildkit is free,
| compose is free, no feature is paywalled apart from Mirantis-
| centric stuff (not part of docker inc)
|
| You can absolutely bet that they would get dropped like a
| rock if they moved to changing the engine's license. Even the
| docker desktop code wasn't ever open to begin with anyways.
| scrum-treats wrote:
| Didn't Docker actually try it earlier this year, e.g.,
| https://blog.alexellis.io/docker-is-deleting-open-source-
| ima...?
| flanked-evergl wrote:
| Not sure what "it" refers to here, but what Docker did is
| in no way similar to what HashiCorp did.
| mardifoufs wrote:
| That's just hosting though iirc. Docker hub is very
| important, but it's not really part of Docker the
| software. As in, you could deploy your own container
| registry with 0 licensing issues. They just didn't want
| to pay the bandwidth costs anymore, though I think they
| walked back on that for open source images.
| coolspot wrote:
| Nginx is FreeBSD License, The Docker Engine is licensed under
| the Apache License 2.0
| AtNightWeCode wrote:
| The fantastic cost of running TF in the cloud is painful.
| Several years ago it was very clear that it would be difficult
| for HC to survive once they became a company registered at
| stock markets.
| jen20 wrote:
| > The fantastic cost of running TF in the cloud is painful.
|
| Citation needed. I don't think it costs very much at all.
| bayindirh wrote:
| 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 patches if Hashicorp decides
| to reject them (which is fine, too, this is how ecosystem
| works).
|
| But, HashiCorp says that, the thing we develop (i.e. Terraform)
| is used by others and generate revenue for them, this is great,
| but we can't generate enough revenue from it to keep the
| company afloat and continue providing TerraForm development,
| and sell it as a product at the same time.
|
| What should they do? I'd advocate AGPL, but xGPL licenses are
| avoided like a plague, because Free Software is not "closed
| forks" friendly, and companies hate to open everything like
| that.
|
| BSL is neither Free nor Open, which we all hate, but it allows
| HashiCorp to survive to a degree (this is not a fact, this is
| what HashiCorp is thinking).
|
| So, just because people adapted it, and HashiCorp cannot
| survive, should they say, we're closing shop, it's all MIT now,
| do whatever you want, bye!?
|
| Weak copyleft licenses are not designed for software that big.
| Or they assume that the developing party is untouchable. Strong
| copyleft solves this, but companies hate it because its
| unrelenting transparency.
|
| What should we do?
|
| P.S.: I neither endorse, nor support BSL, or HashiCorp's
| decision (or any company treads the same path).
|
| Edit: I mistyped MPL as permissive instead of weak-copyleft.
| Corrected, sorry.
| skywhopper wrote:
| HashiCorp has plenty of revenue and that revenue is growing
| fast. They are losing money, but that's to be expected during
| the high-growth phase of their lifecycle. If they are having
| trouble growing as fast as their investors want it to,
| changing their licensing is not the way to fix it. This
| change is unfortunate because it won't bring serious new
| revenue to the company but it is a major blow to the
| reputation they had built.
| jaggederest wrote:
| > But, HashiCorp says that, the thing we develop (i.e.
| Terraform) is used by others and generate revenue for them,
| this is great, but we can't generate enough revenue from it
| to keep the company afloat and continue providing TerraForm
| development, and sell it as a product at the same time.
|
| > What should they do?
|
| Suck it up, open source Terraform under a non profit
| foundation, find a new source of revenue. Or stop developing
| Terraform, cut expenditures, and move on with life.
|
| There's no universe where "bait and switch customers who
| wanted open source into paying us by switching licenses" is a
| viable option.
|
| > So, just because people adapted it, and HashiCorp cannot
| survive, should they say, we're closing shop, it's all MIT
| now, do whatever you want, bye!?
|
| Exactly, you know the answer, you just don't like the
| implications. People somehow think that a business which
| started an open source project "deserves" to profit from it.
| They do not. Open source is a great way to get people to know
| who you are and build things that are interoperable with your
| (proprietary, closed source) SaaS offerings. It is not in
| itself a revenue source.
|
| If the viability of your business is predicated on being the
| only one able to provide your project as a service and earn
| that service revenue gravy, _just leave it closed source and
| proprietary_. Sure, you won 't get adoption at anywhere near
| the rate, but that's the tradeoff you make.
| spencerflem wrote:
| How is them shutting down and them continuing under a
| closed source licence any different for you?
| bayindirh wrote:
| > Exactly, you know the answer,
|
| No. It was not a rhetorical device.
|
| > you just don't like the implications.
|
| I don't know which implications you're talking about, it
| was a question without prejudice or load.
|
| > People somehow think that a business which started an
| open source project "deserves" to profit from it.
|
| I do not agree. I don't hold a position stating that "TF
| should stay open, and companies should profit from it while
| giving it patches if you feel like it". I'm the opposite,
| and I find the approach to permissive licenses as "Ooo...
| Free tool to build a new product on and profit" as
| unethical to begin with. I put anything and everything I
| put out as A/GPLv3 or GFDL, because I produce that code for
| myself, on my free time, and I don't have a secret desire
| for it to be forked and closed down for internet cookie
| points.
|
| If you want to use my tool for any reason (which are not
| very sophisticated to begin with), comply with GPL, or roll
| your own. I. Don't. Care.
|
| I also pay for tons of things. Docker, cloud storage,
| programming fonts I use, anything I deem worth the money
| they're asking for.
|
| I also use Vagrant a lot, share my Vagrantfiles (again
| under GPLv3), and if they begin to charge like Docker, I'll
| pay for it, if I deem it's worth the money they ask for.
|
| However, at the end of the day, I'm a Free Software
| advocate. I use Free Software to the extent possible, and
| develop my software as Free Software. Not Open Source
| software under some permissive license to be grabbed and
| forked to death.
| stu2b50 wrote:
| > Or stop developing Terraform, cut expenditures, and move
| on with life.
|
| How would that be an improvement to anyone in any way? If
| you want, you can just pretend that Terraform is dead and
| Hashicorp will never push another commit for it. The people
| who can make the compromises BSL has can continue to use
| it.
|
| > If the viability of your business is predicated on being
| the only one able to provide your project as a service and
| earn that service revenue gravy, just leave it closed
| source and proprietary. Sure, you won't get adoption at
| anywhere near the rate, but that's the tradeoff you make.
|
| I don't understand why this is a binary. If the conditions
| of the BSL are unacceptable to YOU that's fine, just
| pretend it's closed source if you wish. For others, that
| the BSL isn't completely proprietary is useful for them -
| let it be useful. Your wishes need not dictate everyone
| else's.
| smarx007 wrote:
| MPL is a copyleft license, actually, just like EPL and EUPL.
| What it is not is a _viral_ copyleft license. Anyone making
| changes to TF code and productionizing it is expected to
| contribute back but only the direct changes to TF itself, not
| the extensions around it. That 's my reading of EPL/MPL/EUPL.
| Does that match your reading?
| bayindirh wrote:
| You're right. MPL is a weak-copyleft license. I mistyped
| it, I don't know why. Fixed my comment with a note, thanks.
|
| However, it still allows your code to be bundled inside a
| bigger work. The bigger work can be in any license (maybe
| not GPL, need to check), but MPL stays MPL. This doesn't
| prevent white-labeling the codebase, though.
|
| As far as I read the MPL, the contribution back part is not
| mandatory, but encouraged by not affecting the larger work.
| It keeps the MPL part open, but doesn't enforce a "send
| patches back" policy.
| smarx007 wrote:
| > As far as I read the MPL, the contribution back part is
| not mandatory
|
| That's not how I read it.
|
| > the contribution back part is not mandatory
|
| In that case weak copyleft would not be any different
| from MIT/BSD.
|
| First, assuming you are distributing only the larger
| work:
|
| "3.3. Distribution of a Larger Work
|
| You may create and distribute a Larger Work under terms
| of Your choice, provided that You also comply with the
| requirements of this License for the Covered Software.
| [...]"
|
| Assuming the covered (OSS) work is distributed as an
| executable:
|
| "3.2. Distribution of Executable Form
|
| If You distribute Covered Software in Executable Form
| then: (a) such Covered Software must also be made
| available in Source Code Form, as described in Section
| 3.1 [...]"
|
| Finally, 3.1:
|
| "3.1. Distribution of Source Form
|
| All distribution of Covered Software in Source Code Form,
| including any Modifications that You create or to which
| You contribute, must be under the terms of this License."
|
| The only wiggle room I see is not triggering the
| distribution clause by a SaaS-only offering. By the way,
| EUPL is a non-viral copyleft license that closes the SaaS
| loophole in MPL/EPL/LGPL.
| bayindirh wrote:
| By contributing back, I mean rolling up a patchset (or a
| tar of your source tree) and sending back to upstream.
|
| Otherwise, I think I clearly noted that the MPL part's
| source stays available whatever you do by saying "MPL
| part stays open".
|
| It's not the earliest hour here, so sorry if I can't
| articulate my thoughts clearly.
|
| You need to keep MPL part's source open and accessible,
| yet MPL doesn't prevent abuse like permissive licenses,
| much.
| smarx007 wrote:
| True, sending back to upstream is not required by the
| license. But even AGPL does not require this.
|
| Rolling up a tar of your source tree, however, will be
| required if you get a request from one of your customers
| by email. The difference from GPL is that you will only
| have to tarball a portion of the tree that was MPL-
| licensed. That tar must include your patches, as SS3.1
| requires.
|
| As I said before, many companies argue that using a
| private fork of an MPL/EPL/LGPL software in a SaaS does
| not trigger the distribution clause as customers never
| get a source or a binary of the program that runs in the
| cloud. EUPL closes that loophole.
|
| It's also possible that many companies violate
| EPL/MPL/LGPL terms (knowingly or unknowingly).
|
| One good example of non-viral copyleft working as
| intended is the Eclipse IDE. There are many closed-source
| tools that use Eclipse IDE under the hood (the part that
| Eclipse calls RCP), but there are no commercial forks of
| the IDE itself because any such company would have to
| open-source their changes to the fork.
| ecnahc515 wrote:
| 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.
| tootie wrote:
| 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.
| Matl wrote:
| > They built the most valuable devops tool of the last
| generation
|
| 'They' as in Docker Inc.? They made it accessible for the
| masses, which counts for a lot, but they built on a lot of
| pre-existing Linux kernel tech that other people who
| envisioned containers put in place before Docker came in and
| seized on the opportunity.
|
| > can barely muster a viable business.
|
| They perused what proved to be the wrong business model until
| 2019, nowdays they're more than 'barely' viable.
| reidrac wrote:
| It is all about the change. HashiCorp model _was_ open
| source, and now is not. Salesforce has never been open
| source.
|
| Would terraform have been as popular it if had never been
| open source? That we won't know, but we can guess.
| i_am_jl wrote:
| Why would Hashicorp give the slightest worry to losing
| thousands and thousands of non-paying customers?
|
| Because it goes hand in hand with losing hundreds of unpaid
| developers, testers, bug-reporters and evangelists.
| 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.
|
| Because the community contributed to the codebase. Salesforce
| was never open source, Terraform was and took community
| contributions, that's the reason we have different
| expectations. [Docker] can barely muster a
| viable business
|
| Docker split their development and enterprise offerings into
| two companies years ago and _both_ are making money.
| smarx007 wrote:
| I think that once you have more than X customers, you don't
| really need OSS testers and bug-reporters that much - your
| customers will be the first ones to file a ticket if
| anything is wrong. And as we saw with CentOS Stream, OSS
| users are not generally keen to be beta-testers.
|
| Ditto for earnings: once your company is publicly traded or
| at least lands in a Gartner report, you don't need
| evangelists that badly anymore.
|
| Free pull requests are always welcome, but I guess a
| calculation was made in this case.
| i_am_jl wrote:
| >I think that once you have more than X customers, you
| don't really need OSS testers and bug-reporters that much
| - your customers will be the first ones to file a ticket
| if anything is wrong. And as we saw with CentOS Stream,
| OSS users are not generally keen to be beta-testers.
|
| In this case the customers they're losing (as well as the
| devs, testers, reporters, etc) aren't end users but
| companies who have built software offerings on top of
| Terraform. That's the class of user principally impacted
| by the change to the license. OSS users aren't stoked
| about testing, but developers who build on top of
| Terraform in order to eat will submit bug reports and PRs
| all day.
| bcantrill wrote:
| We at Oxide were honored to be asked to add our name to OpenTF
| Manifesto. Our statement:
|
| _At Oxide, our vision has been that on-premises infrastructure
| is deserving of a system consisting of both hardware and
| software, at once integrated and open. Ensuring Terraform users
| can easily deploy to Oxide has been essential for realizing this
| vision: we want customers of an Oxide rack to be able to use the
| tools that they know and love! And while HashiCorp 's move to the
| BSL does not immediately affect Oxide (our Terraform provider is
| and remains MPLv2), we recognize that the ambiguity in both the
| license and HashCorp's language has created widespread concern
| that gives customers pause. We support the OpenTF efforts to
| assure an open source Terraform. It is our preference to see an
| MPLv2 Terraform as led by HashiCorp, and we join the call from
| the OpenTF signatories for HashiCorp to renew its social contract
| with the community by reverting the change of Terraform to the
| BSL. That said, we also agree with OpenTF's fallback position: a
| BSL-licensed Terraform is not in fact tenable; if Terraform must
| be forked into a foundation to assure its future, we will support
| these efforts. Open source comprises the foundation of the modern
| Internet, and is bigger than one company: it is the power of us
| all together to determine our fate. But we cannot take that
| foundation for granted -- and we must be willing to work to
| exercise that power to assure an open source future._
|
| Thank you to the consortium here that is coming together to guide
| Hashi to see the wisdom in an open source Terraform!
| diarrhea wrote:
| Just scrolled through your open job postings, and the Control
| Plane opening is jaw-droppingly interesting. Sounds like a
| marvelous mission you're on. I'm wishing you all the best and
| will make sure to check back in with Oxide's progress!
| sausagefeet wrote:
| As a huge Oxide fan, thank you for the support!
| lawnchair wrote:
| Thanks Bryan!
| hbogert wrote:
| I can rest easy now that my take on this aligns with Oxide's
| and I'm not being sarcastic. I've been following the podcast
| for 2 years now, and you guys are spot on with your stance on
| opening up and keeping things Open.
|
| It would be ironic though if Hubris ever gets relicensed
| yabones wrote:
| Turns out the proliferation of open source was never because of
| "collaboration" or "community", it was actually just a result of
| zero interest rates and "growth".
| yjftsjthsd-h wrote:
| That's a possibility, but a collection of companies trying to
| drive FOSS even after the original company stops is a great
| argument that it _is_ in fact a collaborative thing
| busterarm wrote:
| FOSS predates the zero-interest rate era by almost 20 years.
| lijok wrote:
| I love it. The list of "pledged companies" is literally just a
| list of all the offenders that Hashicorp are trying to shake off.
| PeterZaitsev wrote:
| This is reality of any successful Open Source ecosystem - folks
| who contribute the most (code, bug reports, marketing) in the
| project tend to be those who are making money on the project
| and these are the same folks who compete with you
|
| Coopetition is name of the game in Open Source and too bad
| increasing number of the companies want to focus on capturing
| all economic value from ecosystem they have created with help
| from so many others
| tedivm wrote:
| These people have seriously contributed back to the Terraform
| community. Terraform doesn't have a test suite- Grunt made
| Terratest, as well as many other tools. These people have
| seriously contributed back to the ecosystem, in many ways
| beyond what Hashicorp has done.
|
| Beyond that, I know some of these companies tried to be
| contributors to Terraform itself but were ghosted by Hashicorp.
|
| At the same time there's only a handful of regular contributors
| to Terraform[1]. It would not be hard for these companies to
| provide more resources to Terraform than Hashicorp is.
|
| https://github.com/hashicorp/terraform/pulse/monthly
| DrRobinson wrote:
| > Terraform doesn't have a test suite- Grunt made Terratest
|
| They have experimental support: https://developer.hashicorp.c
| om/terraform/language/modules/t...
| rjbwork wrote:
| Probably not difficult for these competitor organizations to
| fund an OpenTF team to hire some of these people away from
| HashiCorp and continue it on as FOSS either. I can't imagine
| Liam turning down .5M/year to do so.
| fishnchips wrote:
| Marcin here, co-founder at Spacelift. We are open to fund 5
| FTEs, feel free to reach out to us via the pledge page if
| you're interested in OpenTF becoming your full-time job.
| tedivm wrote:
| This is the first time I've been disappointed that I
| really like my current job, as that sounds like it would
| be pretty awesome.
| lijok wrote:
| Gruntwork is the only one of these companies that I genuinely
| cannot understand Hashicorp having any beef with.
| jen20 wrote:
| > Terraform doesn't have a test suite
|
| Patently false. Terraform has had an excellent test suite
| since 2014.
| tedivm wrote:
| Sorry, this may be a miscommunication. Terraform itself has
| a test suite, yeah, but it doesn't have a testing framework
| that users of the language can use to test their own code.
|
| To make a python metaphor, if cpython had a testing suite
| but pytest didn't exist then people wouldn't be able to
| test their own python code. That's kind of the situation
| with Terraform right now- you can't test your code using
| just the Terraform tools, you have to rely on Terratest
| which was written by Gruntwork. Hashicorp has spent years
| relying on the open source community to fill those gaps,
| which Gruntwork has done very nicely.
|
| Hashicorp even recommends Terratest for testing:
| https://www.hashicorp.com/blog/testing-hashicorp-terraform
| pseg134 wrote:
| It isn't a miscommunication, jen20 is astroturfing for
| hashicorp. Look at all of their recent posts.
| jen20 wrote:
| "Astroturfing"... lol OK. I don't think I've ever made it
| a secret that I worked for HashiCorp in the early days
| (leaving in 2017), and have been critical to the point of
| being banned by the CEO from speaking at HashiConf.
|
| Saying "Terraform doesn't have a test suite" is not
| miscommunication, it is misinformation, plain and simple
| - the same as most of the other things I have been
| correcting this week (not least from the same poster in
| this thread - someone who's clearly has an axe to grind).
| candiddevmike wrote:
| 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.
| jen20 wrote:
| 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.
| empressplay wrote:
| This is not testing?
|
| https://developer.hashicorp.com/terraform/cli/commands/pl
| an
| candiddevmike wrote:
| No, that's a rough guesstimate from Terrafrom on what
| actions it will be doing. Terratest allows you to write
| actual tests and mocks.
| cube2222 wrote:
| 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
| empressplay wrote:
| You guys effectively sell cloud-based TF instances though,
| don't you? Pretty sure that's a no-no...?
| cube2222 wrote:
| > 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.
| cyberax wrote:
| 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.
| rank0 wrote:
| Any reason why you don't like cloudFormation or the SDKs?
| verdverm wrote:
| The CUE community has some experiments, we were chatting about
| it recently, given the upheaval
|
| Imagine if that language covered more of the stack then just
| one tool too!
| diarrhea wrote:
| 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 wrong type to some variable
| I declared. This is type safety 101: variable declared `str`
| shouldn't accept `int`, ever. Yet `tf validate` was silent, so
| was all IDE-integrated tooling (whatever the VSCode TF
| extension does).
|
| Jumping to/from symbol definitions/usages was also flaky (but
| not entirely absent).
|
| Really disappointing! My excitement of diving into TF went
| poof. Maybe I'm overly sensitive, but I was so excited to
| escape YAML hell (Ansible).
|
| Now I'm _even_ firmer in the boat of just using a regular old
| language, like Pulumi with Python (with full typing).
|
| Did I do something wrong or can anyone confirm my findings?
| spion wrote:
| 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.
| jen20 wrote:
| Well, if that's something you _actually_ want, take a look at
| Pulumi, which does precisely what you ask.
| Sparkyte wrote:
| Not sure what sort of thought process went into Hashicorp
| thinking that going BSL was a good idea. I am exagerating but
| almost all of their code is community driven. So the biggest
| issue is that this will likely kill all of their profit.
|
| Perhaps if they went down the certification strategy it would've
| been a safer gamble. Certified Hashicorp Terraform Practioner.
| 650 a cert, probably would've saved their arse.
| kemitchell wrote:
| > When any company releases their tool as open source, the
| contract with the community is always the same...
|
| There is no contract. Try to enforce it. Even non-binding
| _expectations_ differ widely among projects.
|
| > We believe that HashiCorp should earn a return by leveraging
| its unique position in the Terraform ecosystem to build a better
| product, not by outright preventing others from competing in the
| first place.
|
| Nobody at Hashi cares how their competitors think they should
| make money. As for competition, Hashi just blew the whistle for
| an all-comers product pace-race against its formerly free-riding
| rivals. The old code remains MPLv2-licesed. That's the starting
| line. Their new BSL automatically releases new code under MPLv2
| four years after it's published. That's Hashi committing to a
| minimum pace. They clearly foresaw a fork.
|
| They are betting their maintenance commitment, expertise, new
| development pace, and existing book of business will make their
| new, less than four-year-old versions the versions users want,
| despite the license. Hashi's announcement and FAQs try to
| minimize perceived cost of the license change by emphasizing they
| intend no change for users, customers, and contributors, as
| distinct from product-service competitors. This new fork
| announcement tries to maximize uncertainty about the license and
| throw shade on future development prospects. It's all in the
| game.
|
| Customers can watch the runners run. Eat popcorn.
|
| I think it's highly unlikely Hashi's rivals will make enough
| marketing pain on this to force them to reverse the change. The
| database companies made far bigger moves, with more complexity
| and fewer marketing lessons learned. They held out. So the war's
| on the product dev and product marketing fronts.
|
| The real test will come in January, after Hashi says it will stop
| backporting fixes to the current MPL release. At that point, the
| rivals are under their own power only. Will any MPL-today-
| licensed fork be so competitive with Hashi's version at that
| point that customers bet on it over Hashi's long-term? It will
| have to bear its own development and maintenance costs for
| whatever differentiates it.
|
| I'm familiar with the products, but not an active user. My main
| question is whether there's substantial new development still to
| be done on the most popular projects, or whether it's really a
| maintenance war. I'd be looking for whether Hashi's new versions
| break compat, either tactically or as a consequence of new
| development.
| brikis98 wrote:
| Gruntwork here. You can find our statement here: The Future of
| Terraform must be open--our plan and pledge to keep Terraform
| open source. https://blog.gruntwork.io/the-future-of-terraform-
| must-be-op...
|
| If you want to help us keep Terraform open source, please show
| your support at https://opentf.org/!
| DrRobinson wrote:
| Great to see your commitment but I'm also curious why you,
| unlike some other companies, have chosen not to support with
| any full time employees? It seems your business is largely
| based on Terraform and saying pretty much "we'll contribute
| code" doesn't signal too much commitment.
|
| I realize my comment might sound like an accusation but that's
| not my intention, I want to hear your reasoning about it!
| Brian_K_White wrote:
| 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
| that caused the problem is the one who did some action.
|
| OpenTF did not (or is not prepareing to) fork this project,
| Hashicorp did.
|
| If it was me and I wasn't legally prevented by something actually
| binding in writing with signatures, I'd even keep using the
| original name and duke that out.
| dijit wrote:
| 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.
| PeterZaitsev wrote:
| Do not mix source code license with Trademark. Trademark use
| is focused by Trademark policy which is here for Hashicorp
| https://www.hashicorp.com/trademark-policy
| hadlock wrote:
| 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
| Fawlty wrote:
| afaik you can't use terraform in the name, it's trademarked by
| Hashicorp
| Brian_K_White wrote:
| That would be what I meant by legally prevented.
| flash0777 wrote:
| [dead]
| mousetree wrote:
| 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.
| mirzap wrote:
| It doesn't. And it will not make any difference. The same way
| as Sentry license, Elasticsearch, etc., doesn't have any
| difference for regular users. Those changes target cloud
| providers like Amazon, Google, etc.
| robbintt wrote:
| It will affect categories of business users (programmers) who
| currently embrace terraform: amazon, google, microsoft, oracle,
| alibaba cloud.
|
| Like it or not, cohorts of engineering organizations like the
| above (cloud providers) have a very outsized weight and already
| have contender products they can choose to vigorously fund
| tomorrow.
|
| From the article:
|
| The license does not allow you to use Terraform if you meet
| both of the following conditions: You are building a product
| that is competitive with HashiCorp. You embed or host Terraform
| in your product.
|
| My $0.02: the management of hashicorp is following a stupid
| trend and should have thought about their customers more.
|
| It will come out to what lawyers think, I guess. Lawyers
| usually say no to things with poorly established precedent.
| cbo100 wrote:
| > have contender products they can choose to vigorously fund
| tomorrow.
|
| Then why didn't they "choose" to fund hashicorp yesterday and
| avoid this?
|
| As usual in OSS-goes-private events these all just sound like
| "keep building our critical infrastructure tool for free or
| we will go elsewhere".
|
| What is hashicorp or any other company in their position to
| do?
|
| This is not sustainable.
| i_am_jl wrote:
| > As usual in OSS-goes-private events these all just sound
| like "keep building our critical infrastructure tool for
| free or we will go elsewhere".
|
| If Terraform was 100% developed by HashiCorp employees that
| would be fair description. It's more like "We're the only
| company allowed to make money off of the codebase you
| contributed to."
|
| > What is hashicorp or any other company in their position
| to do?
|
| I'd suggest paying developers to write proprietary code.
| That way they could just sell a product they fully own
| instead of having to pull this bullshit re-licensing of an
| open source codebase.
| vrosas wrote:
| IANAL but it doesn't seem like much, unless you're planning on
| building a terraform-as-a-service company to compete directly
| with hashicorp. Honestly I'm not surprised given hashicorp's
| enterprise offering are basically just... hosting the .tfstate
| file for you? I still can't figure out what their upsell is.
| pknomad wrote:
| Hosting the statefile in a secure way, state-locking,
| injecting the secrets so you're not keeping the secrets
| locally or in env var, and pre-built integration with other
| Hashicorp suite.
|
| I see the use case for it if you don't want to use a 3rd
| party or open source tool (Atlantis) but the pricing seems
| prohibitive.
| yonixwm wrote:
| I think you will be affected by the bigger picture. Mongo did
| this move also but there they were mostly in control before and
| after. Here there is a huge community of plugins. If before AWS
| shared a provider without hesitating, now they will ask
| themselves why contribute to a closed and possibly competitor
| garden.
| hnav wrote:
| this is similar to other opencore debacles, Hashicorp wants you
| to use their managed Terraform rather than someone else's
| integration. This means that if you choose TF today for you
| managing your IaC you'll potentially be locked into using Hashi
| products down the road. The community is all but guaranteed to
| fork TF which means that over time the two forks will diverge
| and you'll have a bad time when trying to read docs, debug,
| contribute fixes.
| dmattia wrote:
| 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 open source tools that don't directly compete
| with Hashicorp that are in a bit of a gray area, but I've seen
| Atlantis, Pulumi, OTF, and other tools all claim that this does
| not affect them. I would presume this could also apply to
| things like Terratest, Terragrunt, etc. but I don't know. I am
| not a lawyer.
|
| And if none of these company/product names are familiar to you,
| then you shouldn't have any noticeable difference :)
| cube2222 wrote:
| > 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...
| dmattia wrote:
| Oh neat, thanks for sharing this! I had read
| https://spacelift.io/blog/hashicorps-license-change last
| week, but hadn't seen this blog yet.
|
| Best of luck with Spacelift :)
| cube2222 wrote:
| Thanks, very appreciated!
| lacker wrote:
| As a regular end-user, the main difference in the licenses is
| that it forks the ecosystem. If the fork goes ahead, and you
| were using some HashiCorp products and some software that is
| moving to OpenTF, eventually you won't be able to use that
| combination of tools any more. So you will have to pick what
| license you are going with, even if you don't care about the
| license directly.
| pknomad wrote:
| Not much, right now.
|
| Long term? Possibly less adoption (teams may elect to go with
| Pulumi or some other alternatives), less 3rd party tooling
| available (what if Hashicorp decides your tool is their
| competitor?), etc.
|
| It seems very similar to the spat that community had with Red
| Hat with how 3rd party captures too much value from their own
| internal offering and leadership responds by changing the
| license model and makes things less open-source-y. Perhaps this
| will become the new normal for OSS/former OSS? IDK.
| rst wrote:
| It depends on what you're using it for, and whether it competes
| with anything Hashicorp does -- or might do in the future. If
| you can guarantee that's "none", you're in the clear. But as
| the man said, prediction is hard, especially about the future.
| igorzij wrote:
| Digger here
|
| Our statement: https://medium.com/@DiggerHQ/diggers-statement-on-
| the-hashic...
| ddon wrote:
| Impossible to read, behind a paywall... why people post stuff
| to Medium is a big mystery to me :)
|
| Here is how your post looks like: https://postimg.cc/Pvwdw8D3
| mdaniel wrote:
| Let me introduce you to my go-to for that bullshit:
| https://scribe.rip/@DiggerHQ/diggers-statement-on-the-
| hashic...
|
| courtesy of: https://news.ycombinator.com/item?id=28838053
| oars wrote:
| Thanks for sharing Scribe which can help me read Medium
| articles with an alternative front end that bypasses the
| paywall.
| aftbit wrote:
| >Imagine if the creators of Linux [] suddenly switched to a non-
| open-source license that only permitted non-competitive usage.
|
| Linux cannot even successfully switch from GPL2 to GPL3 because
| of the sheer number of contributors and the fact that not all of
| them have transferred their copyright ownership to any given
| organization. This patchwork of different copyright owners has
| historically been seen as a potential weakness for Linux, but it
| seems like perhaps license inflexibility is a strength for open
| source.
| MrStonedOne wrote:
| [dead]
| cies wrote:
| I thought Linus and other believed GPLv2 was fine and the
| improvements of GPLv3 did not outweigh the potential problems
| introduced by it. It never came to a point where all authors
| were asked to agree, or sign away their ownership.
| kmeisthax wrote:
| Torvalds considered the anti-TiVo clause to be changing the
| deal and he didn't want to do that, and there's no way in
| GPLv3 to opt-out of the clause[0].
|
| This is less "locking down devices is a human right" and more
| him being angry that the FSF was trying to butt into his
| project's affairs. He's also similarly angry about
| "GNU/Linux" as it sounds an awful lot like Stallman just
| demanding everyone stick "GNU" onto the name of Linus's
| kernel project.
|
| Anyway all of this is going to seem really quaint in 2027
| when Broadcom gets sued under DMCA 1201 by a rogue kernel
| contributor for evading the Linux linker's license checks[1]
| and they have to hurriedly rewrite them out of the kernel and
| relicense anyway.
|
| [0] Granting a blanket exception doesn't work because others
| can just remove the exception. "No further restrictions" is
| an ironclad law of copyleft.
|
| [1] The Linux kernel checks the declared license of loaded
| modules and refuses to link non-GPL-compatible code against
| any kernel symbol not marked as a user-space equivalent. The
| reason why this works this way is because Linux ships under
| GPLv2 plus an exception that says user-space APIs don't trip
| copyleft, so you can legally load code built to those APIs
| into the kernel, but anything else might violate GPL.
|
| Since this is enforcing an interpretation of the GPL, this is
| a DMCA 1201 technical protection measure. You absolutely
| could make a DMCA 1201 anticircumvention claim in court
| against a proprietary driver developer that tried to evade
| the checks. Though Linus usually just bans their modules in
| the next kernel revision since he's mainly worried about
| keeping proprietary modules from generating spurious bug
| reports in Linux. But the lawsuit is still possible, since
| they're on GPLv2. If they had relicensed to GPLv3, this
| wouldn't be an issue.
| rwmj wrote:
| We changed the license[1] of a project which had 10
| contributors, and we got every single one of them to do an
| Acked-by (by email) which took some weeks. That was on the
| advice of our lawyers. Can't imagine the impossible hassle of
| doing the same for something like Linux.
|
| [1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea
| 775...
| maccard wrote:
| Can't speak for Linux, but got a few projects I've
| contributed to I've had to sign a CLA which negates that
| problem (but causes the one in this thread)
| justincormack wrote:
| It has been done for some fairly large projects, eg openssl
| managed to swith to Apache for 3.0. It is a lot of work.
| nabakin wrote:
| Yes, I believe I saw a video of Linus stating exactly this
| aftbit wrote:
| My understanding was that some people in the community
| believed that GPLv3 was better, and one of Linus's criticisms
| was that it was essentially impossible to switch even if it
| were better. I also believe Linus was opposed to the switch,
| which would make it unlikely anyway, but even if he had
| approved, I still think it would be practically impossible.
| sausagefeet wrote:
| We, Terrateam, do not believe we violate the new license but we
| support Terraform being open due to how important it is to the
| ecosystem. Unlike Vault or Waypoint, Terraform is closer to a
| language compiler like Go or Java and benefits from a robust
| community that can build on top of a stable ecosystem. As such,
| we have announced our support of the OpenTF Manifest[0]
|
| [0] https://terrateam.io/blog/opentf-pledge
| theowawayhs wrote:
| Once a prolific commentator, Mitchell Hashimoto has gone quiet
| here for over 50 days now.
|
| His GitHub activity seem to indicate he is now focused on the Zig
| programming language.
| tedivm wrote:
| He doesn't work at Hashicorp anymore, and even quit the board.
| Since the company is public he could have just completely
| cashed out at this point (and I wouldn't blame him for it).
| throwaway1101z wrote:
| Only Hashicorp employees are allowed to comment here? How
| about the person that actually built it? Maybe he has
| interesting things to say. Also, he's been silent on HN as a
| whole, not just Hashicorp-related threads.
|
| Maybe he signed a gag order and cashed out. We may never
| know.
| ms4720 wrote:
| I think the problem is that if hashicorp thinks you are a
| competitor you and your clients now have legal/operational
| issues. Ie you are now a competitor because we are releasing a
| product just like yours, here is a letter from a lawyer telling
| you to stop using terraform.
| brikis98 wrote:
| > if hashicorp thinks you are a competitor
|
| This is precisely the problem with the new BSL license. Whether
| your usage of Terraform complies with the license isn't
| determined by the legal terms, but instead is entirely at the
| whim of HashiCorp. And they can change their mind at any time.
| It makes it impossible to build anything on top of Terraform.
|
| I talk about that more here: https://blog.gruntwork.io/the-
| future-of-terraform-must-be-op...
| unethical_ban wrote:
| I worked at a financial institution that heavily utilized
| terraform. Their business is banking and they do not offer
| automation, orchestration or IaC as a service. They're fine.
|
| This seems to affect only those places that attempt to build
| a business off terraform.
|
| I am not saying those businesses can't be mad at the rug
| getting pulled out from under them, but it's important to be
| accurate that this doesn't affect end users of TF directly.
| ig1 wrote:
| Is the financial institution made up of separate legal
| entities which bill each other for services, and does one
| of those entities provide tech infra for the other legal
| entities?
| unethical_ban wrote:
| Good point, but no. Also I think they pay Hashicorp for
| support.
| ig1 wrote:
| The messiness of the real-world unfortunately doesn't
| play well with ambiguity in licences :)
|
| It'll be a headache for every large company which now has
| to send the licence to their legal teams who have to ask
| these kind of questions (another interesting one is "can
| contractors touch our terraform setup?") - in fairness to
| Hashicorp they've tried to address some of these issues
| in their FAQ, but the FAQ isn't legally binding so legal
| teams have to go on what's actually written in the
| licence.
| cstejerean wrote:
| This covers really well why I think the BSL license is a non-
| starter for things like TF. I get trying to prevent AWS from
| competing with you using your own open source code, but it
| creates this ambiguity where it's not clear whether lots of
| uses are or are not competing with HashiCorp.
|
| > For example, if you're an independent software vendor (ISV)
| or managed service provider (MSP) in the DevOps space, and
| you use Terraform with your customers (but not necessarily
| Terraform Cloud/Enterprise), are you a competitor? If your
| company creates a CI / CD product, is that competitive with
| Terraform Cloud or Waypoint? If your CI / CD product natively
| supports running Terraform as part of your CI / CD builds, is
| that embedding or hosting? If you built a wrapper for
| Terraform, is that a competitor? Is it embedding only if you
| include the source code or does using the Terraform CLI count
| as embedding? What if the CLI is installed by the customer?
| Is it hosting if the customer runs your product on their own
| servers?
|
| The answer is at the whim of HashiCorp and subject to change
| at any point in the future. Even ignoring the attempt to
| dilute the meaning of "open source", the practical
| implications of the BSL license are more than enough reason
| to coalesce around a truly open source fork IMO.
| stavrus wrote:
| 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.
| PeterZaitsev wrote:
| One thing I particularly hate about license change is lack of
| notice - If you operate in good faith you probably would want to
| give time to community to make arrangement, whenever it is
| negotiating agreement with you or looking for alternatives. Lack
| of notice this means everyone who embedded Terraform put their
| customers at risk immediately as in case any discovered CVEs they
| will not be able to ship security fixes to their customers.
| cube2222 wrote:
| Their FAQ states they'll backport security fixes under the old
| license until the end of 2023.
|
| Disclaimer: Work at Spacelift
| PeterZaitsev wrote:
| Ah, this is great when. MongoDB did not do it in their switch
| to SSPL
| punnerud wrote:
| Isn't all agreements to limit competition illegal in EU/Europe?
| Even collaboration between competitors agains a 3. part is
| illegal.
|
| The rest of the agreement is still valid, just the completion
| part is nullified
| fishnchips wrote:
| Spacelift co-founder here. Not going to comment on the legal
| aspect, but I'm actually curious when it did become acceptable
| in polite society to say that "we just want to kill the
| competition".
| PeterZaitsev wrote:
| Interesting to see Twitter (X) poll was right on this one
| https://twitter.com/PeterZaitsev/status/1691173820122443776
| jupp0r wrote:
| iojs comes to mind. This is the beauty of open source in action.
|
| Long living forks and fragmentation sucks, but now HashiCorp has
| to react to this and provide compelling benefits if they don't
| want to loose the whole project alltogether.
| Coryodaniel wrote:
| Massdriver was designed to be infrastructure-as-code agnostic
| from day 1.
|
| Our goal has been to help companies get great operations,
| compliance, and security posture from day one.
|
| While Massdriver is not a competitor to HashiCorp, the license
| language is extremely vague and leaves any infrastructure company
| running containers for their customers wondering if HashiCorp
| will consider them a competitor tomorrow.
|
| We are proud to be providing development and community support
| for this initiative.
|
| Read our statement here:
| https://blog.massdriver.cloud/posts/2023-08-14-opentf-commit...
| bastardoperator wrote:
| Ask Roblox employees how they feel about Hashicorp products.
| Terraform is probably the most solid product they have seconded
| by vault, but after hearing the consul and nomad horror stories,
| I don't think I could take their products seriously ever, not
| when kubernetes is setting right there.
| CaptArmchair wrote:
| Well, here's the link to the post-mortem of said "horror" story
| on the Roblox blog:
|
| https://blog.roblox.com/2022/01/roblox-return-to-service-10-...
|
| TL;DR The outage was caused by (a) they enabled a new streaming
| feature in Consul under unusualy high read-and-write load, (b)
| the load conditions triggered a pathological issue in the
| third-party BoltDB system upon which Consul relies and (c) all
| of that was exacerbated by having one consul cluster supporting
| multiple workloads.
|
| I'd use quotes to catalog this as a "horror" story, because
| this was clearly a very specific issue triggered by a specific
| and complex set of circumstances.
|
| The blogpost also mentions that Roblox worked closely with
| Hashicorp engineers to mitigate the issue, and work towards
| structural solutions; the post also affirms their choice to
| manage their infra themselves rather then moving into a public
| cloud solution.
|
| Sure, Kubernetes covers loads of territory. But there
| definitely are niches where products like Consul & Nomad do add
| value.
| vilkkala wrote:
| Could you elaborate on these horror stories?
| throwaway2023rb wrote:
| Hashicorp enterprise support is rock solid for Nomad, Consul,
| Vault. If there is a P0 problem, they will root cause, and
| usually have a fix identified in < 48 hours. All three of those
| products are taken very seriously - running 10,000+ servers in
| a single cluster.
| busterarm wrote:
| > not when kubernetes is setting right there.
|
| Enjoy spending the rest of your life trying to get etcd to
| cooperate. If you think operating Kubernetes at scale is a
| cakewalk, you don't have the scale problems you think you do.
|
| I'll take consul over etcd ten million times out of ten.
| pcthrowaway wrote:
| Realistically you're either deploying consul on top of 1-N
| kubernetes clusters, or Nomad.
|
| If deploying on kubernetes, you now have all the problems
| that come with kubernetes, plus additional problems of trying
| to get consul working.
|
| I spent a week just trying to stand up a federated multi-
| datacenter deployment of consul on EKS before my company
| decided it was too much hassle
| busterarm wrote:
| the OP was suggesting that it's just obvious to use
| Kubernetes instead of Nomad.
|
| I was saying that anyone who operates large scale
| Kubernetes knows that you will forever be dealing with
| tuning etcd and fighting to keep etcd alive. It's an
| underpinning service of Kubernetes.
|
| Roblox's outage was related to the intricacies of running
| consul and mistakes that they made.
|
| The point I was making was that I would rather, at this
| scale of operation, be running Nomad and optionally Consul
| and optionally dealing with the intricacies of Consul than
| running Kubernetes and being _forced_ to deal with what a
| miserable pain in the ass etcd is.
|
| I was saying that running Kubernetes is _not_ the obvious
| choice -- at least once you're at 10^5+ systems.
| pcthrowaway wrote:
| I was interested in Nomad in the past, but Kubernetes is
| open source, so it has that going for it
| bastardoperator wrote:
| Until you have 3 days of downtime and end up on a special
| build of consul that nobody else has while nearly
| decimating your companies stock price, reputation, and
| employee morale, the alternatives start looking better.
| The point I'm making is that it doesn't handle their
| scale today and that projects with larger communities,
| support, and usage exist today. No one said k8s was a
| silver bullet, it's just an alternative to an already
| failing infrastructure.
| busterarm wrote:
| If you truly read and understood the Roblox post-mortem
| you would understand that the problems that they had with
| Consul were partly and unintentionally self-inflicted and
| partly due to BoltDB. The "special build" was just early
| access to Hashi's already-ongoing work to replace boltdb
| with bbolt, which has long-since shipped.
|
| The hyperbole applied to the description of the harm done
| to Roblox here I'm just going to ignore. Roblox is still
| popular. The company still has the reputation of a rock-
| solid engineering department. Roblox's stock isn't doing
| much differently than the rest of technology companies on
| the market and the "damage" you mention is vastly
| overstated anyway. In fact, Roblox's stock literally had
| a huge rally after and PEAKED within two weeks after the
| outage.
| ragona wrote:
| The CDK and Pulumi teams must be truly delighted by this move.
| jen20 wrote:
| How exactly do the companies involved plan to fund a fork? It
| would require at minimum 3-4 full time engineers, and no one is
| going to do that work for free.
|
| It's also telling that this manifesto blithely suggests TF could
| become Apache 2, which is wholly untrue.
| yjftsjthsd-h wrote:
| > It's also telling that this manifesto blithely suggests TF
| could become Apache 2, which is wholly untrue.
|
| Why is it untrue? If Hashicorp has the ability to relicense to
| BSL, what would prevent them relicensing to anything else?
| igorzij wrote:
| An earlier version of the manifesto contained pledged resources
| from each company (you can still find it in commit history). It
| totalled to ~10 full-time engineers just from founding orgs. It
| was removed to simplify adding their entries for new pledgees
| myroon5 wrote:
| Omitting commitment details may simplify pledges, but it also
| makes pledges almost meaningless. I'd take pledges much more
| seriously if they still had details
| sausagefeet wrote:
| I am a co-founder of Terrateam and we have made a pledge
| for OpenTF. I understand where you are coming from, but
| right now it is difficult to know what exactly to pledge as
| we want a dialogue with HashiCorp on what they need as
| well, if they want to donate to a foundation.
| brikis98 wrote:
| We just moved to a table format for pledges and brought
| back the commitments so you can see them:
| https://opentf.org/
| jen20 wrote:
| Do the founding orgs have public disclosure of their
| finances? It seems the vast majority of them are VC backed
| companies that probably don't even have two years worth of
| runway, let alone be in a position to meaningfully commit to
| funding engineers for five years.
| marcinzm wrote:
| As I see it Hashicorp has failed to create a viable business
| model in an environment where there isn't unlimited perpetual VC
| money. Now they're at the stage of giving up and simply trying to
| shake down those who have managed to make better business models.
|
| It's usually not a good idea to be near a company flailing like
| this since who knows what their next rent seeking approach will
| be. A company with nothing to lose is a dangerous partner to
| have.
| tedivm wrote:
| The worst part is they did create a viable business model. They
| were profitable when they had their IPO. They then pretended
| that the IPO was just another Series X investment, blew all the
| money, and went negative on their cashflow.
|
| Hashicorps problem isn't that their business model doesn't
| work, it's that they are really bad at their jobs. They ignore
| customer feedback, laid off support people, and then jacked
| their prices up. It's a self inflicted wound, and instead of
| trying to fix it they just keep making it worse.
| marcinzm wrote:
| Definitely, the fact they're rent seeking against similar
| small companies clearly shows that. Sad that rather than
| looking inward to improve themselves they've decided to just
| attack others.
| jen20 wrote:
| Have you actually read the financial statements? None of what
| you just wrote is remotely true.
| paulgb wrote:
| I looked it up and you're right, but it's also striking to
| me how much they spend on sales and marketing: almost 75%
| of their gross revenue in 2023!
| [deleted]
| fishpen0 wrote:
| I've worked for three companies now that went to hashicorp to
| buy TFE and left with a quote equal to a quarter or more of
| revenue and the sales rep acting like they are the second
| coming and obviously we are stupid for not thinking they
| bring that much value to our org. No org invests 1/4 of their
| revenue on a single tool. So we used atlantis or spacelift or
| hand rolled GHA scripts and saved a fortune.
|
| We are trying to pay them and they are being so unreasonable
| with pricing that we can't give them our money
| johnbellone wrote:
| It's been that way for years with them. It'll be
| interesting to see if they go the road if a private equity
| buyout, or they're acquired by a technology company for the
| copyright/trademark.
| dbingham wrote:
| 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 community governed non-profit
| foundations can do that.
|
| Private corporations will put the bottom line first _every single
| time_. And in the case of investor funded enterprises, the bottom
| line is never ending exponential growth or bust.
| PeterZaitsev wrote:
| I totally agree. I do not think pleading with Hashicorp to
| reconsider will result in changing back the license
|
| Doing the Fork and showing it IS sustainable and has broad
| community support can encourage Hashicorp to make concessions.
|
| After taking this unilateral hostile step I do not think
| Hashicorp deserves the community trust and what industry needs
| is "Foundation Governed" Terraform like solution, whatever name
| this solution will have.
|
| You can see example in Confluenct which builds proprietary
| solutions around Kafka, where Kafka itself is Apache project.
| brikis98 wrote:
| The truth is that a fork hurts everyone.
|
| Imagine a future CTO trying to pick the IaC tools for their
| company. They see Terraform as an option, but then learn there
| are multiple forks, licensing questions, and a big battle
| happening in the community. What do they do? They are now way
| more likely to pick a different tool that is genuinely open
| source. The same is true of every dev considering where to
| build their career, every hobbyist, every open source
| enthusiast, every vendor, etc. In the end, no matter which fork
| wins, everyone will be worse off: the community will be smaller
| and more splintered.
|
| So we opted to ask HashiCorp do the right thing first. If they
| choose to do the right thing, we can avoid a fork, and avoid
| splintering the community. We still think that's the best
| option. But if that doesn't work, then a foundation + fork it
| is.
| i_am_jl wrote:
| Imagine a future CTO trying to pick the IaC tools for their
| company. They see Terraform as an option, but then learn
| there are multiple forks, licensing questions, and a big
| battle happening in the community. What do they do?
|
| I truly believe that a CTO who sees Terraform as an option
| and who isn't scared off by the BSL, but then has all of
| these other concerns, exists only in fantasy.
| verdverm wrote:
| Lots of people still using elastic, mongo, and redis.
|
| What's different about this one?
| vosper wrote:
| Just went with Elastic cloud after evaluating both
| Elasticsearch and OpenSearch. It was an easy choice to
| stick with the incumbent/creator that I was familiar
| with. No complaints so far.
| verdverm wrote:
| We just went back to TF after giving Pulumi a try. Prefer
| declarative syntax for infra and more abuse of Yaml
| ("fn::..." here) is not what I'm after.
|
| We are working on wrapping TF in CUE since you can
| CUE->JSON->TF
|
| https://github.com/hofstadter-io/cuelm
|
| Many more CUE experiments are going on in the devops
| space
| AaronFriel wrote:
| Pulumi has a few languages other than YAML and Pulumi is
| declarative[1], and the programs you write are only as
| complex as you want them to be. This python program
| declares an S3 bucket and declares ten objects to exist
| in it. from pulumi_aws import s3
| bucket = s3.Bucket('bucket') for i in
| range(10): s3.BucketObject(
| f'object-{i}', s3.BucketObjectArgs(
| bucket=bucket.id, key=str(i),
| ) )
|
| Even so, Pulumi YAML has a "compiler" option, so if you
| want to write CUE or jsonnet[1], or other[2] languages,
| it definitely supports that.
|
| Disclaimer: I led the YAML project and added the compiler
| feature at the request of some folks internally looking
| for CUE support :)
|
| [1] https://www.pulumi.com/blog/pulumi-is-imperative-
| declarative...
|
| [2] https://www.pulumi.com/blog/extending-pulumi-
| languages-with-...
|
| [3] https://leebriggs.co.uk/blog/2022/05/04/deploying-
| kubernetes...
| verdverm wrote:
| I'm aware of the SDKs, but we don't want them because
| they are an imperative interface, no matter how you want
| to spin it as "declarative". I have access to all the
| imperative constructs in the underlying language and can
| create conditional execution without restriction.
|
| Even if I use the Yaml compiler for CUE (which we did) I
| still have to write `fn::` strings as keys, which is ugly
| and not the direction our industry should go. Let's stop
| putting imperative constructs into string, let's use a
| better language for configuration, something purpose
| built, not an SDK in an imperative language. These "fn::"
| strings are just bringing imperative constructs back into
| what could have been an actual declarative interface.
| Note, Pulumi is not alone here, there are lots of people
| hacking Yaml because they don't know what else there is
| to do. CEL making it's way to k8s is another specific
| example.
|
| This cannot be the state-of-art in ops, we can do much
| better, but I get that Pulumi is trying to reach a
| different set of users than devops and will end up with
| different choices and tradeoffs
|
| (I maintain https://cuetorials.com and am very active in
| the CUE community)
| i_am_jl wrote:
| You may make production use of the Licensed Work,
| provided such use does not include offering the Licensed
| Work to third parties on a hosted or embedded basis which
| is competitive with HashiCorp's products.
|
| Read benevolently it's a prohibition from spinning up a
| service based on HashiCorp's code and undercutting
| HashiCorp's pricing.
|
| On the other hand, if I build a product with HashiCorp-
| owned BSL'd code, then HashiCorp releases/acquires a
| product that competes with mine, then my license is void.
| verdverm wrote:
| My understanding is that the aforementioned companies'
| licenses are to the same effect, so what is the
| difference?
| i_am_jl wrote:
| Redis is 3-clause BSD, BSD does not have a "your license
| is void if you sell a product that competes with us"
| clause. Redis does have enterprise products that are
| licensed in a manner similar to BSL, but Redis itself is
| not.
|
| MongoDB and Elastic are SSPL. SSPL approaches the problem
| like the AGPL; it compels licensees who sell a service
| derived from the software to make available under the
| SSPL the source of all supporting tooling and software so
| that a user could spin up their own version of the
| service.
|
| There's an argument to be made that SSPL is _de facto_
| "you can't compete with us" since it would be more
| challenging to make a competitive SaaS offering if your
| whole stack is source available. I don't disagree.
| However, as distasteful as SSPL is, at least it doesn't
| grant licensing to a product conditionally on the
| unknowable future product offerings of HashiCorp.
| verdverm wrote:
| thanks for the explanation, my understanding is that they
| are all after limiting competition in various ways, while
| still trying to maintain the mantle of open source
|
| We are certainly in interesting times around the
| monetization / financial sustainability of open source
| bit_flipper wrote:
| SSPL has no provision even close to the reach of the
| "anti-competition" clause Hashicorp is using. While SSPL
| is not considered open source, it isn't _that_ far off
| from the AGPL. The difference between SSPL and AGPL is
| that SSPL (1) is in effect regardless of modification of
| the service and (2) extends copy left virality to all
| programs which support running the service, including
| those that interact with the software over a network.
|
| MongoDB, Elastic, etc. cannot stop you from running a
| competitor based on the terms of their licenses, they
| just ask that you publish the source code for whatever
| service you're running in its entirety (I acknowledge
| there are disagreements about how far "entirety"
| extends). The clause in Hashicorp's license actually
| revokes the right to use their software at all if you're
| a direct competitor.
|
| OK, no one is going to build an open source competitor to
| Elastic or MongoDB because then you have no moat and your
| business will probably fail, I get it, but it's still
| possible to do without repercussion. It's not like the
| AGPL is that far off in terms of limitation, either,
| which is why you don't see many copyleft services run by
| large corporations unless they've been dual-licensed.
| Spivak wrote:
| I don't get this one, you pick OpenTerraform and get on with
| your life. It's the same with picking OpenSearch over
| Elastic. I can use the proprietary version that locks me into
| a single profit-seeking vendor and doesn't have community
| backing or the one run by a foundation made up of companies
| that _use_ and are heavily invested in Terraform.
| hdaz0017 wrote:
| Hopefully it's not down to CTOs to be picking tools for their
| company but a process within DevOps/Engineering teams etc.
|
| Does anyone else see this as the Nagios Effect all over
| again, there must be lots to learn from history?
| Atotalnoob wrote:
| What is the nagios effect?
| linuxdude314 wrote:
| I doubt that's what would happen if they could afford a
| license from Hashicorp.
|
| Avoiding proprietary licenses has its place but if you aren't
| using terraform to build a product this really shouldn't
| impact you much.
| aldarisbm wrote:
| Shouldnt impact you much. _yet_
| nprateem wrote:
| It was never a public good.
| dbingham wrote:
| > In economics, a public good (also referred to as a social
| good or collective good)[1] is a good that is both non-
| excludable and non-rivalrous. For such goods, users cannot be
| barred from accessing or using them for failing to pay for
| them. Also, use by one person neither prevents access of
| other people nor does it reduce availability to others.
|
| Any free open source product qualifies as a public good. It
| is free for all to use, and one person using it does not
| exclude anyone else from using.
| fishnchips wrote:
| Marcin here, co-founder of Spacelift.
|
| Even though I strongly believe the OpenTF fork could open up
| incredible possibilities for the community (I could go on and
| on about it), it is an equivalent of a civil war. It doesn't
| serve the community and our only interest is in the continued
| strength of the community that we continue to build for.
|
| Based on my immense respect for what's been built under Hashi's
| umbrella I'd rather see a change of mind, and an opportunity to
| honor our pledge of resources (5 FTEs for 5 years) to the
| common rather than partisan cause.
| PeterZaitsev wrote:
| Hi Marcin,
|
| I recognize you're in interesting position in Spacelift. Per
| your recent analyses you may not be impacted and in this case
| you probably do not want to pissoff Hashicorp folks :)
|
| In reality though force better be responded with force and
| showing Hashcorp what what was Terraform will be successful
| as Open Source project with or without them is best way to
| get them to reconsider.
| jeffchao wrote:
| As a user and collaborator of TACOS, agreed that it could
| open up opportunities. Though I echo trade-offs (as in other
| replies) that it could start a civil war that makes it
| difficult for end users and collaborators -- reminds me of
| Python2 -> 3, Presto/Trino, and many other stories. Pledging
| resources is a great approach.
| RcouF1uZ4gsC wrote:
| > it is an equivalent of a civil war.
|
| Why. It is open source. A fork should be no big deal, and
| definitely not a "civil war". I think the community should be
| quicker to fork open source projects that are not serving the
| needs of the community.
|
| The corporations are trying to have the benefits of open
| source without the responsibility. Forking is a normal,
| acceptable part of open source and we should normalize it.
| enneff wrote:
| What would it mean to "normalise" forking? The costs of
| maintaining a fork are significant, and if one group of
| programmers are being funded to work on the project then it
| can be very difficult to fork a project in any meaningful
| way without significant resources behind it.
|
| Also IIUC most of the parties in this conversation are
| corporations. They're all trying to enjoy the benefits of
| open source development for a variety of reasons.
| tedivm wrote:
| I really appreciate that, and I do think it's right of you to
| at least make the attempt.
|
| That being said, I don't expect this attempt to work and I
| fully believe that a fork is going to be inevitable. I also
| think a fork is an amazing opportunity to standardize the
| language and prioritize the features developers want.
|
| It isn't just about the license, but the way that Hashicorp
| has maintained the Terraform project. The github insights
| show that they don't have nearly as many people working on it
| as I would expect, and most of them are split into also
| working on Terraform Cloud. At the same time they don't work
| with the community that well- there are open issues and pull
| requests that just get ignored as Hashicorp clearly doesn't
| see value in open source contributors. This isn't just a
| Terraform issue either- my company had to move off of nomad
| due to the lack of development and support (as well as broken
| features).
|
| I have strong concerns about the future of these projects in
| general beyond just the licensing. An open foundation that
| had multiple companies involved would by definition need to
| find a way for those people to collaborate together, and once
| they do that it makes it easier for them to invite community
| collaboration. So while I do appreciate that it is a drastic
| step, I think it's one that would also be far better for the
| ecosystem and project as a whole.
|
| That said, maybe this is the wake up call hashicorp needs to
| fix these problems. If you provide five FTEs that basically
| doubles the size of their Terraform development team (they
| have more people working on it than five, but those people
| are split into other projects), and once they start working
| with other groups maybe they'll work with the community more
| as well. I'm not holding my breath though.
| lamontcg wrote:
| Smells like the end of Chef. Management doesn't understand
| how much it takes to maintain the open source project and
| is just pouring resources into sales and marketing and
| products that they can charge for, and don't see how that
| erodes goodwill and the technological foundation of the
| company.
| miah_ wrote:
| I also saw that parallel with Chef. I think its the story
| of all VC funded software that attempts to be "Open
| Source". For them, Open Source means "You can read the
| source code, and potentially fix a bug", for us, it means
| community, transparency, and fixing bugs beyond those
| your paying customer has.
|
| I looked at github /chef/chef and github /inspec/inspec
| and its the same as it was shortly after I left. The only
| changes are from the one person who carried over after
| the sale to Progress, and the contracting team out of
| India, with dozens are unanswered queries and pull
| requests from the community.
|
| What really ruffles my feathers was when they had us
| define oss-practices (https://github.com/chef/chef-oss-
| practices), clearly nobody outside our small team read
| (or understood) those words and goals. It feels like it
| was work to make us look better in OSS in order to
| bolster the company sale.
| FrenchTouch42 wrote:
| Thank you Miah for all your contributions (beyond InSpec)
| lamontcg wrote:
| There was a whole lot of community window dressing going
| on. I still wonder if they weren't trying to ship
| maintenance of the open source code off onto the
| community thinking that if all that worked appeared (or
| thinking that it was actually going on--believing their
| own bullshit about how involved the community was) that
| they could just leach that work.
|
| There's probably some manager at Hashi right now trying
| to argue that they should offload TF maintenance entirely
| onto the community and they should pivot to hosting
| services and consulting and making money off of all that
| free work.
| hdaz0017 wrote:
| chef said, did and tried some really dumb stuff and lots
| of it failed for obvious reasons, it's like docker took a
| chunk of their playbook and their business went the same
| way.
|
| It's all good and "fun" on the IPO up.
|
| (in x months we will rewrite the whole universe).
| kragen wrote:
| 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
| reason for the community to sit around twiddling its thumbs
| hoping for such a change. what's important now is that the
| people who are still willing to cooperate can do so
| successfully, and that's what opentf is about
|
| that's even more obviously not the equivalent of going around
| blowing up buildings, raping women, and napalming children.
| it's very much the opposite, in fact
|
| it's unclear to me which of the parties you intend to accuse
| of doing the moral equivalent of burning innocent people
| alive _en masse_ , but either way, maybe you should think
| about walking back that rhetoric a bit
| fishnchips wrote:
| 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.
| kragen wrote:
| 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?
| anyoneamous wrote:
| 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.
| busterarm wrote:
| Hashicorp isn't going to budge here. The same argument that
| you've made about Terraform being the underpinnings and
| needing to be open-sourced can be applied to their other
| important products like Vault, Consul and Nomad as well. The
| ecosystem of those three is plainly a direct competitor to
| Kubernetes which is open-source.
|
| There's really no move for them to make here. It's
| unfortunate.
| fishpen0 wrote:
| Tons of organizations run vault and consul as part of their
| k8s ecosystem so they don't directly compete. The vault CSI
| driver might be the single most installed CSI driver across
| all the orgs I've worked for
| busterarm wrote:
| You're completely missing it.
|
| If you are running Nomad as your orchestrator, because of
| the tight integrations you are almost certainly running
| vault for secrets and consul for service
| discovery/service mesh. The ecosystem of the three is the
| competitor to K8s.
|
| s/ someone who runs both ecosystems at scale.
| twunde wrote:
| While the Nomad stack is a direct competitor to k8s,
| Consul and Vault are both heavily used alongside k8s. In
| fact, Consul had features that were only for k8s the last
| time I checked
| busterarm wrote:
| While these facts are true, that's totally not the
| fucking point and has nothing to do with the argument. I
| say again.
|
| You can have software that both supports and competes
| with the k8s ecosystem. That's even the same type of
| problem all of these companies have with Hashicorp
| software now under the BSL.
|
| Gruntwork builds tools that everyone using Terraform uses
| but they also offer services that Hashicorp would prefer
| that you pay them for instead.
|
| You telling me "but people running K8s also use
| vault/consul" is like telling me that Gruntwork makes
| terragrunt which terraform users use. It doesn't mean
| that Hashicorp doesn't view them as a threat.
| hdaz0017 wrote:
| 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.
| ghshephard wrote:
| 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.
| candiddevmike wrote:
| Most companies are probably using the secret manager
| provided by their cloud platform instead of Vault,
| especially after they tried to buy Vault.
| oneplane wrote:
| You generally only run Vault if your secrets
| don't/won't/can't reside on a public cloud service.
| candiddevmike wrote:
| 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.
| tedivm wrote:
| Hashicorp left the provider frameworks under the original
| licenses, probably because they don't want to scare provider
| developers off. So for now both Terraform and a potential
| fork can continue sharing the same providers without issue.
| dividedbyzero wrote:
| Are they even able to unilaterally relicense third party
| providers?
| throwaway1101z wrote:
| Indirectly, by changing the license for the SDK.
| bickfordb wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
| [deleted]
| stefan_ wrote:
| People have this kind of reaction to Fuchsia a lot: wow, isn't
| this great! Then they learn why it doesn't run on anything and
| why the Linux kernel has 1201530 commits. The real world is
| imperfect. You are trying to make an abstraction of
| "everything" and then complain when it's leaking.
| Sparkyte wrote:
| No because a lot of non cloud tech depend on terraform too. It
| isn't just AWS.
|
| Everything from Kubernetes to various Colocation technology
| leverage it because it codifies the ability to deploy a tech
| stack.
| benlivengood wrote:
| Want to start a GitHub repo? I'll work with you. My list of
| must-haves for configuration management:
|
| Hierarchical state and provider management. The difficulty of
| hooking a kubernetes provider to a EKS or GKE provider in a
| one-shot-apply is pretty terrible. Trying to nest the helm
| provider under kubernetes isn't quite as painful but still not
| great and there isn't a way to get the necessary CRD manifests
| in place for dependencies or resources before they need to be
| created.
|
| Diffs as a first-class citizen throughout the layers of
| providers as opposed to situations like helm_release where helm
| diffs are completely opaque to terraform and especially to
| tools like Atlantis.
|
| Slightly more of real programming language concepts (pure
| functions at least), or else insanely good configuration
| flexibility. Same defaults with simple overrides should be the
| default for all providers and modules in a standard way. I
| think deep merge with reasonable conflict resolution is all
| terraform needs (plus a rewrite of how configuration works in a
| lot of places), but I want to be able to define a template
| configuration for e.g. a cluster and be able to instantiate a
| new cluster with just:
|
| k8s_config = { region = "us-west1" node_config = { machine_type
| = \ cloud_native_machine_type( \ cpu = "amd", ram = "256G",
| cores = "16") spot_instance = true } }
|
| And have deep merging successfully override the default
| configuration with those values, plus that kind of generic
| function capacity to turn verbose/complex configuration blocks
| into a simple definition.
| yevpats wrote:
| I think it's not only the issue with terraform but also the
| underlying infrastructure. AWS should've never have imperative
| APIs in the first place. Or at least it's time for AWS V2 APIs
| jen20 wrote:
| This is clearly a poor idea. Declarative infrastructure
| management is ultimately a dead end, because order of
| operations actually matters.
| phamilton wrote:
| Do you consider cloudformation as imperative APIs?
| easton wrote:
| For most services it's abundantly clear it's calling the
| same imperative APIs under the covers you use as an
| external person because it gets stuck so often. Well, more
| often than you would think if declarative management of
| resources was at the top of Amazon's mind when designing
| these services.
|
| "Internal error? The #$@! does that mean?"
| snom380 wrote:
| 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.
| mdaniel wrote:
| > 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
| cconstantine wrote:
| I've been using terraform for 10-ish years, and this is very
| much not how I feel about it. Terraform absolutely makes life
| easier; I've managed infrastructure without it and it's a
| nightmare.
|
| Yes, it can be awkward, and yes the S3 bucket resource change
| was pretty bad, but overall its operating model (resources that
| move between states) is extremely powerful. The vast majority
| of "terraform" issues I've had have actually been issues with
| how something in AWS works or an attempt to use it for
| something that doesn't map well to resources with state. If an
| engineer at AWS makes a bone-headed decision about how
| something works then there isn't much the terraform folks can
| do to correct it.
|
| I've actually been pretty frustrated trying to talk about
| terraform with people who don't "get it". They complain about
| the statefile without understanding how powerful it is. They
| complain about how it isn't truly cross-platform because you
| can't use the same code to launch an app in aws and gcp. They
| complain about the lack of first-party (aws) support. They
| complain about how hard it is to use without having tried to
| manually do what it does. Maybe you do "get it", and have a
| different idea of what terraform should do. Could you give a
| specific example (besides the s3 resource change) where it
| fails?
|
| It's a complicated tool because the problem it's trying to
| solve is complicated. Maybe another tool can replace it, and
| maybe someone should make that tool because of this license
| change, but terraform does the thing it intends to do pretty
| well.
| r3trohack3r wrote:
| Would be cool to see your laundry list.
|
| I haven't shared your experience, but I read OPs book on
| Terraform cover-to-cover before and trying to work with the
| system.
| 0xbadcafebee wrote:
| Oh god I would be writing for hours. Short version, this is
| not nearly everything: - Bad UX -
| Tool does not have interactive mode to provide suggestions or
| simple solutions to common problems - Lack of options
| or commands for commonly-used tasks, like refactoring
| resources, modules, sub-modules, etc. (Using 'state mv' and
| 'state rm', etc is left as an exercise for the user to figure
| out and takes forever) - Complains about "extra
| variables" found in tfvars files, making it annoying to re-
| use configuration, even though having "extra variables" poses
| no risk to operation - (NEW) Shows you what has
| changed in the plan output, followed by what will *actually
| be changed* if applied, though both look the same, so you get
| confused and think the first part matters, but actually it's
| irrelevant. - Bad internal design - HCL
| has a wealth of functions yet is too restrictive in how you
| can use them. You will spend an entire day (or two) tying
| your brain into knots trying to figure out how to construct
| the logic needed to append to an array in a map element in an
| array in a for_each for a module (which was impossible a few
| years ago). - Providers are inconsistent and often
| not written well, such as not providing useful error messages
| or context. - Common lifecycle policy conventions
| per-resource-type have to be discovered by trial-and-error
| (rather than being the default or hinted) or you will end up
| bricking your gear after it's already deployed. - The
| tool depends on both local state and optionally remote state.
| Local state litters module directories even though nearly
| everyone who uses it at scale uses modules as
| libraries/applications, not the location they execute the
| tool from. Several different wrappers were invented and
| default to changing this behavior because it has been a
| problem for years. - Default actions and best practices
| (such as requiring a plan file before apply or destroy,
| automatically running init before get before validate, etc)
| are left to the user to figure out rather than done for them
| (again, wrappers had to solve this). - Some actively
| dangerous things are the default, like overwriting backup
| state files (if they're created by default). - Version
| management of state is left up to the user (or remote backend
| provider) - Not designed for DRY code or configuration;
| multiple wrappers had to implement this - You can't
| specify backend configuration via the -var-files option, and
| backend configuration can't be JSON ... why? They just felt
| like making it annoying. Some "philosophical" development
| choice that users hate and makes the tool harder to use.
| - Workspaces are an anti-pattern; you end up not using them
| at scale. - You can't use count or for_each for
| provider sections, so if you wanted a configurable number of
| providers (say with different credentials each), tough luck.
| ("We're Opinionated!") - Can't use variables in a
| backend block. ("We're Opinionated!") - Can't have more
| than one backend per module. ("We're Opinionated!") -
| Lots of persistent bad behavior has been fixed in recent
| releases, like not pushing state changes as resources are
| applied, others I can't remember. - Global lock on
| state, because again, ya can't have more than one backend
| block per module. - All secrets are stored as plaintext
| in the state file, so either you don't manage secrets *at
| all* with Terraform, or you admit that your Terraform state
| is highly sensitive and needs to be segregated from
| everyone/everything and nobody can be given access to it.
| - No automatic detection of, or import of, existing
| resources. It knows they're there, because it fails to create
| them (and doesn't get a permission error back from the API),
| but it refuses to then give you the option of importing them.
| The *terraformer* project had to be invented just to get a
| semblance of auto-import, when they could have just added 100
| lines of code to Terraform and saved everyone years of work.
| - Not letting people write modules, logic, providers, etc in
| an arbitrary executable. Other tools do this so you can ramp
| up on new solutions quickly and make turn-key solutions to
| common needs, but Terraform doesn't allow this; write it in
| Go or HCL or get bent. - You have to explicitly pass
| variable inputs to module blocks, so you can't just
| implicitly detect a variable that has already been passed to
| the tool. But this isn't the case if you're applying a
| module; only if you create a sub-module block. This just
| makes initial development and refactoring take more time
| without giving the user an added benefit. - You have to
| explicitly define variables, rather than just inherit them as
| passed to the tool at runtime. Mind you, you don't have to
| actually include the variable type; you just have to declare
| *the name* of the variable. So again, it wastes the user's
| time when trying to develop or refactor, for absolutely no
| benefit at all. - You have to bootstrap the initial
| remote backend state resources *outside* of Terraform, or, do
| it with local state, and then migrate the state after adding
| new resources or using a separate identical module that has a
| backend configuration. Does that sound complicated? It is,
| and annoying, and unnecessary. - You have to be careful
| not to make your module too big, because modules that manage
| too many resources take too long to plan and apply and risk
| dying before completing. (If you're managing resources in
| China, make the module even smaller, because timeouts over
| the great firewall are so common that it's nearly impossible
| to finish applying in a reasonable time) - Tests. In
| Go. - Schema for your tfvars files? Nope; write some
| really complicated logic in a variable to validate each
| variable in a different way. - Providers don't document
| the restrictions on things like naming convention for
| required parameters, so you have to apply to the API and then
| get back a weird error and go try to dig up some docs that
| hopefully tell you the naming convention so you can fix it
| and try again. - Terraform *plan* will give you 'known
| after apply' for values it very easily could tell you
| *before* the apply, but for whatever reason doesn't. You
| never really know what it's going to do until you do it and
| it blows up production. - It's very difficult
| (sometimes near impossible) to just absorb the current state
| of the infrastructure into TF (as in, "it's working right
| now, please just keep it the way it is"). Import only works
| if you've already written the HCL for the resources, and then
| look up how the provider wants to you to import that
| resource. - Version pinning is handled like 5 different
| ways, but is still impossible to pin and use different sets
| of versions when applying different state files for the same
| HCL module code and values.
|
| That's off the top of my head, there's much more.
| theLiminator wrote:
| Yeah I think a restricted nix-like language might be a much
| better choice.
| Hermitian909 wrote:
| > 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.
|
| This describes almost every tool in my toolchain that's over a
| decade old, this is just what happens. If you want to kill
| terraform and replace it with something better the usual bar is
| that it must be 10x better. If that's something you think you
| could do I'd be (genuinely) excited to see it :)
| MrBuddyCasino wrote:
| I don't know what it is about the ops sector that favors ugly
| tools, but apparently they don't care, otherwise Pulumi would
| see more traction.
| danenania wrote:
| There's a lot of inertia in ops tooling. Switching costs are
| very high for an existing project, and once you learn the
| quirks of one tool or another, it takes a lot to justify
| something else for a new project even if it's better, since
| you know the new tool will have its quirks too.
|
| The cost-benefit analysis of new stuff is also different for
| ops compared to pure development. You tend to care more about
| stability and predictability than productivity and elegant
| design. Problems in pure dev land cause bugs that mostly
| aren't super urgent; problems with ops tools bring down whole
| systems and wake everyone up at 2am. For these reasons, ops
| is always going to have a more conservative mindset that
| shuns the shiny new thing to some extent.
| AtNightWeCode wrote:
| This is perhaps the most incorrect post you will ever find on
| HN. I am not a huge fan of Terraform. However, TF is made for
| infra not config. There are several tools out there to manage
| config like Salt, Ansible and so on.
| pa7ch wrote:
| Honest question, what do you consider config vs infra? What
| is infra if not configuring a system to run?
| dbingham wrote:
| Infra is defining the servers that should be running.
| Config is writing configuration files to a running server.
|
| Cloud blurs the line, since a lot of cloud offerings are
| managed where you're really doing both at once when you
| define the managed offering.
| throwawaaarrgh wrote:
| Let's not continue this cargo cult mumbo jumbo.
|
| Terraform is literally a program that looks at a
| declarative configuration file, looks at a state file,
| queries some APIs, and then submits some API calls. That
| is all it does.
|
| There is no "infrastructure", or "config", or "cloud".
| It's literally just calling HTTPS APIs, the same way it
| would call a system call or a library function. Call
| function, pass input, receive output.
|
| There is no magic sauce. There is no difference between
| it and any other tool that has a declarative
| configuration, a state, and operations to try to change
| things to match a desired state.
|
| It's all configuration management. The words "infra",
| "orchestration", "cloud", etc is marketing bullshit. It's
| all just software.
| manvillej wrote:
| its really funny because I needed to create a terraform like
| functionality & went in depth into looking at both building it
| into terraform (which ended up not working) and building a new
| tool.Its not THAT complex. there are a few gimmicks in HCL,
| like it being an actual language, that create some interesting
| features.
|
| but it could just be a yml file. In essence, the requirements
| section says "here are the builders it needs & their versions"
| which identifies types of jobs. each entry is a job with a job
| type, a unique name, and some config info. Each builder is just
| a series of CRUD operations.
|
| Like you said, it builds a directed acyclic graph, queues up
| the ready jobs, and executes them. updating the
| infrastructure's "state" with info from the completed jobs &
| adding new jobs when their dependencies are finished. the state
| files are just a dump of that structure as json.
|
| Its not thathard. I think of myself of a junior level dev and I
| built something for me in my side time in a month with a full
| test suite and its 3/4 of the way there. CLI, builder
| dependency injection, type checking, relationship dependencies,
| it took me a few weekends
|
| I think a senior engineer could build out an enterprise grade
| functional core product in a few weeks. building & maintaining
| the CRUD APIs is the real headache, but I think vendors would
| take care of that themselves if there was a popular enough OS
| solution.
| sredevops01 wrote:
| Terraform is terrible as it is. Good riddance. We need real tools
| instead of messing around with text files with ridiculous
| formatting.
| robbintt wrote:
| I completely agree that it has problems. I use terraform a lot.
| Compared to nothing, I love terraform. However, it's so
| overwrought that it has to be hidden from anyone not in infra
| for a living.
|
| 1. IaC description should be format agnostic and transformable
| (eg definable in yaml, json, whatever).
|
| 2. Something about provider interfaces here, but it's already
| super messy and not sure if it's an improvement or just a shift
|
| 3. State files were wild west last time I checked. And there
| should be a default database interface provider at minimum.
| Maybe there is now?
|
| 4. Forcing the apply->statefile cycle as the default requires
| all of compute, interface, and a human. This should have been
| an abstraction on a raw interface for automated use.
| latchkey wrote:
| While I agree with you about TF having a lot of issues, the
| comment isn't helpful. What would you suggest otherwise? Kind
| of a moot point now that the license is fubar'd, but what could
| be improved to make it better? If you could have a do-over,
| what would that look like?
| zapnuk wrote:
| Right now there is pulumi as a alternative that supports
| different clouds. Otherwise AWS CDK or Azure Bicep come to
| mind.
|
| If i could to a do-over I'd want the solution to look and
| feel like AWS CDK but without the cloudformation in the
| background, and support for GCP and Azure.
|
| I've worked with CDK for 2 years now and being able to define
| your code in Typescript is quite handy and drastically
| reduces the effort it takes for new people to learn how our
| deployment work. It's also quite nice to be able to directly
| bundle and deploy the application together with the
| infrascructure with very little effort.
| latchkey wrote:
| The mind boggles why Pulumi doesn't do ssh.
|
| I have a whole bunch of bare metal sitting in data centers
| all over the world, how am I expected to manage it?
|
| Ansible/Salt/Chef is obviously one type of solution, but
| like you said, being able to code things in TS is really
| nice.
|
| One thing TF does well, is bare metal.
| yjftsjthsd-h wrote:
| > One thing TF does well, is bare metal.
|
| How? I've always viewed TF as good at anything _except_
| metal; the best I would know to do is remote-exec but at
| that point you might as well drop to raw shell.
| latchkey wrote:
| What is raw shell in the world of automation?
| thdn wrote:
| Any reliable alternative at the moment?
| [deleted]
| robbintt wrote:
| For now you can pin your version and cache your sources.
| losvedir wrote:
| I don't get the argument that there's legal ambiguity. It was
| Mozilla licensed through some version; as long as you use that
| version it will be fine, right?
|
| Obviously, there's the argument that Hashicorp might sue you even
| for that, but it feels like the _reductio ad absurdum_ that any
| company can sue you for anything, and not remotely plausible.
| mkl95 wrote:
| > This is similar to how Linux and Kubernetes are managed by
| foundations (the Linux Foundation and the Cloud Native Computing
| Foundation, respectively), which are run by multiple companies,
| ensuring the tool stays truly open source and neutral, and not at
| the whim of any one company.
|
| > We strongly prefer joining an existing reputable foundation
| over creating a new one. Stay tuned for additional details in the
| coming week.
|
| Joining an existing foundation sounds like the right move to me.
| Many organizations need this fork to take off very quickly, since
| they are facing legal uncertainty. Make sure it is clear how to
| support the project, and those organizations will be happy to do
| so.
| datadrivenangel wrote:
| Hopefully the schism this causes will result in more competition
| and improvement in the infrastructure as code space.
| SebastianStadil wrote:
| Scalr cofounder here.
|
| Hope so too, we're a fractured community splits resources and
| forces every organization to have a discussion on what to use.
| That affects all of us.
| new23d wrote:
| As an end-user, not competing with HashiCorp, this change doesn't
| worry me. According to their FAQ [1]: 10. What
| are the usage limitations for HashiCorp's products under BSL?
| All non-production uses are permitted. All production uses are
| allowed other than hosting or embedding the software in an
| offering competitive with HashiCorp commercial products, hosted
| or self-managed. 24. Can I host the HashiCorp products
| as a service internal to my organization? Yes. The terms of
| the BSL allow for all non-production and production usage, except
| for providing competitive offerings to third parties that embed
| or host our software. Hosting the products for your internal use
| of your organization is permitted.
|
| [1] https://www.hashicorp.com/license-faq
| bloopernova wrote:
| It's more that hashicorp leadership has shown themselves to be
| untrustworthy custodians of an infrastructure tool.
| nikolay wrote:
| It should worry you - it hurts the ecosystem. Terraform is just
| a tool. The providers, modules, not supported by HashiCorp, is
| what makes Terraform useful. Ige the ecosystem dies, Terraform
| becomes useless.
| jen20 wrote:
| The ecosystem outside of providers is far less important than
| people like to claim. Open source modules are almost all
| poorly scoped, often just wrapping a single resource
| completely unnecessarily - simultaneously over- and under-
| abstracted. It's also a huge security risk to pull them in.
| colechristensen wrote:
| The only providers I have ever used in production, or would
| likely ever consider using would be published by Hashicorp
| or the software vendor for the resource being managed (for
| example [1]). Much would need to be done to trust any other
| third party without good reason.
|
| I have had similar experiences poking around other tf
| providers which were of apparently low quality.
|
| [1] https://registry.terraform.io/providers/elastic/ec/late
| st/do...
| ryanisnan wrote:
| I think it should, to some extent. A really quick example comes
| to mind. Some of the best documentation on _how_ to use
| Terraform properly comes from folks who provide competitive
| offerings.
|
| I could also see someome like Amazon eventually launching a
| CloudFormation like tool that works natively with Terraform,
| but now that's off the table and I think a net negative.
|
| It also sounds like projects like Atlantis also would be
| against the BSL, including self-managed installations of the
| tool.
| diarrhea wrote:
| It's not about individual usage but the ecosystem around and on
| top of Terraform, whose foundation just got a lot more shaky.
| JeremyNT wrote:
| Even if you don't mind abiding by the terms of the BSL, the
| licensing change is a signal that Hashicorp is in dire straits
| and doesn't know how to operate as a sustainable business.
| They're flailing about trying to increase revenue, and in so
| doing they're removing one of the core components (the open
| source licensing) that made their tools ubiquitous to begin
| with. And what will their next cash grab be?
|
| Here's the kicker though... before the change to BSL, the
| future of Hashicorp didn't really matter as much, since
| somebody could fork their projects and keep them going. But
| with this licensing change, if Hashicorp shuts down one day,
| nobody could create a fork for several years.
|
| So to me, whether or not I _can_ use the software as currently
| licensed isn 't the biggest issue. I want the ability to have
| an "escape hatch" should Hashicorp continue its downward
| trajectory or shut down completely.
| colechristensen wrote:
| Giving away most of your product for free and selling
| commercial services on top when it's very easy to compete
| with you on that front is.... well it's not a sustainable
| business model.
|
| It would be troublesome if any of the vendors at $work past
| or present went bankrupt, this is the nature of having
| external vendors. I am not particularly concerned.
|
| I was not the biggest fan of Terraform in the first place, I
| don't like some of the language choices, but it works better
| than anything else that exists out there.
| [deleted]
| time0ut wrote:
| 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.
| cattown wrote:
| I like Terraform and will continue to use it. I'm just an end
| user that isn't involved in building other product offerings on
| it or a user of other derivative products.
|
| Even though this really doesn't affect my use case it does feel
| like kind of a dirty bait and switch. I do hope for a future
| where there's a version (and Terraform provider module versions)
| that are actively maintained under a true open source license.
| I'll favor using those over the official BSL version as much as
| possible.
|
| I guess it's the CLA that all of the contributors signed that
| allows this to happen? I wonder if there's a way for open source
| licenses to address this, and disallow the use of CLAs, or
| require some CLA clause that doesn't allow sudden switches to
| non-permissive licenses?
| jsiepkes wrote:
| Part of me hopes a fork comes out of this. I mean maybe features
| like this PR[1] for local state file encryption can then finally
| get merged.
|
| [1] https://github.com/hashicorp/terraform/pull/28603
| fishnchips wrote:
| That would be one of the 1st things I'd love to see myself.
| Plus opening of "internal" to let folks build new stuff on top
| of Terraform elements.
| LVB wrote:
| I did see https://github.com/diggerhq/open-terraform but have
| no idea if it is related. And I'm sure there are others. What
| I'll be interested to see with the forks is how they will
| practically be maintained. All the bug and security fixes that
| HashiCorp is writing can't just be cherry-picked into these
| forks (I think?), so what exactly are they supposed to do?
|
| Update: and in the past hour this repo is gone.
| pawelpiwosz wrote:
| Hi! OpenTF is not connected with a single company. This is an
| united, community-driven effort. You can check on the
| manifesto side who is behind. And we welcome all support!
|
| The fork you mentioned is no longer existing.
| JeremyNT wrote:
| > _All the bug and security fixes that HashiCorp is writing
| can't just be cherry-picked into these forks (I think?), so
| what exactly are they supposed to do?_
|
| Indeed, any fork will need to implement their own bug fixes.
|
| Ideally they should do this "clean room" and not even look at
| the BSL'd code, to help defend against any accusations of
| copyright infringement.
| Fawlty wrote:
| Hashi got really good at ignoring PRs if they weren't their
| own. They even ignored the PRs coming from the dev teams of
| their own customers (ie users of TF Cloud and Enterprise) which
| speaks volumes about their willingness to listen to the
| community...
| notswayze wrote:
| What's the cleanest way to pledge support as an individual, but
| without pledging as part of my company?
| brikis98 wrote:
| We just moved the signatures to a table format, so you
| individuals can now add themselves to the table: just set the
| "type" column to "Individual." Thank you!
|
| https://opentf.org/
___________________________________________________________________
(page generated 2023-08-15 23:00 UTC)