Proposal: Open Source Maintenance Fee for Verify

[SimonCropp]

The Verify project is considering adopting the Open Source Maintenance Fee (OSMF), and we'd like to open it up for discussion before committing to anything.

Verify has been freely available since 2019. The source code will remain open and freely available under its existing license — what's being proposed is a Maintenance Fee for organizations that generate revenue from using it, not a change to the underlying license.

The reason this is being explored: the ongoing work of maintaining Verify — triaging issues, reviewing PRs, updating dependencies, responding to security reports, producing releases, and supporting the wider ecosystem of extensions — takes real, sustained effort. The Maintenance Fee model is one way to make that work more sustainable without restricting access for individuals or non-commercial users.

The rough shape of the proposal

• Targeted for rollout in August 2026, giving roughly three months of lead time.
• Applies to organizations that generate revenue, and government agencies, when using Verify's official binary releases.
• Tiered based on organization size, with a single subscription covering all products and uses within that organization.
• Payment via GitHub Sponsors, which supports monthly billing, annual billing, and invoicing.
• A major version bump will be done at release time on any package that requires the OSMF, so consumers see a clear signal in their package manager.

Cost

The sponsorship levels are outlined on the VerifyTests GitHub Sponsors page and follow the recommended levels from the OSMF:

• Small Organization (fewer than 40 employees): $5/month
• Medium Organization (40 to 200 employees): $20/month
• Large Organization (more than 200 employees): $30/month

Required for organizations with annual gross revenue of at least US$10,000 that use Verify as part of revenue-generating activities. Also required for all government agencies.

Existing sponsors

Existing sponsorships are very much appreciated, and the recommended transition is:

• Individual sponsors should stop their personal sponsorship and let their employer know that, if the employer meets the requirements, the employer should now be sponsoring rather than the individual. The Maintenance Fee is designed to be paid by organizations, not individuals out of pocket.
• Organization or company sponsors should move to the tier that applies to them based on their size.

Consulting exemption

Organizations that have engaged any of the core maintainers of Verify in consulting work could be exempt from the Maintenance Fee for 6 months from the final date of that work. The reasoning: those organizations would already be directly funding maintainer time, so requiring a separate Maintenance Fee on top would feel like double-dipping.

If this idea proceeds, details such as what counts as "core maintainer" and "consulting work" would be clarified before rollout. Feedback on whether this exemption makes sense, and how it should be scoped, is welcome.

Scope: which projects?

One thing explicitly not decided yet is whether the Maintenance Fee should apply to all projects under the VerifyTests organization, or only a subset.

One option under consideration is to limit the fee to extensions that target paid or commercial products — for example Verify.Bunit or Verify.SqlServer — on the reasoning that organizations using those extensions are already operating in a commercial context. The core Verify package and extensions targeting free/open-source ecosystems would remain fee-free under that model.

Feedback on this scoping question is particularly welcome.

Enforcement

A separate open question: should there be any technical enforcement of the Maintenance Fee, and if so, how?

The options range from purely honour-based (rely on the EULA and trust organizations to do the right thing) through to automated checks. One possibility for the latter is SponsorCheck, which verifies sponsorship status at build time.

A few principles regardless of which direction is chosen:

• No phone home. Any form of runtime telemetry or "phone home" mechanism is off the table and will not be considered.
• Escape hatch. Whatever option is chosen will include an escape hatch so it can never block productivity — for example, an opt-out flag or override for cases where a check produces a false negative or the user simply needs to keep working. The working assumption is that most people are doing the right thing, and the enforcement mechanism should not punish them when something goes wrong.

There are trade-offs in both directions — honour-based is friction-free but relies entirely on goodwill, while automated checks add reliability but also add complexity, potential for false negatives, and friction for legitimate users. Thoughts on the right balance here are welcome.

What would not change

• The source code stays open and freely available under its existing license.
• Individuals and non-revenue-generating organizations (excluding government agencies) would not be required to pay.
• All existing and future versions would remain available to paying organizations while their sponsorship is active.
• Forks, contributions, and local development of the Verify codebase would be unaffected.

Feedback wanted

Nothing here is locked in. Feedback from the community is welcome before moving forward — particularly from organizations that use Verify, but also from individual contributors and users. Concerns, questions, suggestions on the tiers, the timeline, the scope, enforcement, or the approach overall are all welcome. Please reply below.

For broader context on the model, see the Open Source Maintenance Fee site and its FAQ.

