Don't ask Microsoft to do it all

dotnet/core#10448 was opened, and it has the .NET community debating this. Again.

The issue: "Enterprise concern: .NET LTS support window too short for upgrade and adoption cycles." The dev who opened the issue is on a team that runs about 5 million lines of code on .NET 8. They are nearly done moving it to .NET 10, and that migration took roughly seven months.

Their problem is timing. .NET 8, an LTS release, and .NET 9, an STS release, both go out of support on the same day, November 10, 2026.

The .NET cadence makes new .NET 8 deployments awkward to justify right now (you should be on .NET 10 now) and, in their words, complicates "customer onboarding and procurement discussions." The issue asks for a longer LTS, paid extended support, and more overlap between releases.

tl;dr The instinct is to ask Microsoft to carry .NET longer. A healthy open source platform does not lean on a single vendor for its whole lifecycle. .NET is now built and shipped by multiple vendors, secured by a multi-vendor group, and supported past upstream end-of-life by third parties. That is what a mature open source ecosystem looks like. It is the shape Java took when it stopped relying on Oracle for everything.

I have a stake in this and a particular vantage point. I lead Never-Ending Support (NES) for .NET at HeroDevs, so post-end-of-life .NET is literally my job. Before that I worked at Canonical on Ubuntu and at SUSE on Rancher. These companies show up below. These are my personal thoughts, and I am not sharing anything that is not public.

I have argued that open source won at Microsoft. What comes after winning is the healthy, multi-vendor maturity of open source every important open source project grows into. .NET is in the middle of that now. #10448 is a snapshot of the growing pains.

The .NET support cadence is nothing new

.NET ships a new major every November. Even-numbered releases are LTS, supported for three years. Odd-numbered releases are STS, supported for two years.

The November 2026 EOL date for .NET 8 and .NET 9 in #10448 is not Microsoft shortening a support window. It actually lengthened it. In late 2025 the team extended STS from 18 to 24 months starting with .NET 9, moving its end of support from May 2026 to November 10, 2026, the day .NET 8 retires. .NET 10, an LTS release, runs to November 10, 2028.

This annual-release, dual-track model is not unusual or hurried. It is what open source projects have landed on, independently, over and over:

• Node.js ships a major every six months, promotes even-numbered lines to LTS, about 30 months each.
• Angular does two majors a year, 6 months active plus 12 months long-term.
• Vue maintains the current major and marks older majors EOL on a schedule (Vue 2 ended December 31, 2023).
• Kubernetes ships three minor releases a year, roughly 14 months of patches each.
• Java, through OpenJDK, ships every six months with an LTS about every two years.

A predictable yearly train, an LTS lane, an STS lane. The friction enterprises feel here is the friction of every modern open source release cycle, it is not unique to .NET.

And every one of those ecosystems solved it the same way. Not by leaning harder on the upstream vendor. By adding more vendors around it.

.NET is more than Microsoft now

Microsoft is the upstream. Microsoft is not the only place you get .NET. Many shops already run someone else's build.

Red Hat builds and ships .NET in RHEL and CentOS Stream.

Canonical publishes .NET for Ubuntu as deb packages, snaps, and Chiseled Containers. Microsoft handed deb packages off to Canonical: As of Ubuntu 24.04, Canonical produces the packages. Microsoft no longer publishes .NET to its own feed for newer Ubuntu releases.

IBM maintains .NET for their IBM Z mainframes, the work that first brought .NET 6 to IBM Z and LinuxONE with Red Hat, Microsoft, and the Mono community.

This is how Linux works and how Java works. One upstream, several vendors building, optimizing, and supporting their own distributions for their own platforms. Nobody finds it strange that you can get OpenJDK from Eclipse, Amazon, Azul, Microsoft, or Red Hat. The same is now true of .NET.

Multi-vendor maturity

