DEV Community: Jason Kuehl

How Broadcom Turned VMware Into a Hostage Negotiation

Jason Kuehl — Tue, 09 Jun 2026 14:42:34 +0000

Broadcom Should Be a Warning to Every Software Company

Broadcom serves as a public example of what happens when you completely aggravate your customer base. And the horrible thing is, the people who are really affected by this are not the enterprise-and-beyond companies. It's small, medium, and large businesses that downsized.

VMware has been the tried-and-true virtualization platform in pretty much every company. The pricing was good. The support was good, and the virtualization stack is solid. That's still true today, with versions 8 and 9 slowly being adopted by larger corporations.

What Broadcom Actually Did

When Broadcom acquired VMware in November 2023 for $61 billion, the largest enterprise software acquisition in history, the IT industry didn't hold its breath. We knew from Broadcom's past actions what was coming. What followed was one of the most aggressive and, frankly, predatory pricing overhauls I've ever seen in enterprise software. We expected pricing to change, but we didn't expect this nonsense and greed.

Here's what changed:

Perpetual licenses: gone. As of January 22, 2024, Broadcom ended supporJanuary 22etual VMware licenses. Everything is now subscription-only, with 1-, 3-, or 5-year terms. If you're on a perpetual license today, your support contract expires by October 2027. After that, you either subscribe to the new pricing or get out.

Product portfolio: gutted. VMware's catalog went from roughly 8,000 SKUs and 168 bundles to essentially two products: VMware Cloud Foundation (VCF) and vSphere Foundation (VVF). Individual products like standalone vSAN and NSX? Discontinued. You get the bundle whether you need everything in it or not. That's not simplification; it's a forced upsell.

Pay-as-you-go: dead. Three-year contracts only. No flexibility, no options.

72-core minimum purchase. Starting April 10, 2025, the minimum license order will increase from 16 cores to 72 cores per product. Running a single-socket server with 8 cores? You're paying for 72. A 3-host cluster with 36 total cores? Still 72. This hits small and mid-size organizations the hardest—the very people who can least afford it.

20% late renewal penalty. Miss your subscription anniversary date, and Broadcom charges a 20% surcharge on top of your first-year subscription cost. It's pure pressure to keep you locked in and afraid.

Opaque, inconsistent quoting. There is no public price list in any meaningful sense. Two organizations with identical hardware footprints can get quotes that differ by tens of thousands of dollars, with no explanation. I'll get into this more below, because this one really gets me.

What Makes Broadcom a Scumbag Company

You cannot get reliable pricing. And there's probably even a law against what they're doing. But to me, it's downright scumbag maneuvering.

If you talk to someone with an identical setup — same core count, same node count, same everything — the price they got and the price you got will likely be different. In Broadcom's world, none of that matters because they want you to have a minimum of 72 cores, regardless of what you're actually running. The price for a four- or five-node environment can vary among customers from $50,000 to $85,000, and we don't have an explanation for the gap.

You can't budget for this. You can't plan for this. If you want to know what your renewal will cost, you'll receive a quote within 2–3 months, and you'll have 30 days or less to accept it. That's not a business relationship — that's a hostage negotiation.

The Real Numbers People Are Seeing

The inconsistency isn't just anecdotal Reddit complaints. It's been documented across customer segments:

Opening quotes of 2x–5x are common. With aggressive negotiation and a credible migration alternative, some customers have gotten down to 1.3x–2x —, but that takes months of leverage-building, alternative-vendor quotes, and sometimes even threatening to leave entirely. Most small and mid-market shops don't have the time or resources to run that play.

The list price for VCFist is roughly $240–$250 per core per year, based on Q1 2025 community-verified quotes. Your negotiated rate will vary — and that's exactly the problem. There is no standard. There is no fairness. There's whatever Broadcom thinks they can get from you.

And it gets worse: there are documented cases in which Broadcom quoted the above-published list price to customers they felt they could pressure. That's not a pricing strategy — that's extortion with a software license attached.

The Lawsuits and Regulatory Fallout

This isn't just grumbling on forums. There are formal legal and regulatory actions underway:

AT&T sued Broadcom in federal court, alleging price increases of up to 1,050%. The case settled out of court in December 2024 with undisclosed terms — but that filing is a public record, and the numbers are in it.
Germany's VOICE IT customer association filed a formal complaint with the European Commission.
ECCO (European Cloud Competition Observatory) filed an action with the General Court of the European Union challenging the EC's initial approval of the VMware acquisition.
Cease-and-desist letters were sent to organizations still running perpetual licenses without active subscriptions. That's right — Broadcom is threatening customers who are running software they legally own.
Broadcom sued Siemens' US operations as part of a broader legal pressure campaign against large customers who won't roll over.

