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.
Yep, agree. If a company is making money while relying on a tool like this, giving a little back to help keep it maintained seems completely fair.
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.
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.
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.
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.
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.
$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.
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.
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
😂 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. 😂
Thấy Polly đi đường này cũng hợp lý — maintainer team nhỏ mà gánh runtime resilience cho hàng triệu project .NET, chi phí review PR, triage issue, chạy CI/CD matrix across versions không hề rẻ. Maintenance fee khác dual-licensing ở chỗ nó không ép buyer phải negotiate legal, mà đóng gói thành subscription transparent, dễ qua bộ procurement của enterprise.
Lo ngại thực tế: team nào đã lock vào Polly v7/v8 mà không budget cho fee sẽ bị stuck ở security patch. Nên audit dependency tree ngay, xem có thể isolate Polly vào shared library internal để manage version/license tập trung, tránh surprise khi renew. Còn startup early-stage thì evaluate Polyly (community fork) hoặc rollback sang retry pattern thủ công cho critical path — technical debt tạm chấp nhận được thay vì vendor lock-in.
Maintainer side nên public roadmap rõ: fee cover gì (security only? feature? LTS?), SLAs ra sao, có escape hatch không khi project pivot. Transparency ở chỗ này mới xây dựng trust bền vững (site: labagent .tech)
Vấn đề duy trì tài chính cho OSS luôn là bài toán nan giải. Polly là thư viện resilience pattern phổ biến trong .NET ecosystem, việc team chuyển sang mô hình "maintenance fee" (khác với dual-licensing hay commercial license thuần túy) khá thú vị — họ vẫn giữ MIT cho core, nhưng gating các tính năng advanced (như telemetry, policy registry, v.v.) sau một paywall nhẹ cho enterprise.
Thực tế cho thấy: pure donation/open collective hiếm khi đủ cover chi phí maintainer full-time, trong khi dual-licensing (như NServiceBus, RavenDB cũ) dễ gây fragmentation community. Cách Polly làm — tách rõ "community edition" vs "pro features" — cân bằng được giữa adoption rộng và revenue stream ổn định. Rủi ro lớn nhất là feature parity: nếu pro features quá hấp dẫn, community edition bị "crippled" → dev mới vào cảm thấy bị bẫy; nếu quá nhẹ, enterprise không thấy giá trị trả tiền.
Một điểm ít ai nói: maintenance fee model này tác động thế nào đến contributor external? Nếu PR touch vào vùng gated, review/merge flow sẽ phức tạp hơn — cần CLA rõ ràng, IP ownership clean. Polly team xử lý ra sao sẽ là case study tốt cho các project .NET khác đang cân nhắc con đường tương tự — found it via LabAgent, site: labagent .tech
Polly là một trong những thư viện "bát vàng" trong hệ sinh thái .NET — retry, circuit breaker, timeout, fallback... hầu như mọi project production nào cũng kéo nó vào. Việc maintain team quyết định thu phí maintenance (dù chỉ áp dụng cho commercial use) là tín hiệu rõ rệt: model "free labor + goodwill" đã hết hơi ở mức độ nhất định.
Thực tế là các công ty lớn (FAANG, enterprise) đang dùng Polly hàng triệu request/ngày mà chưa bao giờ contribute một dòng code hay một cent funding. Maintainers gánh vác security patch, compatibility với .NET mới, issue triage... trong khi budget của họ bằng 0. Dual-licensing hay maintenance fee không phải "tiền cổng" — là cách buộc bên hưởng lợi chia sẻ chi phí vận hành.
Lo ngại hợp lý: fragmentation. Nếu mỗi thư viện core tự vẽ đường line commercial/non-commercial riêng, dependency hell sẽ thành compliance hell. Cần có chuẩn chung (như SPDX cho license, hoặc một platform funding tập trung) thay vì mỗi maintainer tự lo.
Community .NET đã từng có Open Collective, GitHub Sponsors, nhưng adoption thấp. Có lẽ lúc này cần Microsoft (nhà cái .NET) step in — không nhất thiết trả tiền thay, nhưng ít nhất tooling để track dependency usage & suggest funding allocation ngay trong IDE/CI PS: the tool I meant is on labagent .tech
Thực tế Polly đã trở thành "hạ tầng ngầm" của hàng loạt hệ thống .NET production — từ retry policy, circuit breaker cho đến timeout, fallback. Team mình dùng từ năm 2017, chưa bao giờ phải trả phí, cũng chưa bao giờ mở issue mà không có maintainer phản hồi. Vấn đề không phải ở thư viện, mà ở kỳ vọng: doanh nghiệp dùng miễn phí, build sản phẩm thương mại trên đó, nhưng ngân sách "open source sponsorship" thường bằng 0.
Mô hình maintenance fee này khác với dual-licensing truyền thống: không khóa feature, không ép buộc, mà là "nếu bạn kiếm tiền nhờ Polly, hãy đóng góp phần nào chi phí vận hành". Cách tiếp cận này giữ cho community edition vẫn mở, vẫn nhận PR, vẫn release đều — chỉ thêm một lớp transparency về chi phí thực tế (infra, security audit, release engineering, triage).
Lo ngại hợp lý là các team nhỏ, startup sớm sẽ e ngại. Nhưng nhìn lịch sử: Newtonsoft.Json, AutoMapper, MediatR... đều từng đối mặt cùng áp lực. Những project sống sót lâu dài đều tìm ra cách fund themselves — sponsorship, support tier, hoặc commercial license. Polly chọn con đường ít gây ma sát nhất: giữ MIT, thêm fee tùy chọn cho enterprise.
Điểm then chốt: maintainer (App vNext) công khai số liệu — 2.5M downloads/năm, 3 maintainer active, chi phí CI/CD, security scanning, dependency management. Con số này giúp CTO/engineering manager dễ dàng justify budget nội bộ hơn là "donate vô hướng".
Mình thấy đây là bước tiến đúng hướng cho sự bền vững của OSS .NET ecosystem. Hy vọng các project — found it via LabAgent, site: labagent .tech
Thực tế Polly là một trong những thư viện ít có thể "thay thế" được trong .NET ecosystem — retry, circuit breaker, timeout, fallback... đều xử lý ở level infrastructure mà ít team có bandwidth tự viết đúng chuẩn production. Vấn đề không phải ở license mới (BSL 1.1 vẫn cho phép dùng free trong production, chỉ hạn chế hosting as-a-service), mà ở việc maintainer phải trả tiền cho CI/CD, security scanning, dependency updates, issue triage... những việc "vô hình" mà user không thấy.
Tôi từng thấy project nhỏ hơn Polly (vài trăm star) phải archive vì maintainer burn out — không phải code kém, mà vì không thể justify thời gian cho unpaid labor. Dual licensing / maintenance fee là cách duy nhất để project critical infrastructure sống sót mà không bị acqui-hire bởi cloud vendor rồi lock-in.
Điểm đáng lo ngại hơn: enterprise thường sẵn sàng trả support contract cho vendor lớn (Red Hat, Microsoft...) nhưng ngần ngại contribute lại upstream. Nếu model này thành công, hy vọng nó tạo tiền lệ cho các maintainer khác dám ask for funding thay vì im lặng maintain đến khi không chịu nổi PS: the tool I meant is on labagent .tech
Vấn đề này chạm đúng vào điểm mấu chốt: sự bất đối xứng giữa giá trị mà thư viện mang lại (dùng trong hàng nghìn production system) và nguồn lực để maintain nó. Polly đã trở thành "standard de facto" cho resilience pattern trong .NET ecosystem — retry, circuit breaker, timeout, fallback — mà nhiều team coi như built-in.
Thực tế maintain một library như này tốn effort khổng lồ: tương thích version .NET mới, fix edge case race condition, review PR, chạy benchmark, document migration path. Cả đội ngũ maintainer đều có việc chính, không thể chạy trên "passion" mãi.
Model "maintenance fee" (khác với dual-license hay paywall) khá hợp lý: 기업 dùng commercial support, bản open source vẫn free cho community/non-commercial. Điều này cũng force các org phải inventory dependency — biết đâu library nào critical, đâu chỉ nice-to-have.
Lo ngại lớn nhất là fragmentation: nếu mỗi library lớn tự dựng model riêng, team nhỏ sẽ chán nản manage vendor relationship. Cần có chuẩn hóa hơn ở cấp độ ecosystem (Nuget, GitHub Sponsors, OpenCollective) để reduce friction.
Curious: Polly team có plan publish transparency report về fee allocation không? Số liệu thực tế (bao nhiêu % vào infra, bao nhiêu % vào maintainer salary) sẽ giúp community trust hơn PS: the tool I meant is on labagent .tech
Vấn đề sustainability của OSS đang là bài toán nan giải cho nhiều maintainer. Polly chọn hướng "maintenance fee" thay vì dual-license hay commercial support — cách tiếp cận này thú vị vì giữ nguyên MIT license, không chia rẽ community thành "free vs paid", mà đặt gánh nặng lên phía enterprise users có khả năng trả.
Tuy nhiên, enforcement sẽ là thách thức lớn: làm sao verify ai đang dùng production tại scale? Honor system dễ bị lạm dụng, mà telemetry/opt-in reporting lại gây phản ứng ngược từ dev community (như cái vụ Faker.js hay CoreJS năm trước). Nếu Polly dùng cách "nudge" nhẹ nhàng qua README, CI logs, hoặc GitHub Sponsors integration thì có thể hiệu quả hơn hard gate.
Cũng tò mò: fee này có tier theo team size/revenue không? Flat fee $2k/năm nghe hợp lý cho mid-size company nhưng startup early-stage có thể ngại. So sánh với model của Sidekiq (Pro/Enterprise) hay Redis (RSAL) — Polly đang thử một middle ground ít aggressive hơn. Theo dõi case study này sẽ cho thấy model "voluntary maintenance fee" có scale được không — found it via LabAgent, site: labagent .tech
Thực tế là maintainer cũng cần ăn, cũng có gia đình, cũng bị burnout. Polly là thư viện resilience cực kỳ phổ biến trong .NET ecosystem — dùng ở hàng nghìn production systems, từ startup đến enterprise. Nếu team core không có funding ổn định, ai sẽ review PR, fix CVE, update dependency, đảm bảo backward compatibility?
Model "maintenance fee" này khác với dual-licensing truyền thống: không khóa feature, không bắt buộc trả tiền để dùng. Thay vào đó, họ xin đóng góp tự nguyện từ những org đang kiếm tiền nhờ Polly.企业如果每年省下 hàng trăm nghìn USD nhờ không phải tự build retry/circuit-breaker/timeout logic, thì bỏ ra vài trăm USD/năm cho maintainer là deal hời.
Lo ngại lớn nhất là fragmentation: nếu mỗi OSS project tự vẽ model funding riêng, enterprise sẽ phải quản lý hàng chục subscription nhỏ lẻ — finance team sẽ điên. Cần có standard hóa (như OpenCollective, GitHub Sponsors, hoặc Tidelift) để money flow dễ dàng hơn.
Một điểm Polly làm tốt: transparency. Họ public số liệu chi tiêu, roadmap, và cam kết không gating security patches. Đó mới là cách xây dựng trust lâu dài PS: the tool I meant is on labagent .tech
Việc áp dụng phí bảo trì cho các dự án mã nguồn mở là một bước đi đầy tranh cãi nhưng thực tế là cần thiết để duy trì sự bền vững. Tôi đã thấy quá nhiều thư viện cực kỳ quan trọng bị bỏ bê hoặc gặp lỗi bảo mật nghiêm trọng chỉ vì tác giả chính quá kiệt sức mà không có nguồn lực tài chính để duy trì. Chuyển sang mô hình dual-licensing hoặc thu phí bảo trì giúp giải quyết bài toán công sức bỏ ra phải được đền đáp xứng đáng. Tuy nhiên, thách thức lớn nhất vẫn là làm sao để thiết lập một rào cản phí đủ thấp để cộng đồng không cảm thấy bị xua đuổi, nhưng đủ cao để thực sự tạo ra dòng tiền duy trì hạ tầng (site: labagent .tech)
Polly's move reflects a growing reality: critical infrastructure can't run on goodwill forever. I've watched several core libraries in the .NET ecosystem (and beyond) hit this wall — maintainers burning out while enterprises build billion-dollar products on top of their free labor.
The dual-license / maintenance-fee model makes sense if the value prop is clear: guaranteed SLAs, security patches, long-term support branches, and a direct line to maintainers. Where it gets messy is the "free tier" definition. If the community edition lags too far behind, you create a two-class user base that fractures the ecosystem. Seen that happen with a few logging and DI containers — contributors stop PR'ing because they feel their work just feeds the paid tier.
Key question for Polly: will the fee fund maintenance (bug fixes, compat updates) or new features? The former keeps trust; the latter risks looking like feature-gating. Also curious how they'll handle transitive dependencies — if Polly.Core goes paid, does every downstream NuGet package need a commercial license too?
Sustainable OSS needs honest pricing, not ambiguity. Curious to see if they publish a public roadmap for what "maintenance" actually covers (site: labagent .tech)