The .NET OSS Relicensing Panic Is an Incentives Problem

Relicensing and OSMF fees are the predictable outcome of misaligned incentives between maintainers and commercial users, but there's a way to fix it.

• The Impact of the Open Source Maintenance Fee
• Protecting Yourself from Third Party OSS
  • Fork It / Maintain It Yourself
• Front-Running Relicensing
  • Incentives Matter
  • When Projects Lack a Business Model
• Get Ahead of the Bill

A couple of popular open source projects in the .NET ecosystem, first Verify and now Polly - have adopted (or are thinking about adopting) the Open Source Maintenance Fee to support the long-term development of their projects.

What follows is the popular cycle of rancor, procurement rage, sad /r/dotnet users, and another popular .NET library monetizing the library itself to sustain the OSS project.

Things are different than when I first started writing about IdentityServer relicensing five years ago.

IdentityServer has been very successful commercially since relicensing and everyone can see it, serving as an inspiration for many other maintainers.

Maintainers are no longer intimidated by u/CheetoDustedFatPig or u/DisgruntledMidCoder expressing public disapproval on /r/dotnet. The .NET Foundation is absolutely powerless to stop its own projects from leaving and relicensing¹.

In short, what we have here is the classic incentives problem that has always faced OSS maintainers and their commercial users.

What’s different this time is the maintainers have a proven go-to-market strategy for essentially sticking a loaded gun into the mouths of corporate users and demanding that they pay or face the consequences.

There’s a way to put a stop to the cycle of relicensing, but will anyone listen?

The Impact of the Open Source Maintenance Fee

The OSMF isn’t quite the same as relicensing, a subject I’ve covered in the .NET space before, but it’s adjacent to it and it impacts users in a similar way. The difference comes down to what each mechanism actually touches.

In other words, relicensing changes the deal on both the code and the artifacts you ship, while the OSMF leaves the open source license untouched and simply attaches a convenience fee to consuming the publicly available binary.

With all due respect to Rob Mensching, the creator of OSMF and a friend of mine - this is a legal distinction, not a practical one for consumers of open source. If you can’t use the public binaries, you’ll need to build and host your own.

It’s not the same level of commitment as maintaining a fork of the pre-license-change project (which you’d need to do with relicensing) but it’s still a logistical and operational hurdle for adopters.

In either case, relicensing or adoption of the OSMF, the consequence is the same: you can’t consume the publicly available binaries without some remuneration to the maintainers if you’re a commercial user of the software.

Protecting Yourself from Third Party OSS

I wanted to highlight this comment from a redditor that I think is representative of how many consumers are looking at third party open source in the .NET ecosystem right now:

What makes arguing about the OSMF somewhat ridiculous on the part of most redditors is how little money the maintainers are asking for - a $20 per month donation via GitHub Sponsors. Really? If you’re making six figures a year working for BigCo and you’re nervous or scared about talking to your company’s idiotic procurement bureaucracy, just pay it yourself and move on.

But since it’s 2026 and we can’t do sensible things, let’s go through all of the trouble of:

1. Creating our own parallel package delivery and build infrastructure for third party packages;
2. Maintaining our own sync cadence with the upstream - or stay on pinned packages forever and ignore security updates; and
3. Documenting and institutionalizing this for our organization to operate in perpetuity.

All to avoid having to spend $20 a month.

Or we can go down the road of forgoing third party OSS entirely and become the baying retards who beg Microsoft to solve our problems for us. Given that:

1. Hope is not a strategy and
2. Microsoft can’t do every given thing you ever could possibly need

This is going to fail.

Fork It / Maintain It Yourself

There’s a meme, trafficked mostly by people in the business of selling AI coding tools, that we’ll soon just have Claude or Codex write our dependencies for us instead of pulling packages off a public registry. For a self-contained utility, sure - you can probably pull that off. For a UI framework or a distributed system, I’m deeply skeptical, and for two reasons.

First, it isn’t even what the models do. LLMs love dependencies - they lower your total cost of ownership and the models are trained on how to use the popular ones. We see it in our own Akka.NET install data: AI is driving people toward the established libraries, not away from them.

Second, and more important: an LLM doesn’t have any long-term horizon for planning and maintaining an open source project - humans still need to do this.

I’ve maintained Akka.NET for thirteen years, so of course I’ll tell you it’s hard to replace - but here’s a story that’s true whether you trust me or not.

I spent seventy-plus hours last year chasing a single bug in Akka.Cluster.Tools that had shipped in every version since 2015 and could silently spawn two copies of the same cluster singleton, quietly corrupting your data. F5 debugging didn’t find it; unit and integration tests didn’t reproduce it. It only surfaced inside a chaos experiment I built specifically to provoke it - Docker, Kubernetes, and distributed tracing wired into the framework’s internals - and that was just to see it happen.