ECCO called Broadcom's financial model "legally and ethically flawed" and stated outright that current practices appear to violate EU competition regulations. Germany, the EU, and multiple customer advocacy groups are all pushing back simultaneously. That doesn't happen unless something is genuinely broken.

The Industry Consensus
We've agreed as an industry: Broadcom does not want us — enterprise customers with smaller workloads — using their platform. That's abundantly clear.

The platform was built on customer service and stability. I'm in the same boat — I ran VMware for years in my homelab and professionally before switching to Proxmox after Broadcom made it obvious they didn't want mid-market customers. The migration wasn't painless. Exporting VMs as OVAs, tweaking network drivers, relearning storage and backup concepts — it takes real time. But having full control back without a predatory vendor holding your renewal hostage? Worth every hour.

I'm not alone. Alternatives like Proxmox VE, Nutanix, Microsoft Hyper-V, and Azure Stack HCI are seeing massive adoption spikes directly because of Broadcom. RunZero noted a significant increase in the number of deployed Proxmox VE systems over the last year. vSphere 7 reached the end of support in October 2025, forcing even more organizations to make a decision they'd been delaying.

The 72-core minimums, the forced bundles, the late renewal penalties, the opaque quoting — none of this is accidental. It's a systematic squeeze on the mid-market: the organizations with the least negotiating leverage, the tightest budgets, and the fewest resources to run a migration project under time pressure.

Broadcom built this on the backs of customers who believed in VMware. The platform was built on trust and stability. They burned it for margin.

I honestly hope it comes back to bite them.

BLOG - The Self-Hosting Balancing Act

Jason Kuehl — Wed, 27 May 2026 12:10:49 +0000

Self-Hosting Is A Balancing Act

Self-hosting is like a counterweight scale. You weigh your options when deciding whether to self-host something. That scale will look drastically different depending on the person and the environment they have set up, and it can change as people gain more knowledge.

One side of that scale is reliability, and the other is stability. In a home lab context, stability is a system's ability to remain steady and return to its normal state after a disturbance. For example, if you run an update on your home media server and something breaks, good stability means your server can recover and work as expected again without too much hassle. Reliability, on the other hand, is the probability that the system will consistently perform its intended function without error over a specific period (per M$ documentation). Think of reliability as making sure your media server is always up and running whenever your family wants to stream a movie, week after week, with very few interruptions.

When you look at software to host to replace other services, let's use web hosting as an example, the easy choice to start. Maybe the choice to self-host is due to cost, data control, or security. Or maybe you just don't care and want to, just to learn.

It all comes down to how much risk you are willing to accept with self-hosting, and what level of reliability you need. To make these choices clearer, here's a quick step-by-step approach I use when deciding between different tools or setups:

Define what you want to host and your goals (for example, personal use, learning, or production).
Consider how critical the service is: Would it be a big problem if it went offline? How much downtime can you tolerate?
Assess your technical comfort and available time. Are you ready to troubleshoot breaking changes, or do you need something simple and stable?
Research stable, reputable options that fit your needs (for example, using nginx or Apache for a web server if you want reliability and stability).
Think about your environment: Do you want to try containerization with Docker Swarm or Kubernetes? Or are you ready for more advanced setups like a multi-node Proxmox cluster?
Finally, balance the temptation of new technologies versus the trustworthiness of established solutions if you want fewer headaches.

The options are endless, and each decision you make will shape how you build things.

It all comes down to this: after you figure out all that, now risk. How mad will I be if I lose this data? How upset will I be if I can't access this web server? Will my family disown me, or will my wife and kids be upset? The different things that can be run will always have distinct risk factors. Which again goes back to you weighing the options of running these different services.

To make this even more practical, here is a simple risk assessment checklist you can use before self-hosting a service:

How critical is this service or data to me or others using it?
What would happen if this service went offline for an hour? A day? A week?
What is the impact if some or all of the data is lost?
Could downtime affect my work, my family, or anyone else who depends on it?
Do I have a recent backup that I can actually restore from if things go wrong?
Will I be able to resolve issues quickly, or will lack of access create major headaches?
Are there any legal or compliance concerns with hosting this service or storing this data myself? Going through these quick questions before setting up anything new can save you a lot of frustration and help you decide if the risks are worth the rewards.

At the end of the day, you might not care about any of this, but it becomes a time to do. But for the love of God, please have a good backup strategy for the data you actually care about that doesn't live within your own self-hosted environment.

