A few weeks ago, I wrote about open-source projects moving toward paid or dual-licensing models, and whether AI is accelerating that shift.
...
For further actions, you may consider blocking this person and/or reporting abuse
I think this is a really good model! You often see something similar with frontend tools too, although implemented a bit differently. For example, you might have a data grid or component library with a free/basic version, but if you want the really nice advanced features, you pay a relatively reasonable amount for them. With grids, that might be things like server-side or asynchronous row loading.
And I think the logic here is pretty similar: as long as you’re not making money from it, the free version is probably enough. Once you start making money, investing some of it back into better features suddenly makes a lot more sense. 😄
I really like this model. We’re not taking money from the poor, only from the rich. Basically the Robin Hood business model. 😂
Hmm, interesting and is the code still open source in those cases? There are a lot of products with the “free basic version, paid advanced features” model, where you pay mainly for features that save time, but the code itself isn’t open.
That’s what I find interesting about this model: the code still stays open source, so you can fork it and maintain/build it yourself for free, or just pay the small maintenance fee.
Amazing name: Robin Hood business model. 😂😂 I think they should rename OSMF to that instead. 😄
Hahaha, you're right! I think with those libraries, the paid code isn't actually open source. Apparently they don't trust the community that much. 🤣
And yes, “Robin Hood” would at least be easy to remember, instead of some impossible tongue twister. 😂
Btw, I have to brag a little! I’m basically almost Czech at this point, so Ewa Farna finally has some serious competition on the Polish-Czech market. 😂
Oh nice!! But careful, one more conference in Czechia and Ewa Farna might start getting nervous. That could turn into a real rivalry! 🤣🤣
Exactly! But does Ewa Farna know what WebGPU is? Can she build her own AI agent? I DON’T THINK SO. 🤣🤣🤣
I love it. I think its fair. If im a successful business using this tool that helped me, I have no problem giving back if it's going to good use. I think if more business took on a little more social responsibility the entire world would be just a tiny bit better.
Collecting money not from poor individuals but from wealthy companies is a good idea. Also, collecting money per company rather than per user makes more sense. I hope both OSS users and creators can keep it sustainable. 🤔
Yep, I agree. You’re actually a maintainer yourself. Your code isn’t open source, but your app is free. Have you thought about a pricing model for the future?
Yes, when AI Avatar becomes a big hit, I would love to add an extra paid plan. Also, I will hire you at a high salary! 🤣💰
Oh nice! Finally I’d be able to buy an aircraft carrier. 🤣🤣🚢
I hope AI Avatar becomes a really, really big hit!😅🤑
The $20/month fee is trivial for any business generating $20k+, but the procurement overhead is where this model hits a massive wall.
In enterprise software engineering, the hurdle is rarely the dollar amount—it’s the legal and administrative friction:
While I respect Polly for attempting to solve open-source burnout without changing the underlying OSI license, requiring corporate procurement for a micro-transaction often drives risk-averse enterprise legal teams to simply ban the dependency or look for internal forks.
Agree. You’re actually the second person to mention this. The $20 itself is almost nothing for a bigger company, but the procurement and compliance around it can easily cost much more than the fee itself.
That’s probably the biggest practical weakness of this model in larger companies.
Your joke about corporate license purchases is the whole story, and it is worse than most people outside regulated buyers realize.
I work on the public sector side. A 240 dollar annual charge is not a small purchase for us, it is an awkward one. Below the competitive threshold it still needs a vendor record, a W-9, a sole source justification explaining why this library and not another, and a purchase order. That is several hours of several people's time, which means the administrative cost of paying Polly exceeds the fee by an order of magnitude. And a recurring GitHub Sponsors charge on a card is a payment instrument plenty of agencies simply do not have. The failure mode is not unwillingness to pay, it is inability to transact.
So the practical advice I'd give any maintainer considering OSMF is to make yourself purchasable: an entity that can receive an invoice, a W-9 on request, and an option to prepay three years in one transaction. The prepay matters more than the price. It converts a recurring headache into a single procurement event, and it is the difference between "yes" and "we'll look at it next fiscal year," which is the same as no.
The part I like structurally is that OSMF leaves the license alone. It asks for a norm rather than enforcing a term, which keeps downstream trust intact in a way relicensing never does. It does mean compliance is self-attested at the 20k threshold, but a norm that most companies follow beats a license change that fragments the ecosystem.
The number I'd watch is not how many orgs pay. It is whether funded maintenance visibly changes issue and release latency. If Polly can show that, the second wave of maintainers has an argument. If it cannot, OSMF reads as a tip jar with paperwork.
Thanks for bringing another angle to this, especially about making OSMF easier to buy for bigger companies or the public sector.
The problem with pushing a new fee through corporate procurement is definitely real and the internal cost can easily be much higher than the fee itself. You’re actually the third person to mention this.
I really like your idea about being able to prepay for a few years at once. For companies where every payment means another procurement process, that could make a much bigger difference than lowering the fee itself.
And I agree that the interesting question will be whether this additional funding actually translates into better maintenance and faster releases. If it does, I think it makes the whole model much easier to justify.
Multi-year prepay is the detail I'd push hardest on if I were advising the maintainers — it doesn't just cut procurement cycles, it turns an annual budget fight into a one-time decision, which is a very different ask to get signed off. Agreed the real test is whether the fee shows up in release velocity; funding that doesn't visibly change output is the fastest way to lose the argument for renewing it next cycle.
Yep, agree.
One common mistake is trying to choose a revenue model before building the system.
You should build the system first, then decide what should be free, paid, subscription-based, service-based, or even free for users but paid by companies.
The same skill can support completely different business models.
For example:
Free content can attract people, a paid service can generate revenue, and a product can be free for individual users while companies pay for the business value they receive.
So the question isn't simply:
What is my revenue model?
It is:
“What system am I building, who creates value in it, who receives that value, and where should the money flow?”
Revenue models can differ. The system is what connects them.
That makes sense in general, especially for a new product.
With Polly though, I think the situation is a bit different because the project has existed for years and already has a large user base. The interesting question here is more about how to fund long-term maintenance of an established open-source project without changing its license.
That’s why I find OSMF interesting in this case.
Exactly, and I think that’s where the distinction becomes interesting.
For an established open-source project like Polly, the system already exists, the users already exist, and the value is already being created. The problem shifts from “how do we monetize this?” to “how do we keep the system sustainable without breaking what made it valuable in the first place?”
That’s why I think maintenance funding is part of the system architecture too. The revenue model may change over time, but it still needs to fit the users, contributors, license, and long-term value of the project.
That’s what makes the Polly case interesting.
One case I haven't seen covered here is the transitive one. Plenty of .NET teams never reference Polly directly; they get it through Microsoft.Extensions.Http.Resilience or some vendor SDK that depends on it. Does the obligation land on a company that has never typed the word Polly, or on the library in between? If it's the former, compliance starts with discovering the package in your own dependency tree, and that's the step the $20 doesn't pay for.
This was supposed to be just a small announcement post, but thanks for bringing this up. It’s definitely an important part.
I checked the OSMF docs, and they actually cover this case. The fee applies only to direct dependencies. So if Polly is pulled in transitively through something like Microsoft.Extensions.Http.Resilience or another SDK, your company doesn’t need to pay Polly directly.
Polly’s own announcement doesn’t go into this detail, but it points to the OSMF FAQ for cases like this.
OSMF FAQ: opensourcemaintenancefee.org/consu...
Thanks for digging that out, it's a cleaner answer than I expected. It does make the csproj the thing to audit: the same Polly binary is billable or not depending on whether it's a direct PackageReference or arrives through Microsoft.Extensions.Http.Resilience. I suspect plenty of teams will find a direct reference someone added years ago for a single retry policy, and the fee is the first reason anyone has had to look at it since.
The price is probably the easy part; dependency ownership is the harder operational question. A maintenance-fee model works best when an organization can identify where Polly is used, which versions count as maintained releases, who owns renewal, and which products cross the revenue threshold. I’d treat adoption as an SBOM and procurement event: pin the approved version through central package management, record the responsible owner, and make CI flag unreviewed upgrades. Otherwise a small fee can become a surprisingly large shadow-compliance problem.
Yeah, the compliance side can definitely become more complicated than the actual price and tracking where Polly is used, who owns it, and who is responsible for paying the fee can become a bigger problem, especially in larger companies.
But in Polly’s case, as I understand it, the fee is per organization, not per project or version. So once the company qualifies, it’s still just one $20/month fee.
Daniel, the revenue threshold is the smart part about this. So $20,000 before the fee kicks in protects small users completely. I am building something close to this logic right now, a free BYOK tool with a flat usage markup instead of a subscription. Same idea: stay free until someone is actually making money off it.
Interesting. So if I understand it right, your model is usage-based pricing?
And is the code open source too or are you just selling the final product?
close but a bit different. The markup is usage-based but the free tier stays free below a set usage level not just a trial.
The plan is to keep the code open source, like Polly. Users can self-host and skip the fee if they want to. far from a finished project tho.
That sounds really good. Good luck with the project!
$20/month is nothing for a company making $20k+ off a product. The real cost is the paperwork — getting a vendor set up in procurement, legal reviewing the license terms, someone tracking the renewal. I've seen that process take longer than the integration itself. The model is clever but the $20k revenue threshold is going to be a nightmare to verify in practice — most companies won't self-report, and Polly has no enforcement mechanism beyond the license terms.
Yep, this is becoming the most common concern in the comments. The $20 itself is basically nothing for a bigger company, but procurement and compliance around it can easily cost much more.
And I agree that the revenue threshold is another tricky part. For large companies it might be pretty obvious that they cross the threshold, but for smaller or mid-sized companies it can be much harder to know. In practice, Polly has to rely quite a lot on companies recognizing that they qualify and following the maintenance-fee terms for official releases.
I work at a bank, so I've seen how this goes from the inside. $240 a year is nothing, but getting a new vendor approved for it is a small project of its own. I think a lot of companies will just stay on the last free version and nobody will notice for a couple of years, which is kind of the opposite of what the fee is for. Still like the idea though, it's a lot more honest than changing the license.
Yep, companies can decide it’s easier to stay on the last version than go through vendor approval, or even do some small maintenance themselves in a fork.
And I agree, keeping the license unchanged is probably the strongest part of this model.
The model has been around for a long time, Inno Setup does the same, if you earn over 5k, you pay for it... The only thing is, it's an installer... Why pay a ton of money... For an installer... That a user only ever uses once?
That's where the model breaks down, because if the software doesnt do magic, they'd just replace it, how would you enforce it and when you enforce it, what'll make them pay as opposed to replace it? It took me less than a week to build an arguably better installer from scratch, it'll take a large firm less than half the time to do the same.
Open source is by nature tough to monetize, it's purely incentive driven and to make someone pay for it, after they used it for free, means they'd rather not use it to begin with? Rather, the model I think works best, is the model that Rust Foundation uses and Linux Foundation too. You get paid for maintaining and expanding, by the companies that need you to maintain and expand. You offer services ontop, that you wouldnt be able to offer, if people didnt use it. That way it's not just 'ok, it made you money, where's my cut?' instead, it's 'if you want that feature, pay for it'. That's how companies can incentivize the maintainers through bug bounties, support services and training services. The other model, is use it and monetize using it, alot of companies host their open source product and that's their market value, eg. Wasmer, Wasmer Edge is literally a baremetal server cluster with wasmer installed, so it can run the .wasm files. Nothing fancy. But people use it, because it's cheaper and easier than setting it up themselves.
I get your point, but it’s also not always easy to get budget for replacing some piece of software, even in big companies. Nobody really wants to give you money just to replace something that already works, so building your own alternative is not always such an easy decision.
But developing software is one thing and maintaining it for years is another. Libraries like Polly can require a huge amount of time every year just for maintenance, fixes, compatibility, releases, etc.
That’s actually what I like about OSMF. You can pay a relatively small fee for maintained releases, or you still have the open-source code and can fork/build it and take care of the maintenance yourself.
So for me it’s less “you made money, give me a cut” and more “if you want us to keep maintaining this for you, help fund that maintenance.”
As someone who has released an open-source Java library, I’ve seen that publishing the code is only the beginning—maintenance and compatibility work continue long after. I like that this model keeps the source open while asking revenue-generating organizations to support that work. The tricky part may be procurement: approvals and compliance could cost more than the $20 fee itself. If the payment process stays simple and transparent, this could be a fair middle ground. I’m curious how Polly plans to handle that overhead for larger companies.
Yep, exactly. Publishing the code is only the beginning, maintenance and compatibility work can continue for years.
And procurement is definitely the most common concern people have mentioned here. The $20 itself is small, but getting it approved inside a bigger company can cost much more in time and administration.
$20/mo is super reasonable for maintenance. At The Printing World, setup fees like this are totally normal for custom box manufacturing runs. Upkeep costs time and money, so making sure core tech stays maintained makes total sense.
😂 Open source is funny that way. We all love the “free as in freedom” part until the maintainer realizes freedom doesn’t pay the server bill.
That’s the part people forget , “free” software still costs someone time, infrastructure, and support.
Well said. 😂
Smart that the license stays the same. But $20 a month is nothing while the procurement to approve it can cost far more in time. If maintainers make it easy to buy, this has legs.
not a fan of .NET but this is good for the project