No downstream consumer is putting in that kind of effort on their own fork, and you’re certainly not prompting your way to it without deep knowledge of the internals and the infrastructure to reproduce the failure.

Large language models aren’t a substitute for determined, experienced people who are motivated to solve a problem for their customers. Maintainers aren’t fungible - sure, someone can spin up a fork, but are you going to still be working on it in ten years?

You’re not escaping the dependencies that matter. That’s exactly why it’s worth paying to have a say in how they’re run.

Front-Running Relicensing

The problem maintainers have in 2026 is that relicensing a popular project and monetizing the project itself is now risk-free in a way it was not five years ago.

If every maintainer prices in:

1. The people who bitch the loudest about relicensing were never part of my ICP² - and I’m not really going to suffer any actual reputational damage from pissing them off.
2. Several other large projects have relicensed and have not just been fine, but it’s worked! Relicensing gets more normalized each time someone does it.
3. Worst case scenario is my project dies, which is already what would happen if I stopped working on it and never asked for the sale.

Then there’s zero downside to relicensing popular libraries.

If anything, people getting pissed off and angry at you increases your sales by spreading awareness about the change. Angry Reddit posts and YouTube videos are effectively viral marketing for the paid license.

What the redditor was describing is how to become part of the auto-ignored ICP, a forever-irrelevant nonfactor in the maintainer decision-making process.

If the two options presented are:

1. Isolate yourself from upstream third party dependency changes through a lot of song and dance or
2. Get mad when relicensing happens and creates a business disruption.

What if there was a third option? Front-run the relicensing by proactively offering to support the project or buying services offered by the maintainer first.

In other words, price in the idea that key dependencies are going to cost you from the very beginning and act accordingly.

Incentives Matter

While there are a handful of projects that set out to use OSS as a distribution and customer acquisition strategy from the onset, like Pulumi, in most cases open source turns into a business by accident. This is absolutely the case with me, Akka.NET, and Petabridge.

Projects get popular, the original creator wants to help everyone, and this can go on harmoniously for years - but the more popular a project becomes, the more demand there is for the maintainers’ scarce and usually uncompensated time.

The “zero risk” for relicensing originates with the consumers of OSS having zero skin in the game - “I demand you change this free thing, IMMEDIATELY, so I can use it in software that makes me money” is an extremely unpersuasive argument on day 1, let alone day 1000 of maintaining an open source software project.

A third option tries to restore this balance by putting the maintainer in a position where they have something to lose if they relicense or adopt the OSMF: revenue, contractual guarantees, and goodwill from actual customers.

If I’m selling hundreds of thousands of dollars of Akka.NET support contracts each year, do I want to potentially upset that apple cart by pushing for a commercial licensing scheme on top of that? That’s much more of a gamble.

This is the position, you, the consumer, want to put maintainers in: make changing the rules of how OSS is consumed a higher-risk bet. You do this by becoming a customer, not a donor - because when you’re a customer you get things in return for your cash.

When Projects Lack a Business Model

The problem you’ll have from day 1 is that most maintainers are either inept at or totally disinterested in business, and therefore won’t have a business model you can readily support.

Rather than treat this like a blocker, treat it like an opportunity to set the terms of your relationship with the maintainer:

Hi {maintainer}

We love your {project} and want to use it in our applications here at {BigCo}. Would it be possible for us to sponsor you to the tune of {$/yr}? We would do this in exchange for an understanding, in writing that {project stays maintained, maintainer provides private incident response channel, license stays as-is for BigCo so long as sponsorship is maintained, etc}

This is basically writing your own support plan and naming your own price. What you are also doing is insulating your business from a future shock or disruption by making sure you are covered from relicensing risks.

Not every single third party dependency you depend on is going to warrant this, of course. It’s your risk and your choice.

Get Ahead of the Bill

Don’t think about relicensing like something that’s being done to you. It’s a bill coming due. Just like redditors love to argue that maintainers should have never expected to be paid for something they put out there for free, you shouldn’t expect to eat free forever either.

The software your business runs on costs real money, time, and sustained effort to maintain. Maintainers have discovered that a huge portion of their user-base will simply pay if they relicense; that trend will only continue. This is what a functioning market for open source looks like, and we’re early in it.

What you get to decide is whether or not you want to be surprised and disrupted when the bill comes due.

Sponsor the projects that matter to you now, while it’s cheap and you’re the one setting the terms, and you’re a customer the maintainer works to keep. Price it in from the start and it never becomes a crisis. It’s just the cost of using good software.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..

Tweet Follow @Aaronontheweb