Science Fiction Was the Roadmap

Jason Kuehl — Wed, 06 May 2026 12:41:30 +0000

I don't think people realize how much Star Trek has prepared us for using AI as we are using it today.

My interaction with Co-Pilot, Gemini, or Claude, if you look at it, is very similar to how they're using AI in Star Trek. It's just a conversation with the computer to get outputs of the things that they're looking for.

You can even see how interacting with the computer in Star Trek changed over many generations, from simply reading fundamental data to providing output to what we have now in TNG, which could be construed as vibe coding if you consider the holodeck.

When I say "vibe coding," I mean the process of describing what you want in natural language, focusing on the intended feel or high-level concept rather than writing explicit code instructions. This approach is sometimes controversial because some people feel it yields less precise or predictable results, and they worry about a lack of control over what the AI generates.

The holodeck is a magical place that allows people to just talk about what they want, and it generates a vibe, which is what a lot of people are hating on vibe coding right now. However, I have been loving it for its ability to generate the things I've always wanted to create. It's literally opened up a new world for me to build the silly things I have always wanted. Which, if you think about it, is the holodeck.
The holodeck was also used for trading, teaching, and tactical purposes. But those were more finely tuned and highly refined programs. For a lot of us, we're starting to use DSLs with AI to make sure the output from our AI of choice builds exactly what we're looking for for those specific purposes.

(A DSL, or domain-specific language, is a specialized type of programming language designed for a particular task or field. In the context of AI, that could be something like a language tailored for creating educational simulations or tactical training scenarios, making our interactions much more precise and aligned with the needs of the user.)
You even have hallucinations in Star Trek. There have been many episodes of DS9 or TNG where they're given inaccurate data.

For example, in the TNG episode "The Naked Now," the Enterprise's computer provides misleading information due to a contaminant affecting the crew and the ship's systems. Similarly, in DS9's "Civil Defense," the station's computer triggers an outdated security protocol, causing chaos for the crew based on faulty or obsolete logic.

In these cases, the computer straight up has the wrong data, and the people requesting that information are seeing it as a hallucination because they say the data is incorrect.

Within this whole world, you still have human-in-the-loop control. It's still a person, at the end of the day, who's making those final decisions. Sure, the computer is doing all the heavy lifting, but the person is still making the fine-grained decisions about how they want that to look, work, and interact with others.

This is not the first time Star Trek has done this. Throughout the series, Star Trek has predicted and even inspired the creation of a wide range of technologies.

Here's a look at some of the biggest ones, when Star Trek introduced them, and how long it took for reality to catch up:

Communicator → Flip Phone — Introduced in TOS (1966). Motorola's StarTAC flip phone arrived in 1996, a 30-year gap.
PADD → Tablet / iPad — Introduced in TNG (1987). Apple's iPad launched in 2010—a 23-year gap.
Universal Translator → Google Translate — Introduced in TOS (1966). Real-time spoken translation became practical in the 2010s. ~50-year gap.
Voice-Activated Computer → Siri / Alexa — Introduced in TOS (1966). Siri launched in 2011, Alexa in 2014. ~45-year gap.
Viewscreen → Video Calling — Introduced in TOS (1966). Skype launched in 2003, and Zoom went mainstream in 2020. 37–54-year gap.
Automatic Doors — Introduced in TOS (1966). Became commercially common through the 1970s–80s. Nearly simultaneous.
Holodeck → VR / AI Environments — Concept originated in 1968, named and featured in TNG (1987). Consumer VR arrived in 2016; truly immersive AI environments are still emerging. Still not fully there.

These examples show how Star Trek has consistently anticipated future innovations, making its vision feel as relevant now as it was decades ago.
Also, within Star Trek, the computer is not a replacement for anyone. It is a tool used to extend their knowledge and help them become better people. You still have all these people running engineering. You still have all these people running hydroponics and so on, running tactics and making decisions.

I think if Star Trek has shown us anything, it's that yes — there are definitely ways to misuse AI, and people will do that — but the vast majority will use it as a tool to better themselves.

Of course, Star Trek doesn't shy away from showing what can go wrong, either. For example, episodes like "The Ultimate Computer" explore what happens when AI systems, such as the M-5 computer, are given too much control, leading to unintended and dangerous consequences.

In the real world, we've already seen issues such as biased outputs, loss of privacy, and reliance on flawed data when using AI systems. By highlighting both the positive uses and the potential pitfalls, Star Trek encourages us to think critically about how we develop and interact with these powerful tools.