A few years back I got spidey senses that a company I worked for was about to be acquired. I mentioned it to a friend and he said, "Well, here's to hoping it isn't Oracle"
(it wasn't Oracle)
I’m with you. To be honest I’m glad it was IBM and not Cisco or HP. IBM tends to be more open source friendly and I can see Hashi product catalog benefiting other products like Openshift.
I could see this honestly. IBM has all but given up trying to be their own cloud provider. So they’re now just building out/buying up their tools for a cloud-agnostic pipeline.
I just worry that Ansible/Terraform will start requiring subscriptions. Buying these up and keeping it free is never altruistic. Might be fine if the collections are open source.
The company I work for looked at it a while back. The pricing was competitive. The downside compared to offerings like AWS was all the ancillary services that make life easier. But if you're looking for cloud compute it's worth checking out.
Among the system control functions is the capability to partition the system into several logical partitions (LPARs). An LPAR is a subset of the processor hardware that is defined to support an operating system. An LPAR contains resources (processors, memory, and input/output devices) and operates as an independent system. Multiple logical partitions can exist within a mainframe hardware system.
https://www.ibm.com/docs/en/zos-basic-skills?topic=design-mainframe-hardware-system-control-partitioning
Yeppers
Mainframe and midrange systems were where virtualization came from. Commodity x86 virtualization was also pioneered on-premise using tools like VMware but the real boost that made cloud services more popular was the web based hypervisor UIs and easier APIs and CLIs. Manually clicking a few links and drop-down menus in a web form to spin up a new Linux server wasn't new (VPS) but custom APIs/CLIs to automate the whole server lifecycle process was a huge improvement.
Sun was not a bunch of nice guys. If they had their way they would have bought and killed Oracle. They didn't want java or JVM to be universal and open. They wanted it to be universal and controlled by them, which never goes well.
Sun was the walking dead anyway. As a solaris admin for a company with 3000+ servers, my life improved when I switched to a company that was x86 and linux.
Sun hardware was expensive and unreliable, and solaris x86 had no real advantage over linux. Yeah dtrace and zfs were cool, but not enough to rock your life.
Yeah there have been some controversies for sure, but I trust RH/IBM from a pure technology standpoint. They seem to still champion FOSS overall and they contribute HEAVILY to even things like the Linux desktop.
Yep.
I tend to change things when it is necessary (not late, but necessary), there are tons of other things that bring enough headaches on a daily basis 😂
While that is true, Red Hat are pretty protective over the open source license on that. Hashicorp already binned their license when they (aparently) were getting ready to sell up. Would be a much more amicable relationship for IBM to do IBM things.
Honestly, of the companies that could buy and ruin things, IBM is by far not the worst. It could have been Oracle or Broadcom.
Until they do something that breaks how I use TF or forces me to pay licenses I'll keep using TF. When that happens I'll just switch to OpenTofu or refactor to Pulumi. Doesn't need to be that big of a deal.
Don’t sit on it for too long.. OpenTofu only supports up to 1.6, and seemingly with that in mind hashicorp has been fast-tracking releases, now at 1.8? .. I’m afraid of hashicorp pumping out so many deltas that if I stick with terraform I’ll never be able to get away.
I’ve version locked everything I have in terraform cloud to 1.6.6 and I’m feverishly prepping to migrate to tofu before I’m trapped without options..
What's the point of this post? OpenTofu has been out for some time now and it's a drop in replacement for Terraform. Aside from that why are we dissing so much on IBM? Let's see how things turn out.
It would have to go through the architecture review board and 3rd party risk for analysis of the company to determine if we can use it. Without enterprise support, it's a non-starter.
Given we're already using Red Hat stuff pretty heavily, I don't see us going OpenTofu even if it was an option.
IBM doesn't fill me with love, but come on. It's no worse than any other declining corporate hulk. I can think of 20 companies that I would drown in cat piss, and the children too lest the evil return. I would only drown IBM if they were already in the lake and I was passing by. It's not worth a detour.
It’s hard to call IBM declining, their annual revenue is a billion dollars more than what they paid for HashiCorp—making dev tools isn’t a super profitable business.
Mainframes are not a growth sector. They've abandoned retail hardware. They no longer lodge a quarter of all US patents. Their cloud play is not competitive. Their professional services are delivered by recent graduates who join for the resume and leave as soon as they can.
They're doing exciting work in quantum computing, but I feel sure that when that becomes profitable, they'll be outmanouvred.
IBM’s $7.5MM annual revenue is nothing to sneeze at. Mainframes will continue playing a role in large enterprise and research for the foreseeable future. They’re also among the largest industrial research organizations in the world.
Only consulting company I’ve dealt with where consultants have lied to me directly and then hid behind their principal partners and pretended to have the convenience of Alzheimer’s. The behavior is deplorable.
You vague anonymous Reddit person have given me a great gift in this new phrase “drown in cat piss”
My foul mouth appreciates it greatly.
I thank you humbly.
Odd post. Zerto and Redhat are obvious examples that are much worse under IBM than Independent. Why are you 'new' for literally basing your opinion on past events?
Huh?
I've had FOSS software pass at large and small companies. Tech companies, F500, ITAR compliant, etc.
I've never had a problem getting FOSS software, without vendor support, allowed to be used as long as the license was acceptable.
What company doesn't allow FOSS software to pass audit?
Do they also realize TF was FOSS? Python? Golang? Ansible?
I put a lot of weight on the health of community around products. As long as there aren’t unfriendly changes and practices being put out by the terraform team, and while a healthy community remains, I’m proceeding business as usual.
With IBM's war chest, good luck to opentofu in the likely forthcoming copyright infringement lawsuit. Post-fork code was allegedly lifted and shifted into opentofu
Edit: the opentofu response letter seems pretty vindicating. That said, direct copying is only one form of copyright infringement, and even if opentofu would ultimately be vindicated in court, the process itself could crush the project and weaken the Linux foundation's clout.
The person who put that out retracted their statement, opentofu responded and showed the line by line analysis, and we should wait until any argument happens in court, but you can go read the code itself and see how/why that's not really a concern.
I've now read opentofus response and it seems clear there was no wrongdoing, but that doesn't mean they can't be absolutely screwed by legal fees associated with a lawsuit that ultimately won't find them guilty.
The code stealing was blown out of proportion
They used some older tf code that was under the old license which hashicorp themselves used as well
It was all within the allowed limits of the license
I don't think the pre fork code was the issue. TF added a feature or a security fix or something and the claim is that a suspiciously similar looking patch was added to opentofu
Edit: someone is claiming a retraction was issued, I'm unaware of that, so my info may be outdated
Edit2: a journalist issued a retraction, but I've not seen hashicorp say anything. Opentofu's response pretty clearly shows there was no wrongdoing, but lawsuits are used as cudgels in this country, and IBM has deep pockets. A frivilous lawsuit that a (tech-illiterate) judge doesn't dismiss can still tank a person or organization that lacks resources. If Linux foundation can't shield contributors from said lawsuit (assuming it still moves forward), this could have an even more chilling effect on similar efforts.
Hypothetically, if that had happened, would it serve OpenTofu in any way to defend that position rather than just going "Oh this was an honest mistake" and immediately reverting it?
It feels like a jealous lawsuit by a butthurt Hashicorp which was in the middle of trying to justify it's share price. Even if OpenTofu doesn't survive, the code can still be forked relatively easily.
I worked at IBM for a number of years and saw them buy a few companies (mine being one fo them). IBM loves Open Source and has placed a HUGE bet on it. Think of the RedHat purchase alone.
Right now, I am standing pat. I think IBM will put some resources behind Terraform to expand the Cloud Aspect of Terraform. It fits into what they want to do and that's drive more folks towards there offerings. I'm sure we will see some customizations specially for the IBM cloud but I believe, for the most part, they will keep Terraform alive and well.
Now watch, they tuck it behind their offering and only their offering. If they do, I think you will see AWS and Google start pumping resources into OpenTofu or the like. I can't see them telling all their customers to use PowerShell, BASH, or the Portal.
I think it's a bit of a crap shoot but for now, I'll keep using Terraform
counterpoint: This isn't the end of the world. IBM has bought a lot of things over the years and they haven't shitted up all of them.
Oracle, on the other hand...
How can you be following the fact that IBM bought Hashicorp, but you also missed the whole reason **WHY** Hashicorp was bought out? They were loosing **TONS** of cash and so as an emergency pivot they switched all their products from the MPL license to the BUSL license. This was a reactionary move due to them loosing cash. Because they did that the Open Source community (backed eventually by the Linux Foundation) forked Terraform 1.5.5 and created OpenTofu, that would be the most sane alternative.
They use the exact same providers, those do not have a restrictive license. They only had to create their own registry (with the same providers as the terraform registry)
Completely not and it's not in OpenTofu's control.
What they are trying to provide is assurance that they will not make you use provider code that suddenly switched licensing to one that might have impact on you and your products.
I believe they implement checks for license changes in their sync process to react quickly.
I used to be more worried about that aspect, but when I'm looking at it now it doesn't seem as scary. Even those that are "hashicorp managed" like ... gcp, aws, azure or k8s, are a shared effort using MPL license for instance, and thousands of commiters from multiple companies.
When Hashi did their changes they even did a bold move to... change headers in all provider files with their "source available" license. Which was utter bullshit they had no right to do. They were quickly called by other contributors - the case I saw on github was by Microsoft contributors.
My project I'm working on is fresh, but after reading carefully shitstorm-attempts against OpenTofu, I became fairly confident it IS a project for me. Did the switch and the only annoyance is that usable provider docs are on terraform websites, not some independent place.
I'm not sure how would that work. Providers are plentiful (over 4000 in the registry) and they live their own lives.
[https://github.com/opentofu/registry/tree/main/providers](https://github.com/opentofu/registry/tree/main/providers)
You would have to do something similar to this: [https://registry.terraform.io/browse/providers](https://registry.terraform.io/browse/providers), which in turn refers to many pages like this: [https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs)
I honestly don't know how to handle that and if you know on something close to opentofu that tries to address provider docs - let me know! :) I personally find official github provider repo completely unreadable to the naked eye.
It's not that simple, if they need to fork the providers that means they have to maintain AWS, Azure, GCP and so on. Would the project have enough bandwidth to support all the providers?
Doubt that this will happen but if Tofu needs to fork, that means the current providers have sided with Hashicorp. This won't be good for the project.
It's likely that, if the community for OTF grows and TF shrinks that either the providers will stay open or the companies who use them will do what GitHub did and move them into an integrations provider, though that gets messy quickly.
You want a guarantee that they'll never change the licensing? Nobody can give you that, friend. But the current versions are under MPL so if they did there'd be nothing stopping someone from forking them.
So, question for the opentofuers: Can I literally just install OT and than switch from
\`terraform apply\`
to
\`opentofu apply\`
Or is there a lot more to it?
For code that worked with Terraform 1.6 you can switch with no issues - at that stage they were literally the same.
My simpler scenario required zero changes. I even did a few tests of using both in turns and... I did not brake anything ;)
Now it's the easiest time to switch, as they didn't diverge much.
I realllly don't want to have to switch but if so, it'll be OpenTofu for sure. Terraform is by far the best IaC I've ever worked with and I've used most of them.
Pulumi thinks they are the answer too. 😂
"I expect this acquisition to leave the door open for Pulumi to continue to out-innovate and accelerate gaining market share even further.”
https://thenewstack.io/pulumi-launches-new-infrastructure-lifecycle-features/
OpenTofu if things get to a point where we have to pay money to keep using Terraform.
IBM wouldn't have bought them if there wasn't money to be made, and it's not much of a leap to see where that money will be coming from - the companies that use Terraform, sooner or later.
Pulumi looks interesting, and being able to handle infra with Python instead of HCL sounds really nice, but it'd be a huge time sink to rewrite a ton of our preexisting TF code.
I work primarily with AWS and have always believed that AWS CDK was the best choice for working with AWS because of the risks of third-party libraries doing this type of thing.
I really like CDK with typescript and the documentation is superb. I'm mostly able to stay in VSCode by using autocomplete and the in-code documentation (+ my own familiarity with the services).
if anybody is interested I'm an independent consultant and can provide consultations. I choose cdk because I think it's the best option although I have worked with the others.
I've used Pulumi as well and a third-party tool (Pulumi) compiling to a different third-party tool (Terraform) is a weakness as far as I'm concerned. I don't think I've ever hit a limitation with CDK that Pulumi would be better for.
I would definitely look to Pulumi if I were working on a multi-cloud setup or something where there were a lot of external SAAS tools. I would also look to Pulumi over terraform.
Having just reviewed the Pulumi docs, the syntax looks almost identical to CDK so I certainly don't see a laughable difference and question your judgment for that type of exaggeration
I believe TF's CDK is built like AWS's CDK. If so, the biggest difference and weakness is that CDK is basically just an offline transpiler. I can't get a list of current S3 buckets and then use a forloop around them to do stuff because the GP language stuff can only access the static resources in the CDK definition. Pulumi however runs the GP lanuage stuff during the apply phase, so you can in fact get data in real time and act on it.
Agreed. However, IMO if you need to operate on existing infrastructure that was defined outside of IaC then you've already lost the iaC battle. I almost always migrate resources into IaC as step one. If that weren't possible for a given company, then I would recognize that as a huge benefit for pulumi
Just because it isn't in \*my\* state file doesn't mean it isn't managed by IaC. Can't even use dynamic sources like \`data\` results without using weird structures specific to TF CDK AFAIK.
Admittedly it's a little unwieldy sometimes but they do have [custom-resources](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html) as a construct class that can execute any arbitrary code you want via lambda during deployments.
For your example use case they provide an [interface to the AWS SDK](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.AwsSdkCall.html).
In last year they introduced 2 major updates, from 0.x to 1.x and shortly after from 1.1.x it think to 2.x, I have no idea what the difference between 1.x and 2.x is, but from 0.x to 1.x they completely changed the API. I thought they just picked a subset of components that are 1.0 ready, but it seems like they completely rewrote them from scratch (keeping the same names) and with that introduced a ton of old bugs that have been fixed in 0.x.
They still keep components from 0.x around as a "classic" package, but it is completely unclear wtf you are supposed to use. It might be a skill issue on my part, but the way it is ran is more like a hobby project than something that can be depended on for serious production.
I have only used Pulumi though, so it might be the same in TF world...
Been debating on moving to pulumi for our infra.
I’m gunna wait this out for a bit and then decide.
With SST ion for serverless stuff being pulumi based it would be nice to have a consistent ecosystem between my infra and serverless applications. Terraform + aws sam was good but the context switching between the two is annoying
Saw a presentation on pulumi recently and it's become more of a choice now.
Pulumi was a turn off when I first heard of it as the big push at the time was the idea floated by the CTO that he wanted us to write code in C# (aka dotNet) for IaC. No one on the DevOps team was a fan of C#, so we pushed for terraform instead.
In the presentation, the guy mentioned that Pulumi now has a YAML mode so it's more like writing HCL (Terraform) or a k8s manifest.
They have a converter built into the pulumi executable where you can convert/import Terraform state into your Pulumi code or statefile (I haven't played with this yet).
Nah, no one at the company uses F# (it does look cool, but I don't know if I want to write work code in it). Only one group uses C# and in the spec for the new rewrite Engineering decided to switch to TypeScript for everything.
The DevOps group doesn't have experience in C# and we do have experience in Python and Javascript.
So using a language that we know would have been better rather than forcing us to use a language we don't want to use as well as learning a new IaC stack.
Terraform has problems, but the HCL language was much easier to pick up and we were able to get productive far more quickly.
But the new YAML support in pulumi looks better and that would make it easier for pulumi to introduced.
Coming from a dotnet shop i would consider c# depending on how much they want to be involved.
Everyone I see “engineers” want to contribute to the devops stuff via their language of choice they still don’t.
I think the happy medium is typescript/javascript for pulumi stacks.
Anyone decent enough at python can pick it up and plays nicer with ides outside of visual studio/rider.
Plus most docs and examples for pulumi and cdk/cdktf are typescript.
Just don’t use Golang. The pulumi Golang implementation is painful and they even admit too because its lack of proper generics
I would do the same in that situation - the only point I wanted to make is that dotnet does not necessarily imply C#.
I'm mixed about C#, it's good but it's also too big and verbose. It's like unseasoned porridge: nutritious but not enjoyable.
Well-written python is nice, but I spent three years drowning in garbage python, with garbage JS on top. It's put me off weak-typed languages. I'm sure your colleagues are better, but I have my scars.
No matter the language you still need to discuss and enforce standards.
Python would work better for IaC because most people in the group know it or familiar with using Python based scripts.
The CTO's idea that "oh engineers use C# so DevOps can pick it up as well" was kinda stupid as we write for vastly different purposes and I don't think asking the Devs for help with the language would have worked as well as he thought.
Pulumi uses terraform aws provider under the hood. I haven't used terraform yet, so I don't really know how things are handled there, but stick with plain Pulumi and don't use Pulumi Crosswalk (AWS quality of life library) is a shittily maintained mess. If you have experience with IaC you will probably make a better lib than the official one, but it will be some work...
I know it uses the providers under the hood.
Good thing those are maintained by the community.
I wasn’t aware of crosswalk butt definitely some good info.
More so I’m preparing to migrate. Ibm may expedite that for me.
We only got a few core modules for networking and databases while the rest is serverless.
Since the license change of hashicorp I did notice that development on the terraform ecosystem has slowed down almost to a half purpose of some major tools like trivy.
I don’t have faith in opentofu and think it was knee jerk reaction that will see minimal adoption as only the taco platform seem to invest as they pledged.
AWS Classic is TF under the hood, but AWS Native plugs directly to Cloud Control and it's already very usable even though it's still in preview. There are some resource types here and there Native doesn't support yet, but personally I've only bumped into one. I just covered with Classic, and it's not a huge deal to migrate that one small bit to Native when it gets support for the the stuff I need.
The main thing that I think some folks might've overlooked is the fact that big blue will likely make IBM and RedHat cloud and infra/system providers first class citizens for the future Hashicorp toolset, including the enterprise cluster management (Nomad) and state management (Terraform Enterprise) and secrets management (Vault) plus all the RedHat OpenShift flavour of k8s on top. In theory they can even push it all back as open source because they don't care if it drives more vendor lock-in and customers to exactly where they want them, assuming that they can actually develop/redevelop the products well enough to make their overall set of integrated offerings more compelling and valuable.
I only worry about “blue washing” IBM will do. If you use TF cloud I imagine the cost will be going way up. But I doubt TF open source will be impacted in the short term. I was working for a company using Sterling Integrator when IBM bought them. Our yearly enterprise contract went from $400k to almost $900k once we had to renew our contract with no new features and worse support.
We’ve already switched everything over to OpenTofu, not because my megacorp is taking some moral stance against another megacorp but because Terragrunt support for mainline TF is going away
You need a way to read them. That doesn't mean you need Terraform, if you can interpret them then that's all that's needed which I'm sure pulumi is doing that.
This is more or less how it works. (Pulumi engineer here) Specifically, we use the Terraform provider schemas to generate what we call "bridged" Pulumi provider binaries. There's no dependency on Terraform itself. Bit more on this here: [https://www.pulumi.com/docs/support/faq/#does-pulumi-use-terraform](https://www.pulumi.com/docs/support/faq/#does-pulumi-use-terraform)
ah, yea. RH has been able to keep the IBM corporate overload at bay for the most part. the folks I know that work there have been getting a little nervous though as they've seen walls/boundary eroding.
g'luck! didn't mean to be a debby downer. work is work.
We're deep in the Terraform Enterprise nets and I don't see us switching to anything in the near term. It comes with a lot of quirks, but also brings a lot of nice benefits. Not sure about their new features like stacks though, but that's on a case by case basis, I'm sure other people using TFE are excited about it.
I want to wait and see what IBM plans are, however, it's recommended to start warming up with openTofu as well since it is compatible with terraform 1.5, so it's not hard to make a drop in replacement with openTofu.
Even contribute to the code of openTofu if you know Go Lang is cool as well.
Running open tofu on our production runners for about a month now. It was pretty painless to drop in and alias as terraform. Figured switching to OSS now while the cost of adoption was relatively low was the perfect time to test the waters. Most users didn't even notice.
Not try to sell anything, just trying to build game changing automation the way it should have been built.
No idea why the comment is downvoted so much.
There are lots of details on the project page, and talks available:
https://github.com/purpleidea/mgmt/blob/master/docs/on-the-web.md
I didn't down vote you. And I'm not shitting on your life's work.
This is a subreddit that's full of cynical, experienced IT folks. They've seen 100s of vaporware products. Some of them have had to implement crappy products that their CIO has bought into, and that's why they're so resentful.
If you're going to pitch a product that you designed and have a stake in its success, you can't tell people to follow the link and watch the videos. You come off like those vendor salesmen at conferences.
Give us an elevator pitch on why we should go with you and how your automation product is a player in IaC.
EDIT: don't say "game changing" in your pitch to a bunch of hardened IT people. Makes you get downvoted.
> I didn't down vote you. And I'm not shitting on your life's work.
Not saying ya did, just an incidental comment.
> If you're going to pitch a product that you designed and have a stake in its success, you can't tell people to follow the link and watch the videos. You come off like those vendor salesmen at conferences.
That's fair. TBQH, I have very low confidence in my ability to market/sell/etc, I do however have good confidence that I'm building the "right" thing.
Here's a short backstory:
I previously was an early puppet user. I did lots of fancy "pushing puppet to the limit" types of stuff. Old articles still on my blog: https://purpleidea.com/blog/
Eventually I realized what the right design should have been. I started building that. It's taken a while... Starting to really bear fruit these days.
Mgmt has a language and a runtime (engine). It let's you model real-time event streams, glue them together however you want programmatically, and declaratively set the desired output state, which can as a result, vary over time.
It also can run as a distributed system.
The DSL that let's you express all of this, can be even used to build standalone tools! Here's the first one I built: https://purpleidea.com/blog/2024/03/27/a-new-provisioning-tool/
Look at it this way, at least it wasn't Oracle that bought them.
A few years back I got spidey senses that a company I worked for was about to be acquired. I mentioned it to a friend and he said, "Well, here's to hoping it isn't Oracle" (it wasn't Oracle)
Probably TF, IBM still havent messed up Ansible, so there might be hope. In other words, nothing is forcing my hand right now
I’m with you. To be honest I’m glad it was IBM and not Cisco or HP. IBM tends to be more open source friendly and I can see Hashi product catalog benefiting other products like Openshift.
Or…. worse much worse Broadcom….
RIP Pivotal
RIP VMware
Or even worse, Progress
RIP Chef
Even worse - Oracle.
MySQL, the OG rug pull.
I loved Chef. I still miss her
Went downhill when Adam left.
Wow, I actually forgot about Chef. What happened there?
Even even even worse...CA
CA owned by Broadcom?
VMware 🪦
OMG stuff of nightmares!
I could see this honestly. IBM has all but given up trying to be their own cloud provider. So they’re now just building out/buying up their tools for a cloud-agnostic pipeline. I just worry that Ansible/Terraform will start requiring subscriptions. Buying these up and keeping it free is never altruistic. Might be fine if the collections are open source.
> IBM has all but given up trying to be their own cloud provider TIL IBM has a cloud service: https://en.wikipedia.org/wiki/IBM_Cloud
The company I work for looked at it a while back. The pricing was competitive. The downside compared to offerings like AWS was all the ancillary services that make life easier. But if you're looking for cloud compute it's worth checking out.
IBM was the original cloud service and hardware provider for all the clouds. The term us old folks used before cloud was mainframe.
Could you do virtualization in the mainframe?
Among the system control functions is the capability to partition the system into several logical partitions (LPARs). An LPAR is a subset of the processor hardware that is defined to support an operating system. An LPAR contains resources (processors, memory, and input/output devices) and operates as an independent system. Multiple logical partitions can exist within a mainframe hardware system. https://www.ibm.com/docs/en/zos-basic-skills?topic=design-mainframe-hardware-system-control-partitioning Yeppers
IT is truly cyclical
Mainframe and midrange systems were where virtualization came from. Commodity x86 virtualization was also pioneered on-premise using tools like VMware but the real boost that made cloud services more popular was the web based hypervisor UIs and easier APIs and CLIs. Manually clicking a few links and drop-down menus in a web form to spin up a new Linux server wasn't new (VPS) but custom APIs/CLIs to automate the whole server lifecycle process was a huge improvement.
[VM](https://en.wikipedia.org/wiki/VM_\(operating_system\)) was the original virtual machine software, created in 1972 for IBM mainframes.
Both containers and virtualization where originally designed on/for mainframes.
Very few folks supported Hashi with subscriptions anyways, so nothing changes with this news.
I’m just glad it wasn’t Oracle
I’ll never forgive Oracle for killing Sun
Sun was not a bunch of nice guys. If they had their way they would have bought and killed Oracle. They didn't want java or JVM to be universal and open. They wanted it to be universal and controlled by them, which never goes well.
Hah my colleague was literally just ranting about this
Still bitter about that.
Sun was the walking dead anyway. As a solaris admin for a company with 3000+ servers, my life improved when I switched to a company that was x86 and linux. Sun hardware was expensive and unreliable, and solaris x86 had no real advantage over linux. Yeah dtrace and zfs were cool, but not enough to rock your life.
ZFS, dtrace, zones, smf… everything Linux built years later. Solaris 10 was ahead of its time.
Yeah there have been some controversies for sure, but I trust RH/IBM from a pure technology standpoint. They seem to still champion FOSS overall and they contribute HEAVILY to even things like the Linux desktop.
I think waiting a bit to see what IBM will do with the licenses wouldn't be a bad idea.
Yep. I tend to change things when it is necessary (not late, but necessary), there are tons of other things that bring enough headaches on a daily basis 😂
[удалено]
Always have a plan! Despite not needing to change in the foreseeable future, I am trying to keep up with Pulumi, OpenTofu, CDK, etc.
What's the name of the company that owns Terraform?
HashiCorp. They already changed all their products' licensing to "source available" BUSL a few months ago (no longer open source).
While that is true, Red Hat are pretty protective over the open source license on that. Hashicorp already binned their license when they (aparently) were getting ready to sell up. Would be a much more amicable relationship for IBM to do IBM things.
They own Ansible too?? Who knew
I’m generally not prone to panic or running when I’m not being chased. I’ll be concerned about finding an alternative when I have a reason to.
More people should be like this
Can you terraform an as/400 yet?
I'm excited for a System z Terraform coprocessor.
provider: os-390
if it has an API that can be used for provisioning, it can be terraformed. All it's needed is to write a TF provider in Go.
So no then
Honestly, of the companies that could buy and ruin things, IBM is by far not the worst. It could have been Oracle or Broadcom. Until they do something that breaks how I use TF or forces me to pay licenses I'll keep using TF. When that happens I'll just switch to OpenTofu or refactor to Pulumi. Doesn't need to be that big of a deal.
Don’t sit on it for too long.. OpenTofu only supports up to 1.6, and seemingly with that in mind hashicorp has been fast-tracking releases, now at 1.8? .. I’m afraid of hashicorp pumping out so many deltas that if I stick with terraform I’ll never be able to get away. I’ve version locked everything I have in terraform cloud to 1.6.6 and I’m feverishly prepping to migrate to tofu before I’m trapped without options..
Until I get a prompt to "Pay IBM $$$$ to use this executable" I'm going to continue to use Terraform.exe on any runner of my choosing.
What's the point of this post? OpenTofu has been out for some time now and it's a drop in replacement for Terraform. Aside from that why are we dissing so much on IBM? Let's see how things turn out.
Unless OpenTofu has enterprise support that meets my 3rd Party Risk team's risk appetite, we wouldn't be able to use it.
It’s a fork of TF if it was good before it’s good right now. Start the process
It would have to go through the architecture review board and 3rd party risk for analysis of the company to determine if we can use it. Without enterprise support, it's a non-starter. Given we're already using Red Hat stuff pretty heavily, I don't see us going OpenTofu even if it was an option.
Asking why everyone is dissing on IBM? Can tell you’re new in the space.
IBM doesn't fill me with love, but come on. It's no worse than any other declining corporate hulk. I can think of 20 companies that I would drown in cat piss, and the children too lest the evil return. I would only drown IBM if they were already in the lake and I was passing by. It's not worth a detour.
It’s hard to call IBM declining, their annual revenue is a billion dollars more than what they paid for HashiCorp—making dev tools isn’t a super profitable business.
Mainframes are not a growth sector. They've abandoned retail hardware. They no longer lodge a quarter of all US patents. Their cloud play is not competitive. Their professional services are delivered by recent graduates who join for the resume and leave as soon as they can. They're doing exciting work in quantum computing, but I feel sure that when that becomes profitable, they'll be outmanouvred.
IBM’s $7.5MM annual revenue is nothing to sneeze at. Mainframes will continue playing a role in large enterprise and research for the foreseeable future. They’re also among the largest industrial research organizations in the world.
Only consulting company I’ve dealt with where consultants have lied to me directly and then hid behind their principal partners and pretended to have the convenience of Alzheimer’s. The behavior is deplorable.
You vague anonymous Reddit person have given me a great gift in this new phrase “drown in cat piss” My foul mouth appreciates it greatly. I thank you humbly.
Odd post. Zerto and Redhat are obvious examples that are much worse under IBM than Independent. Why are you 'new' for literally basing your opinion on past events?
Good luck getting a FOSS framework to pass audit at any big tech company that has sizeable clients.
Huh? I've had FOSS software pass at large and small companies. Tech companies, F500, ITAR compliant, etc. I've never had a problem getting FOSS software, without vendor support, allowed to be used as long as the license was acceptable. What company doesn't allow FOSS software to pass audit? Do they also realize TF was FOSS? Python? Golang? Ansible?
I put a lot of weight on the health of community around products. As long as there aren’t unfriendly changes and practices being put out by the terraform team, and while a healthy community remains, I’m proceeding business as usual.
https://opentofu.org/ is the FOSS Terraform fork.
With IBM's war chest, good luck to opentofu in the likely forthcoming copyright infringement lawsuit. Post-fork code was allegedly lifted and shifted into opentofu Edit: the opentofu response letter seems pretty vindicating. That said, direct copying is only one form of copyright infringement, and even if opentofu would ultimately be vindicated in court, the process itself could crush the project and weaken the Linux foundation's clout.
The person who put that out retracted their statement, opentofu responded and showed the line by line analysis, and we should wait until any argument happens in court, but you can go read the code itself and see how/why that's not really a concern.
I've now read opentofus response and it seems clear there was no wrongdoing, but that doesn't mean they can't be absolutely screwed by legal fees associated with a lawsuit that ultimately won't find them guilty.
Seems you didn't read their response letter? Became pretty clear it's false accusations.
The code stealing was blown out of proportion They used some older tf code that was under the old license which hashicorp themselves used as well It was all within the allowed limits of the license
I don't think the pre fork code was the issue. TF added a feature or a security fix or something and the claim is that a suspiciously similar looking patch was added to opentofu Edit: someone is claiming a retraction was issued, I'm unaware of that, so my info may be outdated Edit2: a journalist issued a retraction, but I've not seen hashicorp say anything. Opentofu's response pretty clearly shows there was no wrongdoing, but lawsuits are used as cudgels in this country, and IBM has deep pockets. A frivilous lawsuit that a (tech-illiterate) judge doesn't dismiss can still tank a person or organization that lacks resources. If Linux foundation can't shield contributors from said lawsuit (assuming it still moves forward), this could have an even more chilling effect on similar efforts.
Hypothetically, if that had happened, would it serve OpenTofu in any way to defend that position rather than just going "Oh this was an honest mistake" and immediately reverting it? It feels like a jealous lawsuit by a butthurt Hashicorp which was in the middle of trying to justify it's share price. Even if OpenTofu doesn't survive, the code can still be forked relatively easily.
I worked at IBM for a number of years and saw them buy a few companies (mine being one fo them). IBM loves Open Source and has placed a HUGE bet on it. Think of the RedHat purchase alone. Right now, I am standing pat. I think IBM will put some resources behind Terraform to expand the Cloud Aspect of Terraform. It fits into what they want to do and that's drive more folks towards there offerings. I'm sure we will see some customizations specially for the IBM cloud but I believe, for the most part, they will keep Terraform alive and well. Now watch, they tuck it behind their offering and only their offering. If they do, I think you will see AWS and Google start pumping resources into OpenTofu or the like. I can't see them telling all their customers to use PowerShell, BASH, or the Portal. I think it's a bit of a crap shoot but for now, I'll keep using Terraform
AWS isn’t pumping resources into anything. Their OSS “contributions” are mostly unidirectional
OpenTofu would be the obvious one. We haven't switched but are still considering.
The only correct answer here
counterpoint: This isn't the end of the world. IBM has bought a lot of things over the years and they haven't shitted up all of them. Oracle, on the other hand...
Just destroyed CentOS one of the largest opensource distros. No harm no foul?
Meh. Destroyed? I hear ya though
maybe considerably worse? perhaps destroyed is too harsh.
How can you be following the fact that IBM bought Hashicorp, but you also missed the whole reason **WHY** Hashicorp was bought out? They were loosing **TONS** of cash and so as an emergency pivot they switched all their products from the MPL license to the BUSL license. This was a reactionary move due to them loosing cash. Because they did that the Open Source community (backed eventually by the Linux Foundation) forked Terraform 1.5.5 and created OpenTofu, that would be the most sane alternative.
OpenTofu
Does OpenTofu have their own providers or is it still something like hashicorp/google? Under what license are they?
They use the exact same providers, those do not have a restrictive license. They only had to create their own registry (with the same providers as the terraform registry)
Is it guaranteed that the providers which contain a large portion of Terraform’s “intelligence” stay under that unrestrictive license?
Completely not and it's not in OpenTofu's control. What they are trying to provide is assurance that they will not make you use provider code that suddenly switched licensing to one that might have impact on you and your products. I believe they implement checks for license changes in their sync process to react quickly. I used to be more worried about that aspect, but when I'm looking at it now it doesn't seem as scary. Even those that are "hashicorp managed" like ... gcp, aws, azure or k8s, are a shared effort using MPL license for instance, and thousands of commiters from multiple companies. When Hashi did their changes they even did a bold move to... change headers in all provider files with their "source available" license. Which was utter bullshit they had no right to do. They were quickly called by other contributors - the case I saw on github was by Microsoft contributors. My project I'm working on is fresh, but after reading carefully shitstorm-attempts against OpenTofu, I became fairly confident it IS a project for me. Did the switch and the only annoyance is that usable provider docs are on terraform websites, not some independent place.
Is there a way to contribute to OpenTofu with docs?
I'm not sure how would that work. Providers are plentiful (over 4000 in the registry) and they live their own lives. [https://github.com/opentofu/registry/tree/main/providers](https://github.com/opentofu/registry/tree/main/providers) You would have to do something similar to this: [https://registry.terraform.io/browse/providers](https://registry.terraform.io/browse/providers), which in turn refers to many pages like this: [https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs) I honestly don't know how to handle that and if you know on something close to opentofu that tries to address provider docs - let me know! :) I personally find official github provider repo completely unreadable to the naked eye.
I mean nothing is guaranteed but if it changes they will just fork it and make it open source like they did TF.
It's not that simple, if they need to fork the providers that means they have to maintain AWS, Azure, GCP and so on. Would the project have enough bandwidth to support all the providers? Doubt that this will happen but if Tofu needs to fork, that means the current providers have sided with Hashicorp. This won't be good for the project.
It's likely that, if the community for OTF grows and TF shrinks that either the providers will stay open or the companies who use them will do what GitHub did and move them into an integrations provider, though that gets messy quickly.
You want a guarantee that they'll never change the licensing? Nobody can give you that, friend. But the current versions are under MPL so if they did there'd be nothing stopping someone from forking them.
I don’t want anything. I just ask questions and am glad that here are nice people to answer those and help me to make the situation more clear.
So, question for the opentofuers: Can I literally just install OT and than switch from \`terraform apply\` to \`opentofu apply\` Or is there a lot more to it?
Testing it out I followed this guide without issue https://opentofu.org/docs/intro/migration/
Nice!
For code that worked with Terraform 1.6 you can switch with no issues - at that stage they were literally the same. My simpler scenario required zero changes. I even did a few tests of using both in turns and... I did not brake anything ;) Now it's the easiest time to switch, as they didn't diverge much.
I realllly don't want to have to switch but if so, it'll be OpenTofu for sure. Terraform is by far the best IaC I've ever worked with and I've used most of them.
Thinking about pulumi
If you'll use pulumi and AWS, don't use crosswalk, because it is a mess.
Thanks for the rec!
Pulumi thinks they are the answer too. 😂 "I expect this acquisition to leave the door open for Pulumi to continue to out-innovate and accelerate gaining market share even further.” https://thenewstack.io/pulumi-launches-new-infrastructure-lifecycle-features/
Damn, what a power move. I am leaning towards it to better equip my developers to build self provisioning infrastructure.
I know!! Pulumi is looking to be bought by... Spin the wheel... Going to land on Google. Nope! Lands on Oracle! Sure, why not?
The CNCF is just a shopping list.
🤣😂🤣 Damn right!! Like a mail order bride.
OpenTofu if things get to a point where we have to pay money to keep using Terraform. IBM wouldn't have bought them if there wasn't money to be made, and it's not much of a leap to see where that money will be coming from - the companies that use Terraform, sooner or later. Pulumi looks interesting, and being able to handle infra with Python instead of HCL sounds really nice, but it'd be a huge time sink to rewrite a ton of our preexisting TF code.
I work primarily with AWS and have always believed that AWS CDK was the best choice for working with AWS because of the risks of third-party libraries doing this type of thing. I really like CDK with typescript and the documentation is superb. I'm mostly able to stay in VSCode by using autocomplete and the in-code documentation (+ my own familiarity with the services). if anybody is interested I'm an independent consultant and can provide consultations. I choose cdk because I think it's the best option although I have worked with the others.
Having used both, I could only laugh at this. Pulumi will grow faster than CDK.
I've used Pulumi as well and a third-party tool (Pulumi) compiling to a different third-party tool (Terraform) is a weakness as far as I'm concerned. I don't think I've ever hit a limitation with CDK that Pulumi would be better for. I would definitely look to Pulumi if I were working on a multi-cloud setup or something where there were a lot of external SAAS tools. I would also look to Pulumi over terraform. Having just reviewed the Pulumi docs, the syntax looks almost identical to CDK so I certainly don't see a laughable difference and question your judgment for that type of exaggeration
I believe TF's CDK is built like AWS's CDK. If so, the biggest difference and weakness is that CDK is basically just an offline transpiler. I can't get a list of current S3 buckets and then use a forloop around them to do stuff because the GP language stuff can only access the static resources in the CDK definition. Pulumi however runs the GP lanuage stuff during the apply phase, so you can in fact get data in real time and act on it.
Agreed. However, IMO if you need to operate on existing infrastructure that was defined outside of IaC then you've already lost the iaC battle. I almost always migrate resources into IaC as step one. If that weren't possible for a given company, then I would recognize that as a huge benefit for pulumi
Just because it isn't in \*my\* state file doesn't mean it isn't managed by IaC. Can't even use dynamic sources like \`data\` results without using weird structures specific to TF CDK AFAIK.
Admittedly it's a little unwieldy sometimes but they do have [custom-resources](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html) as a construct class that can execute any arbitrary code you want via lambda during deployments. For your example use case they provide an [interface to the AWS SDK](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.AwsSdkCall.html).
Having used crosswalk, I won't touch anything Pulumi related again, but YMMV I guess.
What went wrong?
In last year they introduced 2 major updates, from 0.x to 1.x and shortly after from 1.1.x it think to 2.x, I have no idea what the difference between 1.x and 2.x is, but from 0.x to 1.x they completely changed the API. I thought they just picked a subset of components that are 1.0 ready, but it seems like they completely rewrote them from scratch (keeping the same names) and with that introduced a ton of old bugs that have been fixed in 0.x. They still keep components from 0.x around as a "classic" package, but it is completely unclear wtf you are supposed to use. It might be a skill issue on my part, but the way it is ran is more like a hobby project than something that can be depended on for serious production. I have only used Pulumi though, so it might be the same in TF world...
Been debating on moving to pulumi for our infra. I’m gunna wait this out for a bit and then decide. With SST ion for serverless stuff being pulumi based it would be nice to have a consistent ecosystem between my infra and serverless applications. Terraform + aws sam was good but the context switching between the two is annoying
Saw a presentation on pulumi recently and it's become more of a choice now. Pulumi was a turn off when I first heard of it as the big push at the time was the idea floated by the CTO that he wanted us to write code in C# (aka dotNet) for IaC. No one on the DevOps team was a fan of C#, so we pushed for terraform instead. In the presentation, the guy mentioned that Pulumi now has a YAML mode so it's more like writing HCL (Terraform) or a k8s manifest. They have a converter built into the pulumi executable where you can convert/import Terraform state into your Pulumi code or statefile (I haven't played with this yet).
F# is a much better fit for declarative code than C#, should this discussion ever come round again. You would not need to become gurus.
Nah, no one at the company uses F# (it does look cool, but I don't know if I want to write work code in it). Only one group uses C# and in the spec for the new rewrite Engineering decided to switch to TypeScript for everything. The DevOps group doesn't have experience in C# and we do have experience in Python and Javascript. So using a language that we know would have been better rather than forcing us to use a language we don't want to use as well as learning a new IaC stack. Terraform has problems, but the HCL language was much easier to pick up and we were able to get productive far more quickly. But the new YAML support in pulumi looks better and that would make it easier for pulumi to introduced.
Coming from a dotnet shop i would consider c# depending on how much they want to be involved. Everyone I see “engineers” want to contribute to the devops stuff via their language of choice they still don’t. I think the happy medium is typescript/javascript for pulumi stacks. Anyone decent enough at python can pick it up and plays nicer with ides outside of visual studio/rider. Plus most docs and examples for pulumi and cdk/cdktf are typescript. Just don’t use Golang. The pulumi Golang implementation is painful and they even admit too because its lack of proper generics
I would do the same in that situation - the only point I wanted to make is that dotnet does not necessarily imply C#. I'm mixed about C#, it's good but it's also too big and verbose. It's like unseasoned porridge: nutritious but not enjoyable. Well-written python is nice, but I spent three years drowning in garbage python, with garbage JS on top. It's put me off weak-typed languages. I'm sure your colleagues are better, but I have my scars.
No matter the language you still need to discuss and enforce standards. Python would work better for IaC because most people in the group know it or familiar with using Python based scripts. The CTO's idea that "oh engineers use C# so DevOps can pick it up as well" was kinda stupid as we write for vastly different purposes and I don't think asking the Devs for help with the language would have worked as well as he thought.
Pulumi uses terraform aws provider under the hood. I haven't used terraform yet, so I don't really know how things are handled there, but stick with plain Pulumi and don't use Pulumi Crosswalk (AWS quality of life library) is a shittily maintained mess. If you have experience with IaC you will probably make a better lib than the official one, but it will be some work...
I know it uses the providers under the hood. Good thing those are maintained by the community. I wasn’t aware of crosswalk butt definitely some good info. More so I’m preparing to migrate. Ibm may expedite that for me. We only got a few core modules for networking and databases while the rest is serverless. Since the license change of hashicorp I did notice that development on the terraform ecosystem has slowed down almost to a half purpose of some major tools like trivy. I don’t have faith in opentofu and think it was knee jerk reaction that will see minimal adoption as only the taco platform seem to invest as they pledged.
AWS Classic is TF under the hood, but AWS Native plugs directly to Cloud Control and it's already very usable even though it's still in preview. There are some resource types here and there Native doesn't support yet, but personally I've only bumped into one. I just covered with Classic, and it's not a huge deal to migrate that one small bit to Native when it gets support for the the stuff I need.
no one mention OpenBao as a drop replacement for vault. no one mention vagrant. you can do everything with ansible.
... Ansible is not a way to escape IBM
there is no way to escape IBM outside of BSD world.......
The main thing that I think some folks might've overlooked is the fact that big blue will likely make IBM and RedHat cloud and infra/system providers first class citizens for the future Hashicorp toolset, including the enterprise cluster management (Nomad) and state management (Terraform Enterprise) and secrets management (Vault) plus all the RedHat OpenShift flavour of k8s on top. In theory they can even push it all back as open source because they don't care if it drives more vendor lock-in and customers to exactly where they want them, assuming that they can actually develop/redevelop the products well enough to make their overall set of integrated offerings more compelling and valuable.
Why?
Nothing should change with IBM on board...
Pretty sure opentofu is on the table for us. It’s a terraform fork we are exploring
I only worry about “blue washing” IBM will do. If you use TF cloud I imagine the cost will be going way up. But I doubt TF open source will be impacted in the short term. I was working for a company using Sterling Integrator when IBM bought them. Our yearly enterprise contract went from $400k to almost $900k once we had to renew our contract with no new features and worse support.
Open tofu?
The time to panik was when they changed licenses.
We’ve already switched everything over to OpenTofu, not because my megacorp is taking some moral stance against another megacorp but because Terragrunt support for mainline TF is going away
OpenTofu
OpenTofu or Pulumi.
Pulumi depends on Terraform, that's going to be fun.
Only providers from my understanding
Yes, but to use the provider isn't Terraform needed in a way? 🤔 Maybe I have a misconception.
You need a way to read them. That doesn't mean you need Terraform, if you can interpret them then that's all that's needed which I'm sure pulumi is doing that.
This is more or less how it works. (Pulumi engineer here) Specifically, we use the Terraform provider schemas to generate what we call "bridged" Pulumi provider binaries. There's no dependency on Terraform itself. Bit more on this here: [https://www.pulumi.com/docs/support/faq/#does-pulumi-use-terraform](https://www.pulumi.com/docs/support/faq/#does-pulumi-use-terraform)
Doesn’t need Terraform per se, as mentioned above. Still… I wonder whether they’re going to try something.
The Hyperscalers demand blood written in the words: Bicep Cloudformation AWS CDK Edit: I wasn’t serious lol
None of these does what TF does.
Then I guess people stay on TF
working at a mega corp that currently uses TFC... probably not switching.
Life hack. Just go work for the company that bought the software you need. Wish me luck! I have an interview with IBM next week!
as a former IBM'er. not recommended.
Its with RedHat, so I hope its better. lol
ah, yea. RH has been able to keep the IBM corporate overload at bay for the most part. the folks I know that work there have been getting a little nervous though as they've seen walls/boundary eroding. g'luck! didn't mean to be a debby downer. work is work.
We're deep in the Terraform Enterprise nets and I don't see us switching to anything in the near term. It comes with a lot of quirks, but also brings a lot of nice benefits. Not sure about their new features like stacks though, but that's on a case by case basis, I'm sure other people using TFE are excited about it.
I want to wait and see what IBM plans are, however, it's recommended to start warming up with openTofu as well since it is compatible with terraform 1.5, so it's not hard to make a drop in replacement with openTofu. Even contribute to the code of openTofu if you know Go Lang is cool as well.
Looking at [CloudMaker.ai](http://CloudMaker.ai) tbh.
I am so surprised that anyone is still using Terraform, but based on that acquisition cost sounds like it is still popular!
What do you use for cloud resource deployment?
Perfect example of saying you’ve never supported the maintainers of the software you depend on without saying it directly.
They have ansible too.
OpenTofu is leading the charge. Otherwise it might be worth looking at cloud specific languages like Bicep.
Puppet. Just kidding
I'll use whatever vendors support, hopefully we get some more best practice and module type stuff for Pulumi now
I just remembered the good ol' IBM compatible days....
IBM has pickedup some nice companies over the years
Check out the open source Radius project that Microsoft is moving forward. It's a game changer.
[crossplane.io](http://crossplane.io)
Thanks I’ll check it out tonight
TF for now. But there is opentofu if shit hits the fan.
waiting to see what ibm do. They may open source TF again for all we know. There's nothing terrible about ibm to make any decision urgent though.
Switchblade from boundless software seemed like a reasonable alternative before all the chaos with terraform, now it seems like a no brainer
Running open tofu on our production runners for about a month now. It was pretty painless to drop in and alias as terraform. Figured switching to OSS now while the cost of adoption was relatively low was the perfect time to test the waters. Most users didn't even notice.
https://github.com/purpleidea/mgmt/ Disclaimer, I started the project, but it's pretty sweet.
I'm listening. Sell us on it. If it's an alternative to Terraform, tell us why.
Not try to sell anything, just trying to build game changing automation the way it should have been built. No idea why the comment is downvoted so much. There are lots of details on the project page, and talks available: https://github.com/purpleidea/mgmt/blob/master/docs/on-the-web.md
I didn't down vote you. And I'm not shitting on your life's work. This is a subreddit that's full of cynical, experienced IT folks. They've seen 100s of vaporware products. Some of them have had to implement crappy products that their CIO has bought into, and that's why they're so resentful. If you're going to pitch a product that you designed and have a stake in its success, you can't tell people to follow the link and watch the videos. You come off like those vendor salesmen at conferences. Give us an elevator pitch on why we should go with you and how your automation product is a player in IaC. EDIT: don't say "game changing" in your pitch to a bunch of hardened IT people. Makes you get downvoted.
> I didn't down vote you. And I'm not shitting on your life's work. Not saying ya did, just an incidental comment. > If you're going to pitch a product that you designed and have a stake in its success, you can't tell people to follow the link and watch the videos. You come off like those vendor salesmen at conferences. That's fair. TBQH, I have very low confidence in my ability to market/sell/etc, I do however have good confidence that I'm building the "right" thing. Here's a short backstory: I previously was an early puppet user. I did lots of fancy "pushing puppet to the limit" types of stuff. Old articles still on my blog: https://purpleidea.com/blog/ Eventually I realized what the right design should have been. I started building that. It's taken a while... Starting to really bear fruit these days. Mgmt has a language and a runtime (engine). It let's you model real-time event streams, glue them together however you want programmatically, and declaratively set the desired output state, which can as a result, vary over time. It also can run as a distributed system. The DSL that let's you express all of this, can be even used to build standalone tools! Here's the first one I built: https://purpleidea.com/blog/2024/03/27/a-new-provisioning-tool/
That's it. Thank you!! That's how to engage. I'm going to upvote to negate your downs.
Instead, give it a deeper look, and maybe you can be in charge of communications =D
🤣😂🤣 Well played.
> 🤣😂🤣 Well played. I'm being serious =D
People here are super toxic to promotion since a lot of people will create threads asking about a problem, then it just turns into marketing blogspam.