For OSMF specific questions i will be directing people to the above links or to their discussion forum https://github.com/orgs/opensourcemaintenancefee/discussions

[radmorecameron]

I think it could makes sense to start with a subset of paid/commerical projects to test the waters and if that doesn't make much of a difference, expand to other packages or add all projects under VerifyTests.

It could also make sense to try out the different enforcement methods on the subset which could allow you to get feedback before expanding to more packages.

[SimonCropp]

@radmorecameron out of curiosity, what extensions to Verify are you using?

[radmorecameron]

I was using the Playwright extension but I'm no longer working on the project that was using it 🙂

[Skleni]

The difference between small and medium organizations feels a bit high. We fluctuate around 20 employees and depending on which side we land on, the price increases 4 times.
Also, you might want to clarify how "employees" are counted. Just the number of people being employed? Full-time equivalent? What about interns?
This might feel very specific, but in our case these questions would make a difference.

[SimonCropp]

clarify how "employees" are counted. Just the number of people being employed? Full-time equivalent? What about interns?

if people are part-time u can count the % part they work to the count. yes interns count

i will clarify that in the above terms.

the price increases 4 times.

i think it is important to qualify "4 times" here. we are talking the difference between 33c and $1.33 per day. from my perspective, if a dependency was not providing significantly more value than $1.33 per day, then i would question if that is a dependency we should even take.

[SeanKilleen]

In short: I'm for it. If it helps you keep development sustainable it's more than reasonable to request a fee from orgs that make a profit from it.

We'd be impacted by this at my organization. Here's how it would work:

• I'd note the license change (which should come with a major version bump)
• I'd raise to the team
• We'd have a discussion on whether we get $480/year of value from the tool, or whether it's worth spending $x in dev-time to move away from it
• We (almost certainly) decide to adopt the tool
• I make GitHub sponsorship the same day to unblock our update path.

Enforcement is annoying and I'd really rather not have to deal with it at first. Any development shop at a decent commercial enterprise is likely to care when licenses change. Announce the change everywhere you can, major version bump, release notes, readme. See how far that takes you first. If it's clear that things aren't aligned and you need to deal with bad actors, then I'm very willing to adopt it as a follow on step.

[AndrewTriesToCode]

Hi @SimonCropp I maintain a small popularish multi-tenant library for .NET and have been following OSMF and your discussion here. I’ve got a few GitHub sponsors. Some come and go, may one timers, and a few loyal monthly sponsors.

I think that build time checks are the most likely thing that people will tolerate in the .NET open source / enterprise ecosystem.

It’s a tough space. Even if they want to sponsor, corporate red tape gets in the way. It’s so frustrating because I’ve seen the dumb stuff companies will pay for if it’s slightly more visible to their customers.

[SeanKilleen]

@SimonCropp I read the proposal. I appreciate you writing it up.

My point is mostly that if you degrade the experience of good actors in order to attempt to shrink the number of uninformed actors, you will lose good (paying) actors if unnecessary friction occurs. I would first establish who that group of good actors is, which also allows you to give specific warning on build-time changes, explain reasoning, and create a direct line for feedback if things break. These groups will be customers now in a sense, and they will absolutely see themselves as customers (however limited it may be), because they are paying for a good. People who are going to do the right thing by default don't appreciate being lumped in with the rest of folks who won't.

So if you're going to proceed with this, I think the key is minimizing friction through incredibly clear communication on exactly what steps customers need to take if things break. I think you have a solid plan, but I propose moving in these stages to avoid any risk of alienating good actors who are going to pay for your software vs remove the dependency.

To be clear: still 100% in support of you changing licenses and being compensated for your important work.

[SimonCropp]

@SeanKilleen

the friction you are concerned about is a build error, where it explicitly gives you the msbuild property to use to disable the error. it is the least friction way i can think of for ensuring people see the changes.

if you degrade the experience of good actors

Again it is a single build error that is trivial to disable.

I propose moving in these stages to avoid any risk of alienating good actors who are going to pay for your software vs remove the dependency

i am moving in stages. thats was me advertising this discucssion and the plan is. the final point is switching on the build notification. that is for people who have not seen it on social media, not read the comms in the readme

. I would first establish who that group of good actors is

i have no idea how to achieve this.

I think the key is minimizing friction through incredibly clear communication on exactly what steps customers need to take if things break.

all that is done.

People who are going to do the right thing by default don't appreciate being lumped in with the rest of folks who won't.

"People who are going to do the right thing by default " can see the build notification and still do the right thing. and the build notification clearly explains how to easily disable it.

