Coding Bolt

Polly is going paid. Well, sort of.

Starting November 16, 2026, companies making at least $20,000 in revenue from a product or project that uses Polly will be asked to pay a $20 monthly maintenance fee.

That’s $240 per year. For one of the most widely used libraries in the .NET ecosystem, that’s basically nothing. And yet I think this change is going to cause Polly a lot more trouble than $20/month would suggest. Because the problem isn’t the price. It’s everything that comes with it.

Affiliate promo

If you love learning new stuff and want to support me, consider buying a course from Dometrain using this link: Browse courses – Dometrain. Thank you!

What is actually changing?

Polly is adopting something called the Open Source Maintenance Fee, or OSMF. The important distinction is that Polly’s source code isn’t becoming proprietary. The source remains available under its existing open-source license. You can read it, fork it, modify it and build it yourself. The fee is aimed at companies consuming the project’s maintained releases commercially.

For Polly, that means $20/month if a product or project using Polly generates at least $20,000 in revenue. The fee is per organization rather than per application, so using Polly in 50 applications doesn’t turn the bill into $1,000/month.

Individuals, students, hobby projects, nonprofits that aren’t generating revenue from Polly, and companies below the threshold don’t pay anything.

So no, Polly hasn’t suddenly turned into Telerik. But something meaningful has still changed.

Nobody cares about the $20

Let’s say I run a company making millions per year and Polly is sitting inside some critical services. Would I pay $240/year to keep it maintained? Of course. That’s not even a discussion. The funny thing is that the company might spend considerably more than $240 figuring out how to pay the $240.

A developer adds:

<PackageReference Include="Polly.Core" Version="..." />

Previously, that was mostly a technical decision.

Now it can also become a procurement decision.

Someone needs to know the fee exists.

Someone needs to work out whether your company qualifies.

Someone potentially needs to ask legal whether the terms are acceptable.

Someone needs to create the vendor.

Someone needs a company GitHub account or whatever payment process ends up being used.

Someone needs to approve the recurring payment.

And somebody needs to remember why the company is paying “App vNext” $20 every month three years from now.

For a small company, that’s annoying.

For a large company, it can be ridiculous.

I have worked in places where getting a $20 monthly subscription approved would cost more in employee time than the subscription itself.

That’s the actual problem here.

It gets weird with Microsoft.Extensions.Http.Resilience

This was probably the biggest source of confusion when the announcement started spreading. Microsoft’s modern resilience packages are built on Polly.

For example, you can install:

<PackageReference Include="Microsoft.Extensions.Http.Resilience" />

and end up using Polly APIs without explicitly installing Polly yourself. So do you owe Polly $20?

Apparently not.

The OSMF has now clarified that the fee applies to direct dependencies. If your project references package A, and package A depends on Polly, Polly is a transitive dependency and you don’t owe Polly anything.

A Polly maintainer confirmed the same interpretation when someone specifically asked about Microsoft.Extensions.Http.Resilience.

Which means this:

<PackageReference Include="Polly.Core" />

can potentially create a payment obligation.

While this:

<PackageReference Include="Microsoft.Extensions.Http.Resilience" />

doesn’t, even though your code may eventually execute the exact same Polly code underneath. Technically, I understand the distinction. From a developer’s perspective, it’s bizarre. And from the perspective of whoever has to audit your dependencies, it’s even more fun.

Then people started talking about forking Polly

Unsurprisingly, the announcement caused some pushback.

Ian Cooper, maintainer of Brighter, announced that they intended to create a Polly fork called Fences.

His main concern was exactly what you’d expect: Brighter had depended on Polly for years, and suddenly there was uncertainty around what that dependency could mean for Brighter users.

The fork announcement got quite a bit of attention. Then things cooled down slightly.

Polly project owner Joel Hulen responded that the team was taking the concerns seriously and was evaluating questions around affected versions, direct versus transitive dependencies and other edge cases.

Cooper subsequently said the fork would be paused while those details were clarified. That’s an important update because as of right now, this isn’t really a finished story.

The November 16 date is still there. The $20/month plan is still there. But some of the exact mechanics are clearly still being worked through.

The .NET Foundation also stepped in

Polly is a .NET Foundation project, so naturally people started asking what the Foundation thought about all of this.

On August 19, the .NET Foundation published a statement.

And their position was basically:

We’re not taking sides, but you should start reading the terms attached to your NuGet packages much more carefully.

The Foundation explicitly pointed out that the license attached to source code and the terms attached to maintainer-built binaries don’t necessarily have to be identical. That’s a pretty significant statement for .NET developers.