A big sign that .NET has reached multi-vendor maturity is the .NET Security Group. Microsoft expanded it in late 2025 as a coalition of organizations that distribute .NET, so CVE fixes reach the widest set of users at once. Members get CVE information ahead of public disclosure and ship patched builds alongside Microsoft's monthly Patch Tuesday. The group includes Red Hat, IBM, Canonical, and HeroDevs.

A customer on RHEL, a customer on Ubuntu, a customer on a mainframe, and a customer on an end-of-life version from HeroDevs all get protected the same day.

Java has had this for years. The OpenJDK Vulnerability Group runs the same embargoed disclosure across its vendors. Shared security across multiple vendors is what a grown-up ecosystem looks like.

There is life after end-of-life

Back to one specific ask in #10448: paid extended support. Where does an enterprise find more runway when November 2026 arrives before the migration does?

It buys it. Often from a third party. This is the part of the ecosystem I work on.

At HeroDevs, NES for .NET is a drop-in replacement for end-of-life .NET that keeps backporting security patches for CVEs when Microsoft's .NET support ends. We have done it for .NET 6 since it went EOL in November 2024, and NES for .NET 8 is production-ready now, ahead of the November 2026 deadline, so the handoff is a planned step, not a scramble. Because HeroDevs sits in the .NET Security Group, those patches track the same Patch Tuesday as everyone else's.

The point of NES for .NET is not to dodge migration. The team in #10448 should finish moving to .NET 10. The point is to unhook the security clock from the migration clock, so a 5-million-line codebase moves on a schedule the business can execute given multiple priorities, large codebases, and stretched .NET teams.

That is the runway the issue is asking for.

HeroDevs provides it.

This is what every mature OSS ecosystem does

Multiple distributions, multi-vendor support, coordinated security, third-party support after end-of-life. None of it is new. It is the path other ecosystems already walked:

• Java is the closest parallel. OpenJDK is the shared upstream, and you can get a production-ready, verified builds from Eclipse Temurin, Amazon Corretto, Azul Zulu, the Microsoft Build of OpenJDK, the Red Hat build of OpenJDK, IBM Semeru, BellSoft Liberica, or SAP's SapMachine. Several carry extended LTS well past the free upstream window: Amazon supports Java 8 into 2030 and Java 11 into 2032. Azul offers patched builds back to Java 6. The Java community does not depend on Oracle, and after Oracle's 2023 move to per-employee pricing it depends on Oracle even less. That was not a crisis. It was maturity.
• Linux has had this for decades. RHEL has a family of downstream rebuilds in AlmaLinux, Rocky Linux, SUSE Liberty Linux, and Oracle Linux, and OpenELA exists to keep enterprise Linux source open and multi-vendor.
• Kubernetes is consumed almost entirely through vendor distributions: Red Hat OpenShift, SUSE Rancher, Amazon EKS, Google GKE, Azure AKS, several selling extended support past the upstream window. When the community retired Ingress NGINX in March 2026, the controller fronting a huge share of clusters, a third party stepped in: HeroDevs ships NES for Ingress NGINX as a patched drop-in replacement, so teams keep the lights on while they move to Gateway API on their own clock.
• Spring pairs a fast upstream cadence with commercial extended support from Broadcom for older lines, alongside HeroDevs NES for Spring.
• Front-end and runtimes age out and stay alive the same way. HeroDevs offers NES for AngularJS, Angular, Vue 2, Vuetify, Bootstrap, and Node.

Different communities, same shape. One upstream, many vendors, coordinated security, and someone to call when you need more time than the free window gives you.

You're not wrong

The dev on the team who posted #10448 is not wrong to want a longer runway. They, and many in the .NET community, are looking in one direction for it.

But the extended runway option already exists, built from the coordinated work of the .NET Security Group and third-party post-EOL support.

This is all a feature, not a bug.

As open source .NET matures, it cannot rely on Microsoft for everything. The good news, and the whole point, is that it no longer has to.

Open source .NET grew up.

Disclosure, once more: I work at HeroDevs on NES for .NET, and I used to work at Canonical and SUSE. The multi-vendor case stands on its own, but weigh the source.