[SeanKilleen]

@SimonCropp I think you're mistaking my feedback for argument. I'm not telling you that you are wrong or trying to have a debate with you 👍. I'm providing feedback on how I think people who are paying for the software are going to perceive it. Those people are not necessarily me; just based on my experience in dealing with dev shops of various quality.

It sounds like you feel confident that this will not cause the issues I'm concerned about. Great!

Again it is a single build error that is trivial to disable.

Hopefully so, because if it takes a dev a non-trivial amount of time to make that change and get it through the process, meanwhile a whole team is raising concerns about not being able to build the solution, an alarm bell goes off that says "I should remove this dependency; it's not worth this mess."

---

In reality, probably a non-issue for most. In our specific case if that happened, RenovateBot would create a PR with the latest package, the build would fail in that PR in our CI, we'd check it out, have discussion to sponsor, make the sponsorship change, update that PR and merge it, so very little chance of a breaking issue for our team in particular.

[tonyqus]

bottom line is trusting people will be proactive about "honest model licensing with no enforcement" has proven to not be effective. (at least from my observations

I don't fully agree that host model licensing is not working.

NPOI has introduced OSMF since Apr, 2026. We have got 20+ sponsors. Although it's not many, it looks companies/orgs are still willing to pay. And the idea of OSMF is not for you to become millionaire. The fee is just some small money to cover basic life. And we have to tolerate that a few companies/orgs are ignoring the license. This is the fact.

You should be super cautious with enforcement with some buildtime check like SponsorCheck. Collecting any identification data (such as developer's github or company/org name) may break the data collection rule.

[ValdisThomann]

The idea behind only applying the maintenance fee to extensions that target a paid product is interesting, but does it just complicate the intention of the OSMF? Does it also introduce unintended incentives to use/not use certain extensions?

If an organisation is targeting free/open source ecosystems, it may be unlikely to exceed the revenue threshold anyway. If an organisation did exceed the threshold, then it might be appropriate to share some of the revenue with the tools that are helping to generate that revenue.

I think it may be simpler to administer for both maintainers and consumers if you leave it as full coverage. Perhaps you could provide an escape hatch by granting free licenses for free/open source projects? I've seen this used in other contexts, although it does come with an unremunerated maintenance overhead.

[ProbablePrime]

My org would unfortunately not be able to justify this cost and we'd have to fork or replace.

I know that's not exactly helpful, but it is truthful.

[SimonCropp]

@ProbablePrime the impact in aggregate of significant adoption of the OSMF is a valid point. but it is probably better discussed here https://github.com/orgs/opensourcemaintenancefee/discussions

[falconmick]

Love the mentality of "eww it cost what!!! I'll just maintain my own version, that way every month I charge my org the same that it would have cost in a year in lost productivity"

[ProbablePrime]

Do you think that is unreasonable?

Unfortunately yes.

I am not even close to the mean or median of that salary.

[SimonCropp]

@ProbablePrime in that case i reduced the max cost level. it is now works out to $1 USD per day

[ProbablePrime]

I appreciate the flexibility. I'll have to chase this around the flagpole some. Thank you.

[SeanKilleen]

Realized I hadn't given you feedback on a specific ask -- I think it should apply to everything, not just some plugins, even though that might help my org specifically avoid the fee.

Verify is a tool/ecosystem that unlocks a ton of value. I think the value is in the whole thing, not in parts, and I think you'd sell yourself short by not recognizing that. I think it would end up the worst of all worlds if you only applied it to some plugins -- harder to explain, more cognitive overhead for people deciding whether it applies, confusion about whether the fee is per plugin, still take the "hit" for it being paid even if there are many circumstances in which it's not.

I think if you're going to go this route -- which again, I respect -- I think you should fully commit and apply it to the whole ecosystem. You deserve to be able to maintain this software, and applying it to all the software will allow you to do that.

[randellhodges]

I'd like a little more clarification on employees. My organization has about 300 employees, but they are not in IT. Developers, or people that work with the code only number 3. So where would we fall? Also, while we are a pseudo government agency (water district), we are also not a for profit company.

[SimonCropp]

@randellhodges yes all employees are counted.

and there is no current exclusion for not for profit.

so you would be in the $60/month tier.

serious question though. given you are 3 devs, that works out to a cost ~$1 per dev per business day. do you get less than $1 value out of Verify per day?

[michha]

Will there be alternative payment methods available besides GitHub Sponsors?
We are a government agency for which donating or sponsoring money is not feasible, as we require an invoice before any payment can be processed.
While GitHub does offer an invoicing service, it requires a minimum amount of 5,000 USD. This amount does not correspond to a direct service but rather serves as a credit balance from which donations or sponsorships are deducted.
What would work for us is an invoice (meeting very specific requirements, e.g tax reverse charge) that clearly states the service provided, such as “Verify one-year license fee.”

[ValdisThomann]

I'm in a similar situation to you and have just been through this: you can request an invoice with no minimum limit through this form (described as Option 2): https://github.com/resources/events/support-open-source-sustainability

The ultimate effect is similar to the first option, in that it adds to your credit balance on the Github side.

[michha]

Thank you for this link 👍. It will get us forward.
Do you get some sort of preview after clicking on submit? The form provides only 2 lines for billing address but 3 would be required. We also have to place our tax number on the invoice and so on.

[ValdisThomann]

Unfortunately not! It just says "thanks" and then at some stage an invoice is sent you your email address

[falconmick]

I think if people don't like this they are more than welcome to maintain their own version and spend 1000x the resources doing so.

Go for it

[mortenbock]

The use cases I'm using it for, it is basically just syntactic sugar on top of a string compare. I'm guessing there are many like me. That is not a $60 license library IMO.

Keep the core foundation of the library free, or you will lose the impact this library has.

[SimonCropp]

@mortenbock is the client actively maintain/improving the code after handover? eg who does CVE fixes or adds features etc

[mortenbock]

Projects typically run for years, and some clients have their own developers working on the code base at the same time.

[SimonCropp]

how do you handle other developement license? eg IDEs, build infrastructure (devops, octopus,etc), git tooling?

[mortenbock]

Depends on the license. We do whatever the license requires.

By the way, I think this text is a bit ambiguous:

"The source code remains open and free, and individuals, non-revenue organizations, CI, forks, and local development are unaffected"

This sounds like, if I have the package installed, but only run tests in CI or during local development, I don't need to pay the fee. But that's not how I understood this from other descriptions?

[SimonCropp]

Re

This sounds like, if I have the package installed, but only run tests in CI or during local development, I don't need to pay the fee

I clarified

Forks, contributions, and local development of the Verify codebase would be unaffected.

and yes if both you comany and the target organisation are working on the codebase, then both need to pay the fee.

noting under the updated payment levels, if both classify as large, then is is less than $1USD per day each

[SimonCropp]

ok based on feedback i have halved the $ amounts and doubled the employee levels. so

• Small Organization (fewer than 40 employees): $5/month
• Medium Organization (40 to 200 employees): $20/month
• Large Organization (more than 200 employees): $30/month

[AndrewTriesToCode]

I think it’s important to remember that the way OSMF works usually only the official nuget package requires the fee. People are welcome to use the source code and include or package it themselves if they are unable to pay the fee. Otherwise the fee applies and I think your original amounts are reasonable.

[tonyqus]

Perhaps you can split into 4 tiers instead of 3. 40-200 is a big range.

Here are the NPOI OSMF tiers. Just FYI

• Small (< 20 staff)
• Medium (20–49 staff)
• Large (50–99 staff)
• Super Large (100+ staff)

[SimonCropp]

@tonyqus just to be clear, you thing 1$ USD per day for the max tier is too high?

[tonyqus]

I mean 40-100 staff: $30 and 100+ staff: $50

[tonyqus]

I checked tiers from https://github.com/sponsors/calebporzio. It's super straightforward: Small business and Not a small business

[dev-in-disguise]

@SimonCropp we are nearing the end of August and you noted in the readme:

From August 2026, commercial organizations and government agencies using Verify's official binary releases will be asked to pay a small subscription fee (from $10/month).

So far I haven't seen any changes that would either add EULAs or add any other way of "enforcing" the OSMF. And for the 32.0.0 version you've added so far only the move the v3 of xUnit.

Do you have already a kind of roadmap for the OSMF adoption and enforcement and also in which way you're going to implement it?

[lg2de]

For me, it’s not the total amount the company has to pay that matters. I believe that works itself out, at least when looking at a single project.
Rather, I see the following problem: If this idea catches on, the number of packages that can no longer be used without a contract will increase. This is less of a financial problem and more of an organizational one. I fear that this will lead to people preferring to build their own solutions rather than using existing ones. This reduces the chance that users will provide feedback and suggestions for improvements. In the long run, this will harm the project.