For years, most of us have treated:

dotnet add package Something

as the end of the licensing conversation. See MIT/BSD/Apache on GitHub?

Cool. Install package. Move on.

The Foundation is effectively saying that isn’t enough anymore.

You may need to look at package metadata, EULAs, notices and whatever additional terms come with the distributed artifact.

That changes dependency management from something developers mostly solve with Dependabot into something your legal department might eventually care about.

Wonderful.

What about old versions?

This caused another round of confusion.

If I’m already using Polly 8.x today, does a maintenance fee magically appear on November 16? Existing releases can’t simply have their original license retroactively rewritten. That was also acknowledged in the Polly GitHub discussions, and the .NET Foundation’s guidance says that rights to versions acquired under their previous terms remain unaffected. The interesting part is what happens with releases after the change.

The Polly announcement says the source license isn’t changing.

At the same time, the OSMF model works by putting additional terms around maintained binary releases.

That means we’re likely going to have a distinction between:

Polly the open-source project

and

the official Polly packages produced by its maintainers.

The source can stay BSD while future official releases have additional conditions attached to their use.

The .NET Foundation explicitly considers that kind of model compatible with Foundation membership as long as the source stays permissively licensed and users retain the ability to build functionally equivalent artifacts themselves.

Which leads to the obvious workaround.

You could just build Polly yourself

Polly’s source is still open.

So theoretically you can clone the repository, compile it and publish an internal NuGet package. Congratulations. You have saved your company $20/month.

You have also volunteered your company to maintain its own Polly distribution to save $20/month.

Please don’t tell your CFO about this incredible cost optimization.

This is another reason I don’t think the actual price is the interesting part of the story. Almost any technical workaround costs more than simply paying. What companies will care about is avoiding the legal and procurement overhead in the first place. And that’s why some of them might decide that the easiest option isn’t paying or self-building. It’s removing Polly.

I understand why Polly is doing this

This is the part that gets lost whenever an open-source library changes its business model. Polly has more than 2 billion NuGet package downloads.

Maintaining something used at that scale is work. Real work. Security reports need investigating. Issues need triaging. Pull requests need reviewing. New versions of .NET need supporting. Packages need publishing. CI breaks. Dependencies need updating.

People expect the project to be maintained indefinitely because they typed:

dotnet add package Polly

ten years ago.

Meanwhile, companies can make millions of dollars using that software and contribute absolutely nothing back. So I don’t have a problem with Polly’s maintainers wanting money.

In fact, I think maintainers of important open-source projects should make significantly more money than they currently do. That’s why the $20 price almost feels counterproductive.

If you’re going to introduce enough friction that a Fortune 500 company needs procurement involved anyway, charging them $20 feels like the worst of both worlds. You get the commercial friction without really charging a commercial price.

And Polly probably won’t be the last

This is the more interesting part. OSMF isn’t exclusively a Polly thing. Other maintainers are looking at the same model. And if it catches on, imagine a company with 200 direct open-source dependencies.

$10 here.

$20 there.

$40 somewhere else.

The money still isn’t necessarily scary. The dependency administration is.

Suddenly your dependency graph isn’t just:

MyApp
 ├── PackageA
 ├── PackageB
 └── PackageC

It’s:

MyApp
 ├── PackageA       MIT
 ├── PackageB       $20/month
 ├── PackageC       Apache 2.0
 └── PackageD       $40/month after $100k revenue

Now upgrading a package can potentially change more than your API surface. It can change your commercial obligations.

That’s a very different NuGet ecosystem from the one .NET developers are used to.

Would I stop using Polly?

No. Not because of $20/month. If Polly is solving an actual problem in a production system, $240/year is completely reasonable.

I also don’t think maintainers should be expected to work indefinitely for free just because they originally put a BSD license on GitHub.

But if I were choosing dependencies for a new project inside a large company? I’d think about it. Not because I desperately need to save twenty dollars. Because every dependency that requires a separate commercial agreement creates organizational friction and developers are extremely good at avoiding friction.

If I can solve the same problem with something that’s already part of the Microsoft stack, or with 50 lines of code I own myself, that suddenly becomes a much more attractive option.

That’s the risk Polly is taking. Not that developers will refuse to pay $20. That they’ll decide it isn’t worth going through the process required to pay it.

And if OSMF becomes common across the .NET ecosystem, Polly might end up being remembered less for the $20 fee itself and more for forcing us to reconsider what adding a NuGet package actually means.

Affiliate promo

If you love learning new stuff and want to support me, consider buying a course from Dometrain using this link: Browse courses – Dometrain. Thank you!