A few weeks ago, I wrote about open-source projects moving toward paid or dual-licensing models, and whether AI is accelerating that shift.
Now Polly, one of the most popular .NET resilience libraries, is taking a slightly different approach.
Polly is introducing an Open Source Maintenance Fee (OSMF). The source license stays the same and Polly remains open source, but companies earning at least $20,000 from a product or project using Polly will be required to pay $20/month per organization for its maintained releases.
It's an interesting approach to the open-source sustainability problem. You can read the Polly announcement.
OSMF itself is actually an interesting model for open-source maintainers. Instead of changing the open-source license or putting the source code behind a commercial license, maintainers can charge a small maintenance fee for organizations using their maintained releases in revenue-generating products.
GitHub Sponsors can be used to collect the fee, with projects able to define their own pricing or tiers. The source code itself still remains available under its open-source license.
You can read more on the OSMF page.
In Polly's case, $20 per month - $240 per year, is a pretty small amount for a company generating at least $20,000 from a product using it. The administrative side might actually be more annoying for some companies than the price itself. We all know how it works in corporate when it comes to project license purchases, right? 😄
I find this especially interesting because it's another possible answer to the problem I wrote about earlier: how do you fund long-term open-source maintenance without simply turning the project into a commercial product?
What do you think about OSMF? Or do you know another interesting approach to making open-source projects sustainable in the AI era?
Top comments (36)
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. 😄
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. 🤣🤣🤣
🤣 Who knows? Maybe she programs at night under a pseudonym. 🤣🤣🤣 But you are definitely ahead!! 🤣
Hahaha, fair point! 🤣 But hey, I can sing a little too, so Ewa shouldn’t feel too safe just yet. 🤣🤣
Then you are a real threat. 🤣🤣
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. 😂
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.
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.
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.
$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.
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!
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.
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.”
😂 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.
Well said. 😂
Some comments may only be visible to logged-in visitors. Sign in to